From 4bd0fa843176a112c054929fbe6dd99f45d718a2 Mon Sep 17 00:00:00 2001 From: Kali Kaneko Date: Mon, 18 Aug 2014 12:52:50 -0500 Subject: Imported Upstream version 1.3.1 --- docs/NOTES-isec-audit.org | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 docs/NOTES-isec-audit.org (limited to 'docs/NOTES-isec-audit.org') diff --git a/docs/NOTES-isec-audit.org b/docs/NOTES-isec-audit.org new file mode 100644 index 0000000..f1d729d --- /dev/null +++ b/docs/NOTES-isec-audit.org @@ -0,0 +1,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? -- cgit v1.2.3