email signatures OpenPGP
intelMQ shall support cryptographic verification and sending of emails.
There are two competing, well distributed standards for crypto email:
- Object-Format: OpenPGP Email-Format: OpenPGP/MIME
- Object-Format: CMS Email-Format: S/MIME
To not add another central service by introducing a PKIX with S/MIME, I propose that we start supporting OpenPGP. Technical aspect: we need an implementation accessible from python3 (and Free Software compatible with intelmq's license) Idea: use a python interface to www.gnupg.org. A list of the official API for GnuPG can be found here https://wiki.gnupg.org/APIs
https://github.com/Intevation/intelmq-mailgen/issues/12 will start with a "no-mime, system protected privat key"-implementation for sending out emails.
I started to implement a RTIR-fetcher bot including decryption a while ago: 96541e2762bf842c7bcd60df951fbed6ea42f136 As it's a proof of concept (or this was the idea) it does not work AFAIR, completely lacks docs and is incomplete. But possibly a good starting point.
Criteria for selecting a python3 "library" for GnuPG
- Should be based on gpgme, as this is the official api and more stable than calling gpg2.exe ourselfs.
- How easy is it to get this on platforms (e.g. is this packaged for Debian or Ubuntu?)
- How fit is it for the future? (Maintained, ready for new GnuPG2.1 releases)
There are two main choices: a) pyme (with a python3 port in http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=history;f=lang/python;hb=HEAD), GNU LGPL >=2 (compatible) b) pygpgme which comes with a python3 package in Debian and Ubuntu. , same license as gpgme (so probabyl GNU LGPL v>=2, too)
https://tracker.debian.org/pkg/pygpgme https://launchpad.net/ubuntu/+source/pygpgme
https://tracker.debian.org/pkg/pyme https://launchpad.net/ubuntu/+source/pyme
Outside of our design requirements is https://pypi.python.org/pypi/python-gnupg (which is available for python3, but xorg style license, but not following the GnuPG API recommandations).
@sebix thanks for the pointer. I briefly looked at the code and commented there, I'd rather use something based on the official gnupg api. And you only do decryption, verifying a sender is the more interesting part. :)
Ranking our options, regarding the criteria
- pygpgme as it is already packaged for python3, license compatible, based on gpgme, medium points on fitness because of last release 2012, but recent new packages
- upcoming official gpgme python binding based on pyme, but ported to python3. Availability: not packaged yet, not released yet. license compatible, future fitness: good points.
- pyme. Availability: no python3 version packaged. based on gpgme, license compatible. Future fitness: okay as 2.
- (python-gnupg. not based on gpgme)
If 2. would be released, it would be more attractive. I've asked on gnupg-devel about the release schedule. On the other hand it will be comparitively easier to switch to gpgme-python3 once gpgme is released and packaged within the distributions. Compared to package the unreleased version now, repackage it and so on.
I'll go with pygpgme for now and implement a first sending version in Intevation/intelmq-mailgen#12 see progress there
It seems an official gpgme release with a python binding is close (within June) https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031157.html Still pygpgme's availability in Debian and Ubuntu now let me continue with it for now in Intevation/intelmq-mailgen#12
Note that https://github.com/Intevation/intelmq-mailgen/ has support for creating no-mime signatures (since Intevation/intelmq-mailgen#12 was successfully closed).
actually this is a mailgen issue and not a core intelmq issue. Moving to v1.1
Verification the signatures of incoming emails should be a core intelmq issue I guess.
library selection
Meanwhile an official Python3 binding was published from the GnuPG Initiative with gpgme v1.7.0.
This library SHOULD be used in the future. Right now it would add another complex dependency as it is not available from pypi and needs to compile C-source code.
Thus https://github.com/Intevation/intelmq-mailgen/issues/39 will stay with the already used and on-debian-packaged pyme for the time being.