This page documents the effort to establish and maintain cryptographic foundation classes for Trac. Historically the code has evolved from development of encryption for AnnouncerPlugin email messages using GnuPG, but other Trac plugins could use it in the future as well.

Why

Cryptography could help to push Trac towards what I proposed as ​TrustedTrac.

Imagine, you're using Trac in a corporate environment, typically allowing external access to Trac, repositories etc. only after authorization or not at all.
Still, you may wish to keep business partners, support customers, etc. informed about certain or all developments, and that involves sending potentially sensitive (security, privacy ...) information outside the tightly controlled corporate network. Co-workers in a home office setup may create a similar demand.

Use tickets, wiki and it's notification without concerns on authenticity and discretion:

Signing content will help recipients to be sure, that they got unaltered content and got it really from the announced author.

Encrypting content will help to circumvent certain limitations of other Trac plugins, that try to restrict access to sensitive content.

It'll be superior, because the implementation strategy backed by state-of-the-art cryptography is "inherently secure by design", witch non of the other currently available solutions can provide.

What

Here is a description of what shall be done. Experts and GPG/PGP users may wish to skip that section and go to the proposal for Trac-specific use right away.

OpenPGP principles

FIXME I'll write here and cite sources for more detailed explanation of OpenPGP standard and cryptography in communication in general.

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

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

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

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

The choice: python-gnupg

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.

Q&A

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

?: Does python-gnupg support GnuPG v2?

A: AFAIK yes, both versions support same CLI syntax. I'll 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 this subject to exploration in the implementation process.

Development traces (history)

This is kept for reference and personal attitude to preserve historical notes. See the initial development, that has been done since March 2010 inside TracAnnouncer (AnnouncerPlugin).