Version 1 (modified by Steffen Hoffmann, 12 years ago) (diff)

initial design and content

Messages encryption

I'll document the effort to add support for optionally message encryption using GnuPG.

Code structure


Where to kick in and mangle the message body is of course an essential decision. Reading the current code from trunk I found this in ./announcerplugin_trunk/announcer/distributors/

        decorators = self._get_decorators()
        if len(decorators) > 0:
            decorator = decorators.pop()
            decorator.decorate_message(event, rootMessage, decorators)
        recip_adds = [x[2] for x in recipients if x]
        # Append any to, cc or bccs added to the recipient list
        for field in ('To', 'Cc', 'Bcc'):

--> Here I'll add some code to make encryption just work (1st step). Encryption/signing key ID hard-coded, growing number of variables I'd like to see as options in [annoucer] section of trac.ini and other ugliness. This will evolve over time.

[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.

?: Why not implement encryption as another IAnnouncementFormatter

A: Encryption is not about encoding etc.


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

sources (ideas and code)

-- hasienda

Attachments (1)

Download all attachments as: .zip