wiki:AnnouncerPlugin/MessageEncryption

Version 9 (modified by anonymous, 14 years ago) (diff)

--

Messages encryption

I'll document the effort to add support for optionally message encryption using GnuPG. See #6773 for the corresponding ticket asking for this enhancement.

Code structure

Where

Where to kick in and mangle the message body is of course an essential decision. My initial assumption that I could add cryptographically functions right before inserting recipient addresses to the message was wrong. Now I add the following into code of ./announcerplugin_trunk/announcer/distributors/mail.py from trunk of AnnouncerPlugin:

         return msgid
 
     def _do_send(self, transport, event, format, recipients, formatter):
         output = formatter.format(transport, event.realm, format, event)
+
+        email_encrypt = True
+        if email_encrypt:
+            output = encrypt_txt(output)
+            self.log.debug("EmailDistributor successfully encrypted msg.")
+
         alternate_style = formatter.alternative_style_for(
             transport, 
             event.realm,

What

What to do. It greatly depends on decision about how much is read from configuration or qualified deduction/guessing. Less configuration is good for the Admin in charge.

Overview of expected behavior/features:

  • set gpg environment, preferable a dedicated place
  • read recipient list, optionally group recipients into require_encryption_group and allow_verbatim_msg_group
  • associate each recipient in require_encryption_group with key
  • handle behavior on missing key
  • embed DEBUG logging into all operations mentioned above

Is it right 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.

How

The interface

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):

  • python-gnupg
    • 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.4 from 01-03-2010
    • CON: no Debian package?
    • TEST:
      • download and local install without issues,
      • function list_keys() doesn't "just work" works on a known-good gpg keyfile directory - got it
      • 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
  • Python GnuPGInterface
    • PRO: Debian package python-gnupginterface-0.3.2-9
    • 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 (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
  • PyGPGME
    • PRO: Debian package python-gpgme-0.1+bzr20090820-1+b1
    • CON: ?
  • PyMe
    • 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
    • CON: complex dependencies because built on GPGME + Python + SWIG
    • TEST
      • Debian package needed upgrade to python-pyme-0.8.1+clean-3+b1 to fix error on GnuPG interface setup call
      • much more complex API compared to python-gnupg
      • 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.
  • OpenPGP
    • PRO: ?
    • 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 currently unreachable)
  • cryptlib
    • 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
    • CON: no Debian package?

conclusion: test python-gnupg, PyMe, PyGPGME, skip GnuPGInterface, OpenPGP, cryptlib (for now)
hints, recommendations? known-good code references or popular applications?

The code

  1. step: add some code to make encryption just work done
    • expect encryption/signing key ID hard-coded, some fixed values for variables I'd like to see as options in [annoucer] section of trac.ini and other ugliness
  2. step: code evolution over time, i.e.
    1. put code into separate python script and import function into distributors/mail.py done
      • add new reference
        from announcer.util.mail_encrypt import encrypt_txt
        
      • add ./announcerplugin_trunk/announcer/util/mail_encrypt.py containing new cryptographic functions
    2. consider invention of a new class, i.e. to allow for reusable code, gpg interface initialization before sign and encrypt actions would profit among others
    3. add a minimal set of new options to [annoucer] section of trac.ini and replace formerly fixed values to gain planned control about new cryptographic functions
  3. step: extend web_ui of AnnouncerPlugin to remote-control new options from user and/or administration settings

[FIXME: add more Q+A here to help with code design evaluation and code review]

?: Why not implement encryption as another IAnnouncementEmailDecorator

A: Decorators are called without guaranteed order. Encryption needs control, that it'll be the last message body mangling action. We can change this pretty easily - doki_pen

?: Why not implement encryption as another IAnnouncementFormatter

A: Encryption is not about encoding etc. Formatter is more about turning an event into a message, it shouldn't be done here. - doki_pen

Sources (ideas and code)

some more real-world implementations of python-gnupg, hints?

-- hasienda

Attachments (1)

Download all attachments as: .zip