Re: [Mailman-Developers] GSOC Midterm Report
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 signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Midterm Report
On 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-gnupg` was 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:
0) two OpenPGP signatures within a single pgp-signature part
1) your duplicated multipart/alternative approach
2) 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
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Midterm Report
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-gnupg` was 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: http://tinyurl.com/mulvhql 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 signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Midterm Report
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 ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSOC Midterm Report
Hi all,
This is report of my GSoC project - OpenPG integration with GNU Mailman
for midterm. The code is updated at my launchpad branch[1].
Accomplishments:
* 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
the message using gpg utility.
* 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-gnupg` was 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-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.
* 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.
[1]: https://code.launchpad.net/~raj-abhilash1/mailman/master
[2]: http://tools.ietf.org/html/draft-ietf-openpgp-multsig-02
---
Abhilash Raj
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC Midterm Report
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-gnupg` was 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:
0) two OpenPGP signatures within a single pgp-signature part
1) your duplicated multipart/alternative approach
2) 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,
--dkg
signature.asc
Description: OpenPGP digital signature
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
