Hi all,
This is report of my GSoC project - OpenPG integration with GNU Mailman for midterm. The code is updated at my launchpad branch1.
Accomplishments: the message using gpg utility.
- A signature rule(src/mailman/rules/signature.py) to check for OpenPGP signature in a message, incase the signature is found it tries to verify
A gpg utility(src/mailman/utilities/gpg.py) to perform all the signature related tasks using
python-gnupg(v0.3.4). It signs and verifies the signature.A signmessage handler(src/mailman/handlers/signmessage.py) to sign the outgoing message using the gpg utility.(Signing a message is still incomplete in the sense we do not have a way to store and use keys. For now it has a pubring.gpg and secring.gpg inside (var/gpg/). It will be replaced with actual keyrings in future.)
Tests for each of the three modules above. Testing gpg.py was a small challenge(for me).
Issues and Roadblocks:
Signature verification using
python-gnupgwas a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way.Version control was also a issue that I encountered. Initially I started to work on git mirror of mailman. When I tried to port the code back to bazaar and push to github it took me(and others) a lot of brainstorming. Finally I did that using bzr-git.
Deciding the structure of the signed message that we were going to send out. Initially it was decided to leave sender's signature intact so that if someone wants to verify it he can do it, but there can-not be two 'pgp-signature' parts in a conventional multipart/signed message. I wrote the code to follow an internet-draft2 i discovered one-day. But then I commented out the code and also added another format
mutipart/alternative { multipart/signed { text/plain, application/pgp-signature } multipart/signed { text/plain, application/pgp-signature } }
Some furthur assistance and research on which format do MUAs support the most should be implemented.
- python-gnupg does not provide any way to search for keys based on key-data like email-address. I need some more work to get this working.
Future Plan: The next plans for this project include testing all the above parts thoroughly and then moving on to creating a PKI for the key. Also the settings for the list-manager to adjust a few options related to signed lists - like time limit(decided from date in signature) to consider a message old, and also implementing this in code.
Schedule: My work remains two to three days behind the schedule i proposed. I hope I will be able to give some extra time and get back to schedule soon.
Abhilash Raj
I'm excited to see this work, Abhilash!
Do you have a demonstration instance of this code up and running anywhere?
On 07/31/2013 02:43 AM, Abhilash Raj wrote:
- Signature verification using
python-gnupgwas a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way.
have you reported this as a bug to the python-gnupg folks? I imagine a patch to improve their documentation would be welcomed.
- Deciding the structure of the signed message that we were going to send out. Initially it was decided to leave sender's signature intact so that if someone wants to verify it he can do it, but there can-not be two 'pgp-signature' parts in a conventional multipart/signed message. I wrote the code to follow an internet-draft[2] i discovered one-day. But then I commented out the code and also added another format
mutipart/alternative { multipart/signed { text/plain, application/pgp-signature } multipart/signed { text/plain, application/pgp-signature } }
Some furthur assistance and research on which format do MUAs support the most should be implemented.
While you can't have two pgp-signature parts in a conventional multipart/signed message, you *can* have two OpenPGP signatures within a single pgp-signature part.
So it sounds like you have three options:
two OpenPGP signatures within a single pgp-signature part
your duplicated multipart/alternative approach
the recommendation in the internet draft you found.
Of those three, i recommend going with 0 first, then 2, then 1. Having a message with dual signatures is going to be surprising to many MUAs that haven't thought through the implications, no matter what formatting you choose. keeping the message structure simple and standard (suggestion 0) seems like it will be the least surprising.
Have you generated example messages of these forms and tried them with various OpenPGP-capable MUAs?
Future Plan: The next plans for this project include testing all the above parts thoroughly and then moving on to creating a PKI for the key.
Can you explain more what you mean by "a PKI for the key"? I'm curious.
Nice work on all this! I look forward to seeing it in action!
Regards,
--dkgOn Thursday 01 August 2013 03:47 AM, Daniel Kahn Gillmor wrote:
I'm excited to see this work, Abhilash!
Do you have a demonstration instance of this code up and running anywhere?
No, not yet. Even though signature verification and signing work separately still some work needs to be done to make both work together.
On 07/31/2013 02:43 AM, Abhilash Raj wrote:
- Signature verification using
python-gnupgwas a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way.have you reported this as a bug to the python-gnupg folks? I imagine a patch to improve their documentation would be welcomed.
It seems that there is no public repository for this project. I will still open a issue.
- Deciding the structure of the signed message that we were going to send out. Initially it was decided to leave sender's signature intact so that if someone wants to verify it he can do it, but there can-not be two 'pgp-signature' parts in a conventional multipart/signed message. I wrote the code to follow an internet-draft[2] i discovered one-day. But then I commented out the code and also added another format
mutipart/alternative { multipart/signed { text/plain, application/pgp-signature } multipart/signed { text/plain, application/pgp-signature } }
Some furthur assistance and research on which format do MUAs support the most should be implemented.
While you can't have two pgp-signature parts in a conventional multipart/signed message, you *can* have two OpenPGP signatures within a single pgp-signature part.
So it sounds like you have three options:
two OpenPGP signatures within a single pgp-signature part
your duplicated multipart/alternative approach
the recommendation in the internet draft you found.
Of those three, i recommend going with 0 first, then 2, then 1. Having a message with dual signatures is going to be surprising to many MUAs that haven't thought through the implications, no matter what formatting you choose. keeping the message structure simple and standard (suggestion 0) seems like it will be the least surprising.
Have you generated example messages of these forms and tried them with various OpenPGP-capable MUAs?
I haven't but I am working on that. Can you point me to some implementation using 0)?
Future Plan: The next plans for this project include testing all the above parts thoroughly and then moving on to creating a PKI for the key.
Can you explain more what you mean by "a PKI for the key"? I'm curious.
Now as the signing part is almost done except for to-be-able-to-select the key for signing(now python-gnupg signs using the first found key in the secret keyring) we need the proper infrastructure for the key management. Where will the public keys of the users be stored? Where will the secret keys of the lists be stored? How will they be accessed by mailman?
For now simply a directory is created under var-directory where pubring.gpg and secring.gpg exist. I am myself on to finding solution to all these question, although I think I will be needing some serious help on this as I have very less idea how to actually implement it.
Nice work on all this! I look forward to seeing it in action!
Thanks
Regards,
--dkg
Abhilash Raj
On Jul 31, 2013, at 06:17 PM, Daniel Kahn Gillmor wrote:
I'm excited to see this work, Abhilash!
Me too!
On 07/31/2013 02:43 AM, Abhilash Raj wrote:
- Signature verification using
python-gnupgwas a PITA to me for sometime. The way it accepts the string and signature for detached signature is not documented at all and is converse of what I could think of. It just occurred to me to try out the other possibility which turned out to be the right way.have you reported this as a bug to the python-gnupg folks? I imagine a patch to improve their documentation would be welcomed.
I'm not so sure about the "not documented at all" part.
http://pythonhosted.org/python-gnupg/#verification
I'm using verify_file() in another project:
but I agree it's not the most convenient API.
Although the VCS for the upstream code is not publicly available, their issue tracker is:
https://code.google.com/p/python-gnupg/issues/list
and I've found them to be pretty good about responding to bugs and feature requests.
Cheers, -Barry
On Aug 02, 2013, at 05:49 PM, Abhilash Raj wrote:
Now as the signing part is almost done except for to-be-able-to-select the key for signing(now python-gnupg signs using the first found key in the secret keyring) we need the proper infrastructure for the key management. Where will the public keys of the users be stored? Where will the secret keys of the lists be stored? How will they be accessed by mailman?
One thought is to have a public keyring to store all the pubkeys of the users, and store just the key ids/fingerprints in the database. That will probably have to be a table of ids/fingerprints cross-referenced to the user table (since a user would probably control multiple keys).
The other option is to use a table that associates email address in the pubkey to the fingerprint/id and cross reference them to the addresses table for addresses that Mailman knows about.
-Barry
On 08/02/2013 01:18 PM, Barry Warsaw wrote:
On Aug 02, 2013, at 05:49 PM, Abhilash Raj wrote:
Now as the signing part is almost done except for to-be-able-to-select the key for signing(now python-gnupg signs using the first found key in the secret keyring) we need the proper infrastructure for the key management. Where will the public keys of the users be stored? Where will the secret keys of the lists be stored? How will they be accessed by mailman?
One thought is to have a public keyring to store all the pubkeys of the users, and store just the key ids/fingerprints in the database. That will probably have to be a table of ids/fingerprints cross-referenced to the user table (since a user would probably control multiple keys).
The other option is to use a table that associates email address in the pubkey to the fingerprint/id and cross reference them to the addresses table for addresses that Mailman knows about.
Alternately, you could avoid storing any sort of key material or fingerprints in the database at all, and let GnuPG manage the e-mail address → key mappings, based on a set of trusted certifiers.
This is exactly what gnupg's key selection and trustdb code is designed to do already. If gnupg's key selection and trustdb code doesn't work for this purpose, it would be nice to let the gnupg folks know why it's inadequate.
Regards,
--dkg
participants (3)
-
Abhilash Raj -
Barry Warsaw -
Daniel Kahn Gillmor