Changes between Version 22 and Version 23 of AnnouncerPlugin/MessageEncryption


Ignore:
Timestamp:
May 28, 2012, 2:25:26 PM (12 years ago)
Author:
Steffen Hoffmann
Comment:

update, moved content to new wiki:CryptoPlugin/Dev

Legend:

Unmodified
Added
Removed
Modified

  • AnnouncerPlugin/MessageEncryption

    v22 v23  
    11= Announcer cryptographic capabilities =
    2 [[TOC(heading=page content)]]
    3 This page documents the effort to add optional encryption for AnnouncerPlugin email messages using GnuPG.[[BR]]
    4 See #6773 for the corresponding ticket asking for this enhancement.
     2[[PageOutline(2-4,page content)]]
     3This page documents the effort to add optional encryption for AnnouncerPlugin email messages using GnuPG.
     4See #6773 for the corresponding ticket asking for this enhancement and [wiki:CryptoPlugin CryptoPlugin] for the future of this development.
    55
    66== Why ==
    7 Let's see how cryptography could help with Trac and especially with it's announcements.
     7Let's see how cryptography could help with Trac announcements.
    88
    99Imagine, you're using Trac in a corporate environment, typically allowing external access to Trac, repositories etc. only after authorization or not at all.
    … …  
    1212Signing emails will help recipients to be sure, that they got unaltered content and got it from you. Encrypting emails will help to distribute announcements to external recipients as freely as to recipients inside without concerns on discretion.
    1313
    14 == What ==
    15 Here is a description of what shall be done. Experts and GPG/PGP users may wish to skip that section and go to the [#AnnouncerEmailEncryption proposal for Trac-specific use] right away.
    16 
    17 === OpenPGP principles ===
    18 FIXME: I'll write here and cite sources for more detailed explanation of OpenPGP standard and cryptography in communication in general.
    19 
    2014== How (proposed implementation) ==
    2115It might help a lot to have a closer look at [t:wiki:TracDev/Announcer internal structure and event flow] of AnnouncerPlugin. Where to kick in is of course an essential decision. Since it's not only about mangle the message body (one of the earlier assumptions that all turned out to reach not far enough), there is not a single point but a bunch of changes needed to get cryptographic operations working.
    2216 
    2317There are modifications required and code to be added to `announcer/distributors/mail.py`. A new file `announcer/util/mail_crypto` introduces a new class `CryptoTxt`, that provides the cryptographic operations. The approach is generic enough to be extended beyond OpenPGP, currently the only supported crypto standard and handled by GnuPG, to i.e. use X.509 certificates as well.
     18
     19''Update:'' I've thought a lot about the aforementioned approach and found it far to narrow. So a major re-design is on the way now. Cryptographically operations will be completely moved into a dedicated stack of python scripts: CryptoPlugin, that provides universal, reusable methods for certificate and key management and beyond announcement email content.
    2420
    2521=== !AnnouncerEmailEncryption ===
    … …  
    6662
    6763=== Q&A ===
     64[FIXME: add more Q+A here to help with code design evaluation and code review] 
    6865 ?: ''Is it true that different users will have different keys?  If so, we can add configuration to the user's preference page.  We could have a big textbox for GPG key and if they have one entered, then use encryption.
    69   A: Yes, different users will (typically) have different keys. It might be desirable even to support multiple keys per user. Only in rare cases one key would be associated with different users/e-mail addresses, even if this might be technically perfectly valid and useful. But it indicates violation of the de-facto standard one-owner-per-key that abhor kind of group keys.
    70 
    71 == Beyond current development scope ==
    72 There is a [t:wiki:TracDev/Proposals/Announcer proposal] to replace current Trac Notification system with AnnouncerPlugin. This will make the effort for a really clean solution even more urgent.
    73 
    74 Consider [https://subtrac.sara.nl/oss/email2trac/ticket/186 cryptography related features] for EmailtoTracScript ([https://subtrac.sara.nl/oss/email2trac current home outside of Tack-Hacks]). It could be interesting i.e. to allow only e-mails with valid signature from known senders to pass, fighting spam at another level.
    75 
    76 == Development notes ==
    77 === Discussion ===
    78 Hints, recommendations? Known-good code references or popular applications? Put your comments in here, please.
    79 
    80 === Available interfaces with GnuPG ===
    81 To make it more difficult for me to start I've found not one but several candidates for interacting with GnuPG from Python (http://wiki.python.org/moin/GnuPrivacyGuard has a listing with some more comments):
    82  * [http://code.google.com/p/python-gnupg/ python-gnupg]
    83   * PRO: no additional dependencies but pure Python, works on Windows as well as Unix/Linux, most complete set of gpg actions including key generation and management, active development - python 3 support since July 2009, latest release v0.2.9 from 29-03-2012
    84   * CON: no Debian package?
    85   * '''TEST''':
    86    * download and local install without issues,
    87    * function list_keys() ~~doesn't "just work"~~ works on a known-good gpg keyfile directory - got it
    88    * beware: "gnupghome" directory will be created silently (including parents), if something is not there exactly as specified, init function will need to prevent creation of unwanted directories by (worst case: repeated) mis-configuration
    89  * [http://py-gnupg.sourceforge.net/ Python GnuPGInterface]
    90   * PRO: Debian package python-gnupginterface-0.3.2-9.1
    91   * CON: concentrates on interacting with GnuPG via filehandles, based on Perl module GnuPG::Interface by same author, rumors about being "not very easy to use", doesn't work on Windows ([http://sourceforge.net/tracker/?func=detail&aid=1859636&group_id=29555&atid=396635 open feature request] since 2007, even has predecessor from 2002 that was plainly rejected), quite old - latest release v0.3.2 from 24-02-2002, even looks unmaintained since 2008
    92  * [https://launchpad.net/pygpgme PyGPGME]
    93   * PRO: Debian package python-gpgme-0.1+bzr20090820-1+b1, interface to gpgme without SWIG
    94   * CON: ?
    95  * [http://pyme.sourceforge.net/ PyMe]
    96   * PRO: interface to C GPGME library, not limited to gpg by design, other backends planned, works on Windows as well as Unix/Linux, latest release v0.8.1 from 26-11-2008, Debian package python-pyme-0.8.1+clean-1
    97   * CON: complex dependencies because built on GPGME + Python + SWIG
    98   * '''TEST'''
    99    * Debian package needed upgrade to python-pyme-0.8.1+clean-4 to fix error on GnuPG interface setup call
    100    * much more complex API compared to python-gnupg
    101    * on halt for now, but still considered nice-to-have, since it would allow additional crypto-backends i.e. working with X.509 certificates etc.
    102  * [http://pypi.python.org/pypi/OpenPGP/ OpenPGP]
    103   * PRO: ?
    104   * CON: no Debian package, no information on Windows support, quite old - latest release v0.2.3 from 01-07-2005, even looks unmaintained (project homepage ~~http://www.aonalu.net/openpgp~~ ceased to exist)
    105  * [http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ cryptlib]
    106   * PRO: interface to a range of plug-in encryption modules, not only but including gnupg, language bindings for C / C++, C# / .NET, Delphi, Java, Python, and Visual Basic, re-entrant and completely thread-safe, most core algorithms implemented in assembly language, support crypto hardware acceleration facilities like in Via C3 CPU family, extensive documentation designed for cut-n-paste directly from manual
    107   * CON: no Debian package - probably in part [http://www.debian-administration.org/users/dkg/weblog/74 due to licensing issue]
    108  * [http://www.dlitz.net/software/pycrypto/ PyCrypto]
    109   * PRO: ?
    110   * CON: looks incredibly complex at first glance
    111  * [http://www.freenet.org.nz/ezPyCrypto/detail/index.html ezPyCrypto], a simpler API on top of !PyCrypto
    112 
    113 === The choice: python-gnupg ===
    114 '''python-gnupg''' was tested, !PyMe a little too. It became clear, that python-gnupg just worked without much hassle. Anything else had more dependencies and was more complicated i.e. by introducing GPGME. This applies to !PyMe as well as PyGPGME. GnuPGInterface, OpenPGP, cryptlib where skipped right after the initial interface research.
    115 
    116 === Q&A ===
    117 [FIXME: add more Q+A here to help with code design evaluation and code review] 
     66  A: Yes, different users will (typically) have different keys. It might be desirable even to support multiple keys per user. Only in rare cases one key would be associated with different users/e-mail addresses, even if this might be technically perfectly valid and useful. But it indicates violation of the de-facto standard one-owner-per-key that abhor kind of group keys. Update: User preferences will be provided by CryptoPlugin.
    11867 ?: Why not implement encryption as another IAnnouncementEmailDecorator
    11968  A: Decorators are called without guaranteed order. Encryption needs control, that it'll be the last message body mangling action.
    … …  
    13079  ||missing pubkey ||fingerprint in user settings but no corresponding key in pubkeyring file ||delete recipient from recipient list of event in delivery, create new event with info "specified pubkey not in Tracs keyring" to be sent to this user and project admin ||
    13180
    132  ?: Does python-gnupg support GnuPG v2?
    133   A: AFAIK yes, both versions support same CLI syntax. I'll continue to test with both versions in the future to maintain compatibility. There might be even a bonus from using GnuPG v2, since it is announced to be PGP/MIME aware. However I'll still have to look into this in detail.
     81
     82== Beyond current development scope ==
     83There is a [t:wiki:TracDev/Proposals/Announcer proposal] to replace current Trac Notification system with AnnouncerPlugin. This will make the effort for a really clean solution even more urgent.
     84
     85Consider [https://subtrac.sara.nl/oss/email2trac/ticket/186 cryptography related features] for EmailtoTracScript ([https://subtrac.sara.nl/oss/email2trac current home outside of Tack-Hacks]). It could be interesting i.e. to allow only e-mails with valid signature from known senders to pass, fighting spam at another level.
    13486
    13587=== Development traces (history) ===
    … …  
    156108 ||email.encrypt_except ||None ||one or more e-mail-addresses or domain as comma-separated list, matching recipients that still get cleartext msg ||
    157109 ||email.sign_except ||None ||valid values as before, but matching recipients here still get msg without cryptographically signature ||
    158  3. step: extend web_ui of AnnouncerPlugin to remote-control new options from user and/or administration settings
     110 3. step: extend web_ui of AnnouncerPlugin to remote-control new options from user and/or administration settings - ''canceled, as this is largely unrelated to this plugins core business''
    159111
    160112== Resources (for ideas and code) ==
    161  * GNU Privacy Guard Manual at http://www.gnupg.org/documentation/manuals/gnupg/
    162  * Why sign&encrypt is not very secure by default see http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html (discussion about vulnerability againgst "surreptitious forwarding")
    163  * Intro to python-gnupg at http://groups.google.de/group/comp.lang.python/browse_thread/thread/f2b97a2c11e1df63
    164  * Python Wrapper for GnuPG v0.2.4 documentation: http://www.red-dove.com/python_gnupg/index.html
    165113 * Python e-mail test server http://docs.djangoproject.com/en/1.1/topics/email/#topics-email
    166114 * How Django, another Python based system handles e-mail-encryption with [http://code.google.com/p/django-email-extras/ django-email-extras] ([http://code.google.com/p/django-email-extras/source/browse/trunk/email_extras/ browse the code])
    167  * Python tutorial at http://www.python.org/doc/current/tutorial/index.html to help some newbie like me opening the world of Python code
    168 some more real-world implementations of python-gnupg, hints?
    169115 * MIME-capable Python mailer script is published at http://www.physics.drexel.edu/~wking/code/python/send_pgp_mime, this look very interesting, may help with a lot of things, but may not serve as a code base (incompatible license GPL2 vs. BSD-alike), not portable (consider Linux/Unix as well as Windows)
    170116