blob: f1d729d373d326c4006a7e7b1a65ad0d9bad0468 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
-*- mode: org; -*-
* python-gnupg
** what should be done by 1 May 2013:
- [ ] packaging for pypi
- [ ] unittests
- [ ] leap_mx and soledad should be using python-gnupg
** what the isec folks might want to look at:
*** options
are there any ways to coerce python-gnupg in strange/buggy ways though its
allowed options, or, in general, though the API it presents?
*** daemons
if any of the daemons controlled by, or connected to, leap_mx or soledad
can be leveraged in any way to execute an a attack using python-gnupg.
*** keyID collision / couchDB key database poisoning
is there a way to trick python-gnupg into using an incorrect key?
*** identity leaks
is there a way to analyse the mailserver, leapmx, or soledad, to gain info
about which key is being used at a particular time?
|
