From dkg at fifthhorseman.net Thu Aug 1 00:17:46 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Jul 2013 18:17:46 -0400 Subject: [Mailman-Developers] GSOC Midterm Report In-Reply-To: <51F8B225.1060504@gmail.com> References: <51F8B225.1060504@gmail.com> Message-ID: <51F98D0A.4060505@fifthhorseman.net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From raj.abhilash1 at gmail.com Fri Aug 2 14:19:30 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 02 Aug 2013 17:49:30 +0530 Subject: [Mailman-Developers] GSOC Midterm Report In-Reply-To: <51F98D0A.4060505@fifthhorseman.net> References: <51F8B225.1060504@gmail.com> <51F98D0A.4060505@fifthhorseman.net> Message-ID: <51FBA3D2.4010008@gmail.com> 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 From barry at list.org Fri Aug 2 19:13:04 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 2 Aug 2013 13:13:04 -0400 Subject: [Mailman-Developers] GSOC Midterm Report In-Reply-To: <51F98D0A.4060505@fifthhorseman.net> References: <51F8B225.1060504@gmail.com> <51F98D0A.4060505@fifthhorseman.net> Message-ID: <20130802131304.4c3623a3@anarchist> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Fri Aug 2 19:18:31 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 2 Aug 2013 13:18:31 -0400 Subject: [Mailman-Developers] GSOC Midterm Report In-Reply-To: <51FBA3D2.4010008@gmail.com> References: <51F8B225.1060504@gmail.com> <51F98D0A.4060505@fifthhorseman.net> <51FBA3D2.4010008@gmail.com> Message-ID: <20130802131831.4366c6c4@anarchist> 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 From truongvunghia at gmail.com Sun Aug 4 00:41:09 2013 From: truongvunghia at gmail.com (Nghia Vu Truong) Date: Sat, 03 Aug 2013 23:41:09 +0100 Subject: [Mailman-Developers] Where does Mailman keep information of who reply to a post? Message-ID: <51FD8705.6030703@gmail.com> Hi everyone, Could anyone please help me to explain where Mailman keeps record of who reply to a particular post? Thanks Nghia From Richard at Damon-Family.org Sun Aug 4 01:59:23 2013 From: Richard at Damon-Family.org (Richard Damon) Date: Sat, 03 Aug 2013 19:59:23 -0400 Subject: [Mailman-Developers] Where does Mailman keep information of who reply to a post? In-Reply-To: <51FD8705.6030703@gmail.com> References: <51FD8705.6030703@gmail.com> Message-ID: <51FD995B.5000305@Damon-Family.org> On 8/3/13 6:41 PM, Nghia Vu Truong wrote: > Hi everyone, > Could anyone please help me to explain where Mailman keeps record of > who reply to a particular post? > Thanks > Nghia Simple answer, it doesn't. What made you think it did? If you are wondering about how the archives know how to thread the discussion (for the threaded view), this is done by message headers in the email put in by the replying email program, which indicate the message-id (a unique identifier added to all emails by email systems) of the message it is a reply to. -- Richard Damon From dkg at fifthhorseman.net Tue Aug 6 19:30:10 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Aug 2013 13:30:10 -0400 Subject: [Mailman-Developers] GSOC Midterm Report In-Reply-To: <20130802131831.4366c6c4@anarchist> References: <51F8B225.1060504@gmail.com> <51F98D0A.4060505@fifthhorseman.net> <51FBA3D2.4010008@gmail.com> <20130802131831.4366c6c4@anarchist> Message-ID: <520132A2.10603@fifthhorseman.net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Wed Aug 7 08:02:43 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 7 Aug 2013 15:02:43 +0900 Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration In-Reply-To: References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in> <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20993.58115.217623.940490@uwakimon.sk.tsukuba.ac.jp> ehrbar at greenhouse.economics.utah.edu writes: > I am not an expert but the encryption discussion is > extremely important. We are not currently discussing encryption, but rather signing. A similar approach might work for signing, but it's subject to a weaker form of the objection below.[1] > Are you familiar with the Secure Email Lists (SELS) project? It's been mentioned. > To my limited understanding it seems to have the perfect > solution for mailing lists. Nothing in email is perfect or as simple as it seems. :-) > From skimming your messages I did not have the sense > that you were discussing such a paradigm. We aren't. This paradigm has a serious security hole from the point of view of Mailman in that many lists consider the filtering services (ie, blocking certain MIME content-types) to be essential. Since the MTA cannot decode and Mailman doesn't decode messages, there is no way to prevent distribution of malware. This would at the very least be a serious embarrassment to the operators of the allegedly "secure" list, and in my experience a serious danger, as I know very few people who treat "secure" systems as anything but absolutely safe, ignoring the fact that any given security system can only handle the attack vectors it was designed to handle. It might be useful to add it as an additional service, but given the responsibility that mailing list admins are expected to shoulder in today's environment, I think it's essential that the admins have access to the content distributed by their lists. Steve Footnotes: [1] Although filtering is possible, the approach you describe would require whole messages rather than parts to be filtered AFAICS. From ehrbar at greenhouse.economics.utah.edu Tue Aug 6 18:49:49 2013 From: ehrbar at greenhouse.economics.utah.edu (ehrbar at greenhouse.economics.utah.edu) Date: Tue, 06 Aug 2013 10:49:49 -0600 Subject: [Mailman-Developers] A list of discussion topics: GSoC OpenPGP Integration In-Reply-To: <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) References: <878v2cc4mw.fsf@phoenix.mshall.iitkgp.ernet.in> <87ppvn5nh9.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: I am not an expert but the encryption discussion is extremely important. Are you familiar with the Secure Email Lists (SELS) project? If not, drop everything and look at it at right now http://sels.ncsa.illinois.edu/index.html http://www.ncsa.illinois.edu/People/hkhurana/SAC05_1.pdf To my limited understanding it seems to have the perfect solution for mailing lists. Instead of decrypting the messages and re-encrypting them, the mailing list server simply changes the keys needed to read the message without having access to the content of the messages. For this feat to be possible, the mailing list administrator receives the keys from the subscribers and re-issues a different key to each subscriber. I.e., the mailing list administrator must be a trusted person, but the server does not have to be trusted. I think this is often the situation with mailing lists. From skimming your messages I did not have the sense that you were discussing such a paradigm. Perhaps you are discussing it and I didn't get it, or you have good reasons not to. You don't have to reply to me if I am saying something obvious or stupid. But if you are not even familiar with this approach, I urge you to look at it. Thank you for all the great work you are doing. Hans G Ehrbar From terri at zone12.com Wed Aug 7 22:41:20 2013 From: terri at zone12.com (Terri Oda) Date: Wed, 07 Aug 2013 14:41:20 -0600 Subject: [Mailman-Developers] Wiki Migration Update In-Reply-To: <51F3130D.5040100@msapiro.net> References: <201307190115.39468.paul@boddie.org.uk> <20130726155914.5ecfd817@anarchist> <201307270038.23292.paul@boddie.org.uk> <51F3130D.5040100@msapiro.net> Message-ID: <5202B0F0.6010302@zone12.com> On 07/26/2013 06:23 PM, Mark Sapiro wrote: > I'm only one data point, but pretty much the only thing I use the > dashboard for is seeing the recently updated pages, both to see what's > going on and check for spam. I'm perfectly happy with Moin's > RecentChanges page for this. I guess I can be data point number 2: I also mostly use the dashboard for seeing recent stuff, either what's going on or spam, so RecentChanges will also work for me too. Terri From truongvunghia at gmail.com Fri Aug 9 15:52:00 2013 From: truongvunghia at gmail.com (VuNghia Truong) Date: Fri, 9 Aug 2013 14:52:00 +0100 Subject: [Mailman-Developers] How to check whether the message is new thread! Message-ID: Hi guys, Could any one please give me advices about how to check if a message is a new thread or just a reply to a thread? Thanks Nghia From Ralf.Hildebrandt at charite.de Fri Aug 9 16:05:14 2013 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Fri, 9 Aug 2013 16:05:14 +0200 Subject: [Mailman-Developers] How to check whether the message is new thread! In-Reply-To: References: Message-ID: <20130809140514.GZ3081@charite.de> * VuNghia Truong : > Hi guys, > Could any one please give me advices about how to check if a message is a > new thread or just a reply to a thread? If a "References:" header is there, it's referencing an older message, thus it's a reply to a thread -- Ralf Hildebrandt Charite Universit?tsmedizin Berlin ralf.hildebrandt at charite.de Campus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Gesch?ftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155 From nkarageuzian at gmail.com Fri Aug 9 11:29:53 2013 From: nkarageuzian at gmail.com (nkarageuzian at gmail.com) Date: Fri, 9 Aug 2013 11:29:53 +0200 Subject: [Mailman-Developers] Mailman 3.0 todo list Message-ID: Hi, I'm looking forward mailman 3 to find efficient archive UI, with posting from web feature (just like in http://groupserver.org/) I don't know if it's in the roadmap, from the archive i can read The archiver and the web interface are at best early beta, but there are running prototypes. You can substitute a 3rd party service likemail-archive.com if that is satisfactory. ( ref http://mail.python.org/pipermail/mailman-developers/2013-July/023197.html) and in the todo (http://wiki.list.org/display/DEV/Mailman+3.0) i've read the paragraph about archiving but not found mention of such feature. I'm confident with python and could start some points, but i may need orientation or tricks to start over. I've cloned the repository mailman and watched the src/mailman/archiving dir. Looks like a good starting point for inserting messages in postgresql. The questions i have are : Should i consider pipermail or Postorious for rendering ? or start brand new project for dynamic and interactive web archive interface ? Best regards -- Nicolas Karageuzian http://nico.karageuzian.com/ Je soutiens les logiciels libres, j'adh?re ? l'APRIL http://www.april.org Nouvelles de l'APRIL http://planet.april.org/ From stephen at xemacs.org Sat Aug 10 17:07:26 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sun, 11 Aug 2013 00:07:26 +0900 Subject: [Mailman-Developers] How to check whether the message is new thread! In-Reply-To: References: Message-ID: <87zjspk2j5.fsf@uwakimon.sk.tsukuba.ac.jp> VuNghia Truong writes: > Could any one please give me advices about how to check if a message is a > new thread or just a reply to a thread? Check for a References: header or an In-Reply-To: header. These headers contain message ids from the thread. If they aren't present, the message starts a new thread. Technically, the presence of these headers *defines* "thread". In practice, you may also want to group messages with the same subject in the thread. However, there is no good way to determine order without the References or In-Reply-To header, so for most lists it is not worth the extra effort to analyze two headers to see if they're really the same after stripping out various prefixes and affixes added by software along the way. Steve From stephen at xemacs.org Mon Aug 12 15:30:59 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 12 Aug 2013 22:30:59 +0900 Subject: [Mailman-Developers] Mailman 3.0 todo list In-Reply-To: References: Message-ID: <87ob93jass.fsf@uwakimon.sk.tsukuba.ac.jp> nkarageuzian at gmail.com writes: > I'm looking forward mailman 3 to find efficient archive UI, with posting > from web feature (just like in http://groupserver.org/) I don't see a reply, so even though I'm not the best person to answer this I'll take a hack at it. There were two or three proposals related to this feature for GSoC this year. The one directly targeting this feature didn't make the cut. There's another, more ambitious, project to create a user interface for reading, posting, archive browsing, and user profile updates, which is being supervised by a mentor from the Systers. However, neither of these seems like it will be ready for prime time soon. I don't think the student who proposed the feature to Mailman was serious about it, he was just hoping to get a GSoC internship. I doubt he's working on it (anyway, we haven't heard a peep from him since). The Systers student is working on something specifically for use of Systers, and I don't know whether we can integrate it into Mailman 3 directly. > Should i consider pipermail or Postorious for rendering ? Pipermail is dead. Postorius is an option for UI, but it's not really about viewing or posting messages, it's more for admin (both list and user profiles). The archive manager under development currently is HyperKitty, which you can find out more about from https://github.com/hyperkitty/hyperkitty. Steve From nkarageuzian at gmail.com Mon Aug 12 15:35:58 2013 From: nkarageuzian at gmail.com (nkarageuzian at gmail.com) Date: Mon, 12 Aug 2013 15:35:58 +0200 Subject: [Mailman-Developers] Mailman 3.0 todo list In-Reply-To: <87ob93jass.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87ob93jass.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Hi Steeve, Thank-you for spending some time answering my noob question. I've found hyperkitty after reading many docs. It's great and i have submitted pull request for it. Best regards 2013/8/12 Stephen J. Turnbull > nkarageuzian at gmail.com writes: > > > I'm looking forward mailman 3 to find efficient archive UI, with posting > > from web feature (just like in http://groupserver.org/) > > I don't see a reply, so even though I'm not the best person to answer > this I'll take a hack at it. > > There were two or three proposals related to this feature for GSoC > this year. The one directly targeting this feature didn't make the > cut. There's another, more ambitious, project to create a user > interface for reading, posting, archive browsing, and user profile > updates, which is being supervised by a mentor from the Systers. > > However, neither of these seems like it will be ready for prime time > soon. I don't think the student who proposed the feature to Mailman > was serious about it, he was just hoping to get a GSoC internship. I > doubt he's working on it (anyway, we haven't heard a peep from him > since). The Systers student is working on something specifically for > use of Systers, and I don't know whether we can integrate it into > Mailman 3 directly. > > > Should i consider pipermail or Postorious for rendering ? > > Pipermail is dead. Postorius is an option for UI, but it's not really > about viewing or posting messages, it's more for admin (both list and > user profiles). The archive manager under development currently is > HyperKitty, which you can find out more about from > https://github.com/hyperkitty/hyperkitty. > > Steve > -- Nicolas Karageuzian http://nico.karageuzian.com/ Je soutiens les logiciels libres, j'adh?re ? l'APRIL http://www.april.org Nouvelles de l'APRIL http://planet.april.org/ From truongvunghia at gmail.com Tue Aug 13 01:21:29 2013 From: truongvunghia at gmail.com (Nghia Vu Truong) Date: Tue, 13 Aug 2013 00:21:29 +0100 Subject: [Mailman-Developers] How to send out the whole archive of a thread to a member Message-ID: <52096DF9.3010100@gmail.com> Hi everyone, Could you please give me guidances about how to send a thread's archives to a specific member? Thanks From mark at msapiro.net Tue Aug 13 01:31:04 2013 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 12 Aug 2013 16:31:04 -0700 Subject: [Mailman-Developers] How to send out the whole archive of a thread to a member In-Reply-To: <52096DF9.3010100@gmail.com> References: <52096DF9.3010100@gmail.com> Message-ID: <52097038.8050002@msapiro.net> On 08/12/2013 04:21 PM, Nghia Vu Truong wrote: > > Could you please give me guidances about how to send a thread's archives > to a specific member? How about just sending the URL of the first message in the thread and letting the recipient follow the 'next' links to see the rest? -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From raj.abhilash1 at gmail.com Tue Aug 13 16:46:07 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Tue, 13 Aug 2013 20:16:07 +0530 Subject: [Mailman-Developers] GSoC Updates Message-ID: <520A46AF.70400@gmail.com> Hi all, After midterm evaluations I have been working on signing the message using one the keys associated with the list, now since `python-gnupg` does not allow selecting keys with key credentials( like address or list-name name) so we need key_id. As barry suggested we can create a mapping of address to key_ids and store in a seperate table. I was of the opinion that we need key_ids only for signing the content and hence need to select only list's keys and not user, so can we add a new column `key_id` to the existing list table? So that the key_id is easily accessible as a list parameter and can be easily updated. One point in this would be should we allow more than one key associated with a user( or address? ). Any comments on this? (barry?) Also I understand that keeping key safe is one of the important tasks but for the time-being I am simply adding the public and secret keyrings in "VAR_DIR/gpg/", all the list's private keys are in `secring.gpg` and all the list's public keys are in `pubring.gpg` and all the user's public keys are in `userring.gpg`. It will be changed to keep the secret keys at a more safer location. --- Abhilash Raj From rkw at dataplex.net Tue Aug 13 17:43:07 2013 From: rkw at dataplex.net (Richard Wackerbarth) Date: Tue, 13 Aug 2013 10:43:07 -0500 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <520A46AF.70400@gmail.com> References: <520A46AF.70400@gmail.com> Message-ID: Abhilash, I see no reason to have more that one keyring for public keys and another for the private ones. In both cases, those key rings are a flat table indexed by the Key_id. It doesn't matter if the "owner" of the key is a list or a subscriber (or any other user) As for user keys, I think that they should be treated as a ManyToMany relation between the public keys and either the lists or users or, perhaps the subscriptions, in a manner similar to the way that Email addresses are associated with a user. Wacky On Aug 13, 2013, at 9:46 AM, Abhilash Raj wrote: > Hi all, > > After midterm evaluations I have been working on signing the message > using one the keys associated with the list, now since `python-gnupg` > does not allow selecting keys with key credentials( like address or > list-name name) so we need key_id. As barry suggested we can create a > mapping of address to key_ids and store in a seperate table. > > I was of the opinion that we need key_ids only for signing the content > and hence need to select only list's keys and not user, so can we add a > new column `key_id` to the existing list table? So that the key_id is > easily accessible as a list parameter and can be easily updated. One > point in this would be should we allow more than one key associated with > a user( or address? ). > Any comments on this? (barry?) > > Also I understand that keeping key safe is one of the important tasks > but for the time-being I am simply adding the public and secret keyrings > in "VAR_DIR/gpg/", all the list's private keys are in `secring.gpg` and > all the list's public keys are in `pubring.gpg` and all the user's > public keys are in `userring.gpg`. It will be changed to keep the secret > keys at a more safer location. > > --- > Abhilash Raj > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/rkw%40dataplex.net > > Security Policy: http://wiki.list.org/x/QIA9 From stephen at xemacs.org Wed Aug 14 10:35:02 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 14 Aug 2013 17:35:02 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <520A46AF.70400@gmail.com> References: <520A46AF.70400@gmail.com> Message-ID: <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > After midterm evaluations I have been working on signing the message > using one the keys associated with the list, now since `python-gnupg` > does not allow selecting keys with key credentials( like address or > list-name name) Have you tried this? In the GPG documentation, "key ID" often actually means any of the above.[1] If python-gnupg simply passes its argument to the gpg process, it should Just Work. Anyway, it seems to work for me (some output edited for clarity): venv27 abhilash 15:39$ python2.7 Python 2.7.5 (default, Aug 1 2013, 23:58:20) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. No entry for terminal type "emacs"; using dumb terminal settings. >>> from gnupg import GPG >>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') >>> gpg.list_keys() [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', 'ownertrust': u'u', 'algo': u'1', 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', 'date': u'1376462161', 'trust': u'-', 'type': u'pub', 'uids': [u'GPG Test User ']}, {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', 'ownertrust': u'-', 'algo': u'17', 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', 'date': u'1183228371', 'trust': u'-', 'type': u'pub', 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) ']}] >>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen at xemacs.org', always_trust=True) >>> str(crypted) '-----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.14 (Darwin) hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841 MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3 CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/ 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA= =olXg -----END PGP MESSAGE----- ' >>> of = open ('/tmp/cryptfile', 'w') >>> of.write(str(crypted)) >>> of.close() >>> signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester at turnbull.sk.tsukuba.ac.jp') >>> str(signed) '-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A bit of random text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo= =qHjE -----END PGP SIGNATURE----- ' >>> Decryption of the encrypted file works. I didn't verify the signature, but it looks like it's working. > Also I understand that keeping key safe is one of the important > tasks but for the time-being I am simply adding the public and > secret keyrings in "VAR_DIR/gpg/", all the list's private keys are > in `secring.gpg` and all the list's public keys are in > `pubring.gpg` and all the user's public keys are in > `userring.gpg`. It will be changed to keep the secret keys at a > more safer location. I agree with Richard that there's no particular reason to do anything but put the public keys on one ring. I don't see any point in putting the private keys somewhere else. As I wrote elsewhere, the weak point in the private keys is the need to supply a password, not the location of the file containing the key. I wonder if there may not be a way to do this using agent forwarding so that the private keys are kept on a different host. The only issue I can see is that *if* at some point it becomes feasible to use agent forwarding, I suspect only one agent can be used per GPG subprocess. Footnotes: [1] Has anybody else noticed that both gpg's UI and its documentation seem designed to make it as hard to use as possible? From barry at list.org Thu Aug 15 00:26:31 2013 From: barry at list.org (Barry Warsaw) Date: Wed, 14 Aug 2013 18:26:31 -0400 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20130814182631.542b4bd6@anarchist> I agree with everything written elsewhere by Steve and Richard. On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote: >[1] Has anybody else noticed that both gpg's UI and its documentation >seem designed to make it as hard to use as possible? Sadly, I think this is one of the biggest reasons why we've never seen widespread adoption of signatures and encryption in email. I'll ignore nefarious reasons like authors of MUAs-for-the-masses in deliberate collusion to make it difficult for the non-Snowdens of the world. In any case, I've always heard that gpg deliberately does not expose a programmable API that e.g. could be wrapped by Python. They only provide a command line API because they think that's the best way to avoid incorrect use in language bindings. They're probably not wrong about that. In any case, tools like python-gnupg are essentially glorified subprocess wrappers around the gpg cli, because there's no other way to do it. -Barry From terri at zone12.com Thu Aug 15 05:34:17 2013 From: terri at zone12.com (Terri Oda) Date: Wed, 14 Aug 2013 21:34:17 -0600 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <520C4C39.8040606@zone12.com> On 13-08-14 2:35 AM, Stephen J. Turnbull wrote: > Footnotes: [1] Has anybody else noticed that both gpg's UI and its > documentation seem designed to make it as hard to use as possible? Not only have people noticed, but " Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0" is often required reading for computer security students at Carleton because it serves as a great example of how poor usability can render carefully designed encryption and security completely worthless. " The analysis found a number of user interface design flaws that may contribute to security failures, and the user test demonstrated that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully. " If you haven't read it, I highly recommend it. It's an easy read, freely available online, and very educational. Obviously this is especially of interest to those talking about PGP and mailman, but it's a good read for anyone who works with code: https://www.usenix.org/legacy/events/sec99/whitten.html Terri From stephen at xemacs.org Thu Aug 15 07:01:42 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 15 Aug 2013 14:01:42 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <20130814182631.542b4bd6@anarchist> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <20130814182631.542b4bd6@anarchist> Message-ID: <87txirim2x.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > On Aug 14, 2013, at 05:35 PM, Stephen J. Turnbull wrote: > > >[1] Has anybody else noticed that both gpg's UI and its documentation > >seem designed to make it as hard to use as possible? > > Sadly, I think this is one of the biggest reasons why we've never > seen widespread adoption of signatures and encryption in email. Sure, but the wrappers I've seen don't really help. I get the feeling that they are basically designed around smebody's personal needs with all kinds of bags and kludges added on request. Maybe you can sprinkle RDM with itch powder the next time you see him? I bet he could do for a gpg wrapper what he's done for the email package! }:-} From stephen at xemacs.org Fri Aug 16 09:00:56 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 16 Aug 2013 16:00:56 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <520DC450.4010703@gmail.com> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <520CE253.1040202@gmail.com> <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> <520DC450.4010703@gmail.com> Message-ID: <87d2pei0gn.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > But can we achieve required randomization to create keys on virtualized > systems? Not your problem. We can do it on physical hosts, and that's good enough. People who care this much about security will be prepared to pay for it. Generalizing to handle sites that need security but don't care (yet) is Somebody Else's Problem (maybe even you, but in a post- GSoC avatar). "Requirements creep" is identified as one of the most important causes of project failure. Learn to say "No." where possible, "It will cost you USD1,000,000 and 36 months." if you must. (Of course in the latter case you'll replace those numbers with accurate ones. :-) > Okay then we can just suggest not to use md5. Yes. For now, your job is to get the system working and working securely. The defaults for key-generation are fine. > > > Also one more thing while running tests i noticed many other > > > tests are breaking as initially a simple message could pass > > > though "default-posting-chain" but now we need a > > > multipart/signed message. So should I worry about changing all > > > other tests? > > > > Yes. Conventionally that is the responsibility of the person who adds > > a feature. However, there's nothing that says you can't ask Barry for > > help. He may know a way to do it quickly. > > Barry anything here? I guess you didn't notice that you didn't reply to the list? Mailman project lists don't mung Reply-To, you need to reply to list (if your MUA has the function) or reply to all. From raj.abhilash1 at gmail.com Fri Aug 16 11:42:07 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 16 Aug 2013 15:12:07 +0530 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <520CE253.1040202@gmail.com> References: <520CE253.1040202@gmail.com> Message-ID: <520DF3EF.9040605@gmail.com> -------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Thu, 15 Aug 2013 19:44:43 +0530 From: Abhilash Raj To: Stephen J. Turnbull Thanks for the replies, I tried working on it and it was good enough to be used for now. Thanks Steve for trying it yourself. I have another few set of question now as I move towards signing and a few answers to it also(which may be wrong please correct me). 1) How do list owner create keys? What parameters? Which address? I think I will write a small doc on how to create key via command line in linux using gnupg and copy paste the ascii armoured text to postorious ui(which will be created soon). About the address I think owner can create a key using posting address with a min key length of 1024? or else mailman rejects the key? MD5 hash should be discouraged and at least SHA1 should be used?(although I found this[1] that even sha1 should not be used) 2) RSA or DSA keys? DSA can only be used for signing but is faster than RSA, although for now our scope is limited to signing later on we "will" add encryption so I think we should stick to RSA? 3) How to manage paraphrase(or passwords) for keys? In previous discussions we decided to use gnupg-agent and I although I haven't tried it. Any other suggestions to it? Also one more thing while running tests i noticed many other tests are breaking as initially a simple message could pass though "default-posting-chain" but now we need a multipart/signed message. So should I worry about changing all other tests? --- Abhilash Raj [1]: http://lwn.net/Articles/337745/ On Wednesday 14 August 2013 02:05 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > After midterm evaluations I have been working on signing the message > > using one the keys associated with the list, now since `python-gnupg` > > does not allow selecting keys with key credentials( like address or > > list-name name) > > Have you tried this? In the GPG documentation, "key ID" often > actually means any of the above.[1] If python-gnupg simply passes its > argument to the gpg process, it should Just Work. Anyway, it seems to > work for me (some output edited for clarity): > > venv27 abhilash 15:39$ python2.7 > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > No entry for terminal type "emacs"; > using dumb terminal settings. >>>> from gnupg import GPG >>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') >>>> gpg.list_keys() > [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', > 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', > 'ownertrust': u'u', 'algo': u'1', > 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', > 'date': u'1376462161', 'trust': u'-', 'type': u'pub', > 'uids': [u'GPG Test User ']}, > {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', > 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', > 'ownertrust': u'-', 'algo': u'17', > 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', > 'date': u'1183228371', 'trust': u'-', 'type': u'pub', > 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) ']}] >>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen at xemacs.org', always_trust=True) >>>> str(crypted) > '-----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.14 > (Darwin) > > hQIOAxjgOuNvO22tEAgAgPUFFCFDKe8zSWt42IG7LkLWWbbTCiAsO7aM2pEgtFrI > KxRklwvEOX7bj5cYbmGr1PeM2IH58T4gMMHsYuOUyNzxS1mbsXZ9C4rpE0QJSkPY > +5Z10dpHEyAZ030g6uBeubFHC+78as1s10UP16zlVgs2AeZwfM88OBocs7FmUdZr > X5uAUxpB5RGET/zc2uHvBzIigXTzUrS8LrTtPfhyP8jCia6klX/2+2Q3gPlENoaP > PkIx/vZ7aKCIKyoP+pbLlwGAb/CX1WoQgyrsNFApg/HJhZ3ZLYKcvIqO3PNejOcN > 8ZYLRV4Uz0tLCuALCccw+XEZSQTKBoemXqVUwSKCAAf+OiHpMqDMoO7ReVVZg841 > MnRcZzfUnL8mj1FZwnr3iTcQ7BdUbu5vMAjn0SIlBISquu0rZi+wynGwgSpWnJeF > Llh+gjizNuHUxtO96phbwMeyVrD1yKSxkxC9cY0r8NBo/MTwUmyMCHNKpj0qrome > GZI2ekhYjLWfAbX3c6dwBx7pQhwkHkgMmoY6yN0OpLf1urnHGpv+AsEwDmWZ8mz3 > CLtD/l9eMl4LGIHNSV7yQ4lAzhYMenNdxkYJyKtxEvM1BFdqOblRb/h+B3X/xtT/ > 6ATAK1mZz1nU4H2EB1EvS4rbbQJ6oIevQSz3r/G6jSI7PqPDJvhnzQBrN7wh1pep > ldJQASeq3bCushTnFolWVxOgswXm2VFMPnhqEVxBJrZ12nZO2LGN7Y2/W+qQ/Qqb > DdYqbYOXNFW9r9p7ugJKKD1kK3XUkTC0Y+t1I/a7dLJBvpA= > =olXg > -----END PGP MESSAGE----- > ' >>>> of = open ('/tmp/cryptfile', 'w') >>>> of.write(str(crypted)) >>>> of.close() >>>> signed = gpg.sign('A bit of random text.', passphrase=u'Not useful without my keyring.', keyid=u'gpg-tester at turnbull.sk.tsukuba.ac.jp') >>>> str(signed) > '-----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A bit of random text. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 > (Darwin) > > iQEcBAEBAgAGBQJSCz30AAoJEBeoEMM73++oWGcH/jS3AJ6OZLm8JHiLAI0AzCXe > muRVhPPfGrqL/Jr+l9WA8Zj3pClHa04H0ha3nvYFHPhN30lFDDw56iCPMA+DbJbr > 2BeqUSfJj36EGHOi8yV5iljZA4NhAw9qqhwQz7kas+KTeY8+98DQDS10ixVZ92Gv > NDxQCKcyTj+6leqy3ePRAgXP5DouTGXntupzPQzcbQW6L8X6h6STOiLAAGKXpGJm > t4Fruvbb3kAcqDGCp5Y9kLrxd1unlCp9leoeJeG5NZ5IcI2B4qUwqKdydu9ZMJxS > kJYJR1ZNVMtQh/kMNA87GMNv4nd8d5QPD+bm5b4L5BDlibzMGb5Q80mJAKD5xqo= > =qHjE > -----END > PGP SIGNATURE----- > ' >>>> > > Decryption of the encrypted file works. I didn't verify the > signature, but it looks like it's working. > > > Also I understand that keeping key safe is one of the important > > tasks but for the time-being I am simply adding the public and > > secret keyrings in "VAR_DIR/gpg/", all the list's private keys are > > in `secring.gpg` and all the list's public keys are in > > `pubring.gpg` and all the user's public keys are in > > `userring.gpg`. It will be changed to keep the secret keys at a > > more safer location. > > I agree with Richard that there's no particular reason to do anything > but put the public keys on one ring. > > I don't see any point in putting the private keys somewhere else. As I > wrote elsewhere, the weak point in the private keys is the need to > supply a password, not the location of the file containing the key. I > wonder if there may not be a way to do this using agent forwarding so > that the private keys are kept on a different host. > > The only issue I can see is that *if* at some point it becomes > feasible to use agent forwarding, I suspect only one agent can be used > per GPG subprocess. > > > Footnotes: > [1] Has anybody else noticed that both gpg's UI and its documentation > seem designed to make it as hard to use as possible? > From raj.abhilash1 at gmail.com Fri Aug 16 11:43:42 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 16 Aug 2013 15:13:42 +0530 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <520DC450.4010703@gmail.com> References: <520DC450.4010703@gmail.com> Message-ID: <520DF44E.5030100@gmail.com> -------- Original Message -------- Subject: Re: [Mailman-Developers] GSoC Updates Date: Fri, 16 Aug 2013 11:48:56 +0530 From: Abhilash Raj To: Stephen J. Turnbull On Friday 16 August 2013 10:35 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > 1) How do list owner create keys? What parameters? Which address? > > python-gnupg provides a key-generation API, GPG.gen_key(). > Alternatively, this could be done manually by the trusted > site-manager. The web UI would have to run over SSL, presumably > HTTPS. But can we achieve required randomization to create keys on virtualized systems? This was the reason it was suggested before that keys are uploaded by the site owners when they create new lists. > I think the address should be $LIST-owner at fqdn. For other parameters, > defaults are OK I think (size=2048, type=RSA IIRC). > > > About the address I think owner can create a key using posting > > address with a min key length of 1024? or else mailman rejects the > > key? MD5 hash should be discouraged and at least SHA1 should be > > used? (although I found this[1] that even sha1 should not be used) > > Nobody short of a major government can afford to break private keys or > crypto hashes on a regular basis. Otherwise, before they try to break > SHA1, they'll kidnap and torture you (I'm serious about the > calculation they'll make, not that I think it will happen to anybody > we know for several thousand years). Okay then we can just suggest not to use md5. > > 3) How to manage paraphrase(or passwords) for keys? > > > > In previous discussions we decided to use gnupg-agent and I > > although I haven't tried it. Any other suggestions to it? > > I really don't know. As you probably know, files containing host keys > for SSH and other SSL applications don't have passwords, but are > simply made readable only by root. That might be the appropriate > solution here. Otherwise, any reboot takes all lists down until the > owner can be tracked down. > > > Also one more thing while running tests i noticed many other tests are > > breaking as initially a simple message could pass though > > "default-posting-chain" but now we need a multipart/signed message. So > > should I worry about changing all other tests? > > Yes. Conventionally that is the responsibility of the person who adds > a feature. However, there's nothing that says you can't ask Barry for > help. He may know a way to do it quickly. Barry anything here? From raj.abhilash1 at gmail.com Fri Aug 16 13:34:20 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 16 Aug 2013 17:04:20 +0530 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87d2pei0gn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <520CE253.1040202@gmail.com> <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> <520DC450.4010703@gmail.com> <87d2pei0gn.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <520E0E3C.1000406@gmail.com> On Friday 16 August 2013 12:30 PM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > But can we achieve required randomization to create keys on virtualized > > systems? > > Not your problem. We can do it on physical hosts, and that's good > enough. People who care this much about security will be prepared to > pay for it. Generalizing to handle sites that need security but don't > care (yet) is Somebody Else's Problem (maybe even you, but in a post- > GSoC avatar). > > "Requirements creep" is identified as one of the most important causes > of project failure. Learn to say "No." where possible, "It will cost > you USD1,000,000 and 36 months." if you must. (Of course in the > latter case you'll replace those numbers with accurate ones. :-) Then i guess I will simply create a new key with list's credentials when the list is created, for the users I will import key from any public server and also give an option to upload pubic key data? > > Okay then we can just suggest not to use md5. > > Yes. For now, your job is to get the system working and working > securely. The defaults for key-generation are fine. > > > > > Also one more thing while running tests i noticed many other > > > > tests are breaking as initially a simple message could pass > > > > though "default-posting-chain" but now we need a > > > > multipart/signed message. So should I worry about changing all > > > > other tests? > > > > > > Yes. Conventionally that is the responsibility of the person who adds > > > a feature. However, there's nothing that says you can't ask Barry for > > > help. He may know a way to do it quickly. > > > > Barry anything here? > > I guess you didn't notice that you didn't reply to the list? Mailman > project lists don't mung Reply-To, you need to reply to list (if your > MUA has the function) or reply to all. I forwarded two mails to the list which i sent to you by mistake. --- Abhilash Raj From raj.abhilash1 at gmail.com Fri Aug 16 13:41:54 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 16 Aug 2013 17:11:54 +0530 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <520CE253.1040202@gmail.com> <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <520E1002.7010403@gmail.com> On Friday 16 August 2013 10:35 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > 1) How do list owner create keys? What parameters? Which address? > > python-gnupg provides a key-generation API, GPG.gen_key(). > Alternatively, this could be done manually by the trusted > site-manager. The web UI would have to run over SSL, presumably > HTTPS. > > I think the address should be $LIST-owner at fqdn. For other parameters, > defaults are OK I think (size=2048, type=RSA IIRC). Here should not the address be the list's posting address? Like for mm-dev list should it not be "mailman-developers at python.org"? > > About the address I think owner can create a key using posting > > address with a min key length of 1024? or else mailman rejects the > > key? MD5 hash should be discouraged and at least SHA1 should be > > used? (although I found this[1] that even sha1 should not be used) > > Nobody short of a major government can afford to break private keys or > crypto hashes on a regular basis. Otherwise, before they try to break > SHA1, they'll kidnap and torture you (I'm serious about the > calculation they'll make, not that I think it will happen to anybody > we know for several thousand years). > > > 3) How to manage paraphrase(or passwords) for keys? > > > > In previous discussions we decided to use gnupg-agent and I > > although I haven't tried it. Any other suggestions to it? > > I really don't know. As you probably know, files containing host keys > for SSH and other SSL applications don't have passwords, but are > simply made readable only by root. That might be the appropriate > solution here. Otherwise, any reboot takes all lists down until the > owner can be tracked down. > > > Also one more thing while running tests i noticed many other tests are > > breaking as initially a simple message could pass though > > "default-posting-chain" but now we need a multipart/signed message. So > > should I worry about changing all other tests? > > Yes. Conventionally that is the responsibility of the person who adds > a feature. However, there's nothing that says you can't ask Barry for > help. He may know a way to do it quickly. > --- Abhilash Raj From stephen at xemacs.org Fri Aug 16 15:41:38 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 16 Aug 2013 22:41:38 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <520E1002.7010403@gmail.com> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <520CE253.1040202@gmail.com> <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> <520E1002.7010403@gmail.com> Message-ID: <877gfliwh9.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > > I think the address should be $LIST-owner at fqdn. For other parameters, > > defaults are OK I think (size=2048, type=RSA IIRC). > > Here should not the address be the list's posting address? Like for > mm-dev list should it not be "mailman-developers at python.org"? Maybe. But in most cases the sender is not going to be the list, and it's possible to configure the list so that the list-post address doesn't appear in the header. So I don't think it matters much. I just tend to associate signatures with people rather than bots. From stephen at xemacs.org Sat Aug 17 08:22:48 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Sat, 17 Aug 2013 15:22:48 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <520E0E3C.1000406@gmail.com> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <520CE253.1040202@gmail.com> <87eh9ui5sk.fsf@uwakimon.sk.tsukuba.ac.jp> <520DC450.4010703@gmail.com> <87d2pei0gn.fsf@uwakimon.sk.tsukuba.ac.jp> <520E0E3C.1000406@gmail.com> Message-ID: <87y580hm4n.fsf@uwakimon.sk.tsukuba.ac.jp> Abhilash Raj writes: > Then i guess I will simply create a new key with list's credentials > when the list is created, I really think that's best for nontechnical users. Read the article Terri cited on mailman-developers a few days ago. Adding an upload option (non-trivial to implement securely, maybe) or additional key_gen options for generation on the list host should be easy to do for any interested party. > for the users I will import key from any public server and also > give an option to upload pubic key data? Sounds good. From raj.abhilash1 at gmail.com Sun Aug 18 13:13:59 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Sun, 18 Aug 2013 16:43:59 +0530 Subject: [Mailman-Developers] Some Doubts for GSoC Project Message-ID: <5210AC77.6060404@gmail.com> Hi, I had a few doubts regarding the project, I din't see any reply on mm-dev so I mailed separately. Firstly what address should be used to create the keys for the lists? I was of the opinion that list' posting address should be used like 'mailman-developers at python.org' for mm-dev list. Steve had opinion that keys should be associated with people rather than bots so the address should be '$LIST-owner at fooo' type. Any thoughts?? Also Barry while running tests I see a few tests are failing because now simple message will not be able to pass the 'default-posting-chain' and 'multipart/signed' is requred. So should I change all the tests? ---- Abhilash Raj From truongvunghia at gmail.com Sun Aug 18 18:20:06 2013 From: truongvunghia at gmail.com (VuNghia Truong) Date: Sun, 18 Aug 2013 17:20:06 +0100 Subject: [Mailman-Developers] Send message having same "References" from archive Message-ID: Hi, Suppose that I have archive file, like "list_name.mbox". Now, I want to get the message with same "References" field, and send them out. How could I accomplish this problem? Thanks Nghia From stefan.schlott at ulm.ccc.de Sun Aug 18 18:56:11 2013 From: stefan.schlott at ulm.ccc.de (Stefan Schlott) Date: Sun, 18 Aug 2013 18:56:11 +0200 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <5210AC77.6060404@gmail.com> References: <5210AC77.6060404@gmail.com> Message-ID: <5210FCAB.6090201@ulm.ccc.de> Hi, > I had a few doubts regarding the project, I din't see any reply on > mm-dev so I mailed separately. Firstly what address should be used to > create the keys for the lists? I was of the opinion that list' posting > address should be used like 'mailman-developers at python.org' for mm-dev > list. Steve had opinion that keys should be associated with people > rather than bots so the address should be '$LIST-owner at fooo' type. > Any thoughts?? Definitely the address of the list. PGP support of MUAs uses the recipient's mail address for looking up the corresponding key. Not using the list address in the list key will break this assumption and make manual steps for each list post necessary. Stefan. From barry at list.org Mon Aug 19 20:19:19 2013 From: barry at list.org (Barry Warsaw) Date: Mon, 19 Aug 2013 14:19:19 -0400 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <5210AC77.6060404@gmail.com> References: <5210AC77.6060404@gmail.com> Message-ID: <20130819141919.670baafb@anarchist> On Aug 18, 2013, at 04:43 PM, Abhilash Raj wrote: >I had a few doubts regarding the project, I din't see any reply on >mm-dev so I mailed separately. Firstly what address should be used to >create the keys for the lists? I was of the opinion that list' posting >address should be used like 'mailman-developers at python.org' for mm-dev >list. Steve had opinion that keys should be associated with people >rather than bots so the address should be '$LIST-owner at fooo' type. >Any thoughts?? If I read the correct response from Steve, I don't think he was adamant about it. He basically said that he associates keys more with people than bots, but OTOH, -owner isn't really a person. I don't think using -owner is what folks would normally expect, so I think the posting address makes the most sense. (Would it be possible to use the list-id or does it have to be an actual email address? list-id is considered more stable than posting address.) >Also Barry while running tests I see a few tests are failing because now >simple message will not be able to pass the 'default-posting-chain' and > 'multipart/signed' is requred. So should I change all the tests? The test suite is a mess right now. The latest updates to various zope libraries have broken things for me. I am working on a branch to switch to a standard-ish virtualenv + nose{1,2} setup, which will include ensuring the test suite works again, at least for SQLite. Vacation schedules have delayed this a bit. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From truongvunghia at gmail.com Tue Aug 20 00:05:50 2013 From: truongvunghia at gmail.com (Nghia Vu Truong) Date: Mon, 19 Aug 2013 23:05:50 +0100 Subject: [Mailman-Developers] Get message content by message ID Message-ID: <521296BE.4030704@gmail.com> Hi there, Is there any way to get message's content based on its "Message ID"? Thanks Nghia From stephen at xemacs.org Tue Aug 20 04:52:35 2013 From: stephen at xemacs.org (Stephen 'Humble is my middle name' Turnbull) Date: Tue, 20 Aug 2013 11:52:35 +0900 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <20130819141919.670baafb@anarchist> References: <5210AC77.6060404@gmail.com> <20130819141919.670baafb@anarchist> Message-ID: <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > If I read the correct response from Steve, I don't think he was > adamant about it. He basically said that he associates keys more > with people than bots, but OTOH, -owner isn't really a person. I > don't think using -owner is what folks would normally expect, so I > think the posting address makes the most sense. I agree now. The point made in an earlier post is that in most cases people will use their keyrings to store keys, and addresses are the most stable way among human-readable key specifiers to access the keyring. Eg, suppose you're replying to me; my display name in this message won't help you find my key unless your MUA's parser is *very* "sophisticated" (ie, makes dangerous guesses). > (Would it be possible to use the list-id or does it have to be an > actual email address? list-id is considered more stable than > posting address.) List-Id could be used, but do you really think that anybody but larsi would implement fishing it out of the header and using it as the user name in a keyring? ;-)[1] This would also violate PKI user's expectations about the stability of names, slightly. Use of display names to access keyrings is normally interactive because a person can get that right -- she may remember the display name in the key for some reason, or use a partial-match accessor. Programs won't (well, maybe Prism would, but let's hope Prism doesn't have our keys at all!), but they will have immediate access to something that *can't* be misspelled and still be useful (ie, the email address). >> Also Barry while running tests I see a few tests are failing >> because now simple message will not be able to pass the >> 'default-posting-chain' and 'multipart/signed' is requred. So >> should I change all the tests? > > The test suite is a mess right now. Translated into pragmatic terms: Don't bother fixing the leaky roof because Barry's about to bulldoze the house. VCS implication: your branch will have hard-to-fix conflicts throughout the test suite. Footnotes: [1] Lars "larsi" Ingebrittsen is the main developer of the Gnus MUA for Emacs, known for implementing features first (the IETF thanks you) and for much-too-clever code. From stephen at xemacs.org Tue Aug 20 05:05:19 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 20 Aug 2013 12:05:19 +0900 Subject: [Mailman-Developers] Get message content by message ID In-Reply-To: <521296BE.4030704@gmail.com> References: <521296BE.4030704@gmail.com> Message-ID: <877gfhgiz4.fsf@uwakimon.sk.tsukuba.ac.jp> Nghia Vu Truong writes: > Is there any way to get message's content based on its "Message ID"? That depends on where the message is stored and what features that store implements, and where and how you want to fetch messages by message ID. If you're using a "standard" Mailman installation with the bundled archiver and no third-party software, the answer is "no". Specifically, in the case of Mailman 2, there is an internal store for the queues while processing the messages, but no way to access queue items by message ID. Most sites use the bundled "pipermail" archiver to store archives for access by list subscribers and the general public. It provides no search features at all, so there is no way to search on message ID. In the case of Mailman 3 (in development), the same analysis applies to queue items AFAICS, and there is no bundled archive manager. The most likely candidate for recommended (and possibly bundled) archive manager for Mailman 3 is "HyperKitty". You'd have to ask its developers (but it's not ready for beta test yet AFAIK). If you're using a third-party archiver with search features, the answer is probably "yes", but we can't help you with third-party archivers (at least, I can't). From barry at list.org Wed Aug 21 04:05:03 2013 From: barry at list.org (Barry Warsaw) Date: Tue, 20 Aug 2013 22:05:03 -0400 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5210AC77.6060404@gmail.com> <20130819141919.670baafb@anarchist> <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <20130820220503.451bc491@anarchist> On Aug 20, 2013, at 11:52 AM, Stephen 'Humble is my middle name' Turnbull wrote: Actually, it seems like "Humble is my middle name" is your middle name. :) >I agree now. The point made in an earlier post is that in most cases >people will use their keyrings to store keys, and addresses are the >most stable way among human-readable key specifiers to access the >keyring. Eg, suppose you're replying to me; my display name in this >message won't help you find my key unless your MUA's parser is *very* >"sophisticated" (ie, makes dangerous guesses). Agreed. > > The test suite is a mess right now. > >Translated into pragmatic terms: Don't bother fixing the leaky roof >because Barry's about to bulldoze the house. VCS implication: your >branch will have hard-to-fix conflicts throughout the test suite. We'll see, but I'm hopeful now that it may not be so bad. My first branch using nose was brutal, but nose2 has support for zope.testing-ish layers. I haven't gotten the doctests working yet, but everything else seems to have gone quite smoothly with few changes to the code. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Wed Aug 21 10:15:01 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 21 Aug 2013 17:15:01 +0900 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <20130820220503.451bc491@anarchist> References: <5210AC77.6060404@gmail.com> <20130819141919.670baafb@anarchist> <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> <20130820220503.451bc491@anarchist> Message-ID: <87ppt7foje.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > We'll see, but I'm hopeful now that it may not be so bad. My first branch > using nose was brutal, but nose2 has support for zope.testing-ish layers. I > haven't gotten the doctests working yet, but everything else seems to have > gone quite smoothly with few changes to the code. That's good news! Still, there's no point in either of you making work for the other by messing with the tests at the same time. From mgill25 at outlook.com Wed Aug 21 15:09:04 2013 From: mgill25 at outlook.com (Manish Gill) Date: Wed, 21 Aug 2013 18:39:04 +0530 Subject: [Mailman-Developers] Mailman REST API: How to change preferences? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm having some trouble in interacting with preferences as they are exposed via Mailman's REST API. As I understand from the documentation, preferences have various "fallbacks" so a value is always available even if it is not present for an upper level. This goes as: member -> address -> user -> system. Onwards to the problem: To change a value in the preferences of a membership. It would seem that the membership preferences (accessible via "/members/id/all/preferences") are set as read-only. So when I do this: >>> requests.patch(url, data={'delivery_mode': "digest"}, >>> auth=auth) It returns 405. Although we can modify "delivery_mode" if we access "/members/id/preferences". So how do I change those other values? I can try and convert them on the Address, or the User, but those are not specific enough. Something like Address would change them for *all* the subscriptions on that email address, which is not the goal here. And maybe I'm missing something, but it would also seem that changing them on a address would be pointless if we have a membership, since, as the docs say, precedence is given to the membership preferences (which can't be modified). So, why are membership preferences read-only and is there anything I can do about that? Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFLvwAAoJEDTnrae/jUU9gOgH/R0/KcXyNv6hE/gWiT4JN9Vs lranOJ8Iu45iEPbHUP1OZ1V+qJtr7GIAMH+oN/n0dK7lWMTDWmx3tKowaXWODt6t 6DVFceyMItwPUTaIiWI8xtmjZWbBhbNTc11dsaDMcEbegrPLur2QtdQYpnHFXO9x EgBe4F6ZGdLhFxIy0xwmMupTtJRG/1c00r5LCSIhMQrZ5n1ywFZEG7WRMX9hj1sB qKuTMGnGS1ydLnJrQ0RmbEstHWk9AuzxWzlP+1k+LBcdA3X6t5GvedM61Jz+6uTA cPRBNRZSZZLaWXQheXGnnKZ1ioY3EX7YhhAp4sRvspKqvQVTEt2MNmKgBzktP7I= =ysZD -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Wed Aug 21 18:42:32 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 21 Aug 2013 12:42:32 -0400 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5210AC77.6060404@gmail.com> <20130819141919.670baafb@anarchist> <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5214EDF8.6080209@fifthhorseman.net> On 08/19/2013 10:52 PM, Stephen 'Humble is my middle name' Turnbull wrote: > Barry Warsaw writes: > > > If I read the correct response from Steve, I don't think he was > > adamant about it. He basically said that he associates keys more > > with people than bots, but OTOH, -owner isn't really a person. I > > don't think using -owner is what folks would normally expect, so I > > think the posting address makes the most sense. > > I agree now. The point made in an earlier post is that in most cases > people will use their keyrings to store keys, and addresses are the > most stable way among human-readable key specifiers to access the > keyring. Eg, suppose you're replying to me; my display name in this > message won't help you find my key unless your MUA's parser is *very* > "sophisticated" (ie, makes dangerous guesses). fwiw, i also agree with the earlier commenters that the list's e-mail address is the appropriate address for the list key's User ID. that's what's used in every schleuder list that i've ever seen as well, fwiw. In some future iteration, you may also want to bind foo-request at example.net as an additional user ID (to the same key, probably), but i don't think that will be relevant for this iteration. > [1] Lars "larsi" Ingebrittsen is the main developer of the Gnus MUA > for Emacs, known for implementing features first (the IETF thanks > you) and for much-too-clever code. larsi is also the mad genius responsible for most of gmane.org, for which many of us are very grateful :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Aug 21 20:30:07 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 21 Aug 2013 14:30:07 -0400 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <5215072F.3020000@fifthhorseman.net> On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote: > Abhilash Raj writes: > > > After midterm evaluations I have been working on signing the message > > using one the keys associated with the list, now since `python-gnupg` > > does not allow selecting keys with key credentials( like address or > > list-name name) > > Have you tried this? In the GPG documentation, "key ID" often > actually means any of the above.[1] If python-gnupg simply passes its > argument to the gpg process, it should Just Work. Anyway, it seems to > work for me (some output edited for clarity): > > venv27 abhilash 15:39$ python2.7 > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > No entry for terminal type "emacs"; > using dumb terminal settings. >>>> from gnupg import GPG >>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') >>>> gpg.list_keys() > [{'dummy': u'', 'keyid': u'17A810C33BDFEFA8', 'expires': u'', > 'subkeys': [[u'2C376F1897FD6C1C', u'e']], 'length': u'2048', > 'ownertrust': u'u', 'algo': u'1', > 'fingerprint': u'A36D6B345C18B02E695B8B7917A810C33BDFEFA8', > 'date': u'1376462161', 'trust': u'-', 'type': u'pub', > 'uids': [u'GPG Test User ']}, > {'dummy': u'', 'keyid': u'87EBCC0B6DF8B373', 'expires': u'', > 'subkeys': [[u'18E03AE36F3B6DAD', u'e']], 'length': u'1024', > 'ownertrust': u'-', 'algo': u'17', > 'fingerprint': u'A9FC56DBD48F5E5B61B7137487EBCC0B6DF8B373', > 'date': u'1183228371', 'trust': u'-', 'type': u'pub', > 'uids': [u'Stephen J. Turnbull (XEmacs Reviewer) ']}] >>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen at xemacs.org', always_trust=True) hmm, always_trust=True is probably problematic -- if someone manages to inject another key with the associated User ID earlier into gpg's keyring, then their key will be used before the correct key. I agree that gpg should be able to figure out the key to use given the e-mail address, but i'm not sure if it necessarily will if there are two keys which both claim a given User ID and only one has a valid binding (i.e. a proper OpenPGP certification from a trusted introducer). so the above test worked, given the keyring that you had, but it might result in *not* working (e.g. by encrypting to the wrong key) given a different keyring. fortunately, in the current implementation we're only worrying about signing, not encryption; so the relevant issue is the choice of secret key, and we don't expect other users to be able to inject data into the secret keyring, so this shouldn't be a concern. right? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Wed Aug 21 21:29:58 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 22 Aug 2013 04:29:58 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <5215072F.3020000@fifthhorseman.net> References: <520A46AF.70400@gmail.com> <87eh9wk6vd.fsf@uwakimon.sk.tsukuba.ac.jp> <5215072F.3020000@fifthhorseman.net> Message-ID: <87eh9mg7ux.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Kahn Gillmor writes: > On 08/14/2013 04:35 AM, Stephen J. Turnbull wrote: > > Python 2.7.5 (default, Aug 1 2013, 23:58:20) > >>>> from gnupg import GPG > >>>> gpg = GPG(gnupghome='/Users/steve/.gnupg',keyring='test-pub',secret_keyring='test-sec') > >>>> crypted = gpg.encrypt(u'A bit of random text.', u'stephen at xemacs.org', always_trust=True) > hmm, always_trust=True is probably problematic Of course it is, but I was working with a test keyring. > -- if someone manages to inject another key with the associated > User ID earlier into gpg's keyring, then their key will be used > before the correct key. This is an argument for validity checks on the keyring. The alternative is keeping the email-to-fingerprint mapping in the User database, which is *not* designed for crypto validation. I see no reason to suppose it's easier to attack the keyring that the User database. > fortunately, in the current implementation we're only worrying about > signing, not encryption; so the relevant issue is the choice of secret > key, and we don't expect other users to be able to inject data into the > secret keyring, so this shouldn't be a concern. right? I don't think it's a major concern, period. True, encryption uses the public key, which may be downloaded from a keyserver or entered from the web, making injection attacks plausible. So what? What's the alternative given that the raison d'etre of Mailman is to give users control over their profiles? Note that I don't deny that there are real security issues here, and that in some contexts they are important. But if they are, I have to wonder if Mailman isn't much too complicated to be trusted anyway. Steve From truongvunghia at gmail.com Wed Aug 21 23:02:38 2013 From: truongvunghia at gmail.com (Nghia Vu Truong) Date: Wed, 21 Aug 2013 22:02:38 +0100 Subject: [Mailman-Developers] Can we send message with attachment using UserNotification? Message-ID: <52152AEE.6010707@gmail.com> Hi there, Could you please help me with this question! Is there anyway we can attach a document to message, sending by UserNotification method? Thanks Nghia From barry at list.org Thu Aug 22 20:44:01 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 22 Aug 2013 14:44:01 -0400 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <520DF44E.5030100@gmail.com> References: <520DC450.4010703@gmail.com> <520DF44E.5030100@gmail.com> Message-ID: <20130822144401.72219616@anarchist> On Aug 16, 2013, at 03:13 PM, Abhilash Raj wrote: >> > Also one more thing while running tests i noticed many other tests are >> > breaking as initially a simple message could pass though >> > "default-posting-chain" but now we need a multipart/signed message. So >> > should I worry about changing all other tests? >> >> Yes. Conventionally that is the responsibility of the person who adds >> a feature. However, there's nothing that says you can't ask Barry for >> help. He may know a way to do it quickly. > >Barry anything here? Ideally, your changes would only affect tests locally and not have a global effect on the tests. How many tests are newly broken? -Barry From barry at list.org Thu Aug 22 20:45:48 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 22 Aug 2013 14:45:48 -0400 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <520DF3EF.9040605@gmail.com> References: <520CE253.1040202@gmail.com> <520DF3EF.9040605@gmail.com> Message-ID: <20130822144548.3d39a257@anarchist> On Aug 16, 2013, at 03:12 PM, Abhilash Raj wrote: >2) RSA or DSA keys? > >DSA can only be used for signing but is faster than RSA, although for >now our scope is limited to signing later on we "will" add encryption so >I think we should stick to RSA? RSA probably. I don't think the difference in speed will be noticeable. -Barry From raj.abhilash1 at gmail.com Thu Aug 22 22:21:30 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 23 Aug 2013 01:51:30 +0530 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <20130822144401.72219616@anarchist> References: <520DC450.4010703@gmail.com> <520DF44E.5030100@gmail.com> <20130822144401.72219616@anarchist> Message-ID: <521672CA.4000505@gmail.com> On Friday 23 August 2013 12:14 AM, Barry Warsaw wrote: > On Aug 16, 2013, at 03:13 PM, Abhilash Raj wrote: > >>> > Also one more thing while running tests i noticed many other tests are >>> > breaking as initially a simple message could pass though >>> > "default-posting-chain" but now we need a multipart/signed message. So >>> > should I worry about changing all other tests? >>> >>> Yes. Conventionally that is the responsibility of the person who adds >>> a feature. However, there's nothing that says you can't ask Barry for >>> help. He may know a way to do it quickly. >> >> Barry anything here? > > Ideally, your changes would only affect tests locally and not have a global > effect on the tests. How many tests are newly broken? I actually don't have the remember the count but some 10 or so doctests were failing. > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > Abhilash Raj From barry at list.org Thu Aug 22 22:27:53 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 22 Aug 2013 16:27:53 -0400 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <521672CA.4000505@gmail.com> References: <520DC450.4010703@gmail.com> <520DF44E.5030100@gmail.com> <20130822144401.72219616@anarchist> <521672CA.4000505@gmail.com> Message-ID: <20130822162753.293b5a2e@anarchist> On Aug 23, 2013, at 01:51 AM, Abhilash Raj wrote: >I actually don't have the remember the count but some 10 or so doctests >were failing. If possible, you can just ignore these for now. Let's take a more detailed look when I land the nose2-based tests in trunk. -Barry From raj.abhilash1 at gmail.com Thu Aug 22 22:26:42 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Fri, 23 Aug 2013 01:56:42 +0530 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <20130822162753.293b5a2e@anarchist> References: <520DC450.4010703@gmail.com> <520DF44E.5030100@gmail.com> <20130822144401.72219616@anarchist> <521672CA.4000505@gmail.com> <20130822162753.293b5a2e@anarchist> Message-ID: <52167402.7030504@gmail.com> On Friday 23 August 2013 01:57 AM, Barry Warsaw wrote: > On Aug 23, 2013, at 01:51 AM, Abhilash Raj wrote: > >> I actually don't have the remember the count but some 10 or so doctests >> were failing. > > If possible, you can just ignore these for now. Let's take a more detailed > look when I land the nose2-based tests in trunk. Yup sure. > -Barry > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers at 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/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > --- Abhilash Raj From barry at list.org Thu Aug 22 22:35:59 2013 From: barry at list.org (Barry Warsaw) Date: Thu, 22 Aug 2013 16:35:59 -0400 Subject: [Mailman-Developers] Some Doubts for GSoC Project In-Reply-To: <5214EDF8.6080209@fifthhorseman.net> References: <5210AC77.6060404@gmail.com> <20130819141919.670baafb@anarchist> <878uzxgjkc.fsf@uwakimon.sk.tsukuba.ac.jp> <5214EDF8.6080209@fifthhorseman.net> Message-ID: <20130822163559.599af185@anarchist> On Aug 21, 2013, at 12:42 PM, Daniel Kahn Gillmor wrote: >larsi is also the mad genius responsible for most of gmane.org, for >which many of us are very grateful :) I hope at some point we'll have a plugin to allow for direct integration with Gmane (e.g. register-this-list, an IArchiver to feed it directly). Gmane is a *life-saver*! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Aug 22 22:55:34 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Aug 2013 16:55:34 -0400 Subject: [Mailman-Developers] Fwd: Re: GSoC Updates In-Reply-To: <20130822144548.3d39a257@anarchist> References: <520CE253.1040202@gmail.com> <520DF3EF.9040605@gmail.com> <20130822144548.3d39a257@anarchist> Message-ID: <52167AC6.6050608@fifthhorseman.net> On 08/22/2013 02:45 PM, Barry Warsaw wrote: > On Aug 16, 2013, at 03:12 PM, Abhilash Raj wrote: > >> 2) RSA or DSA keys? >> >> DSA can only be used for signing but is faster than RSA, although for >> now our scope is limited to signing later on we "will" add encryption so >> I think we should stick to RSA? > > RSA probably. I don't think the difference in speed will be noticeable. I think sticking to the gpg defaults is an unobjectionable choice at this point, and that is currently 2048-bit RSA. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From barry at list.org Fri Aug 23 15:56:58 2013 From: barry at list.org (Barry Warsaw) Date: Fri, 23 Aug 2013 09:56:58 -0400 Subject: [Mailman-Developers] ANN: wiki.list.org migrations Message-ID: <20130823095658.64e3ae70@anarchist> Hello everyone, I want to mention a few things related to wiki.list.org. First and most immediately, our currently wiki hosting provider Contegix, is in the process of a major infrastructure update which will cause some downtime for wiki.list.org. Contegix has been hosting our wiki gratis for several years, for which we are very grateful. Their support over the years has been superb. Unfortunately, the infrastructure our wiki is hosted on is quite legacy, and in fact, we are the last organization to be hosted on it. The time has come to for them to retire it, but they have again graciously offered to continue hosting our wiki gratis on their new infrastructure. The migration process is tricky, since we have to coordinate with Contegix's timing and our DNS changes with John Viega (Mailman's original author and owner of the list.org domain). Please be aware that the wiki may experience some downtime as both DNS and the instance get shuffled around. As some of you know, Paul Boddie has been working diligently on migrating our current Atlassian Confluence wiki to Moin. While Confluence has served us well over the years, we recognize that it is inappropriate for a GNU project such as Mailman to utilize a non-free wiki. Moin is our current choice for a free software wiki hosting platform, and Paul has done an amazing job on the migration, as anyone who reads mailman-developers can see. That work is close, but not quite ready for production. Stay tuned for more announcements on that front, or join mailman-developers for more information, or if you'd like to pitch in to help. We will send another announcement when the Contegix transfer is complete. In the meantime, if you see outages for wiki.list.org, please be patient. I hope there won't be too much of a disruption of service. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at list.org Wed Aug 28 04:08:31 2013 From: barry at list.org (Barry Warsaw) Date: Tue, 27 Aug 2013 22:08:31 -0400 Subject: [Mailman-Developers] virtualenv and nose2 replace zc.buildout and zope.testing Message-ID: <20130827220831.5a5f1aa5@anarchist> Hey everyone, A while ago I mentioned that I was trying to get rid of zc.buildout to build Mailman 3 and zope.testing to test it. This work is now complete and pushed to trunk. My thanks to the awesome nose2 project and Jason Pellerin for his help in answering my questions along the way. Updated instructions are available in src/mailman/docs/START.rst and it would be great if you could test this out. Here's a summary. * Create a virtual environment using Python 2.7 % virtualenv --system-site-packages /tmp/py27 * Activate the virtualenv and set it up for development % source /tmp/py27/bin/activate % python setup.py develop * Run the tests % nose2 -v This makes building for development consistent with building for (test) deployment, and simplifies Mailman 3's dependencies, and some implementation details are nicer now. Enjoy, and please let me know if you have any problems. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From stephen at xemacs.org Wed Aug 28 05:44:59 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 28 Aug 2013 12:44:59 +0900 Subject: [Mailman-Developers] virtualenv and nose2 replace zc.buildout and zope.testing In-Reply-To: <20130827220831.5a5f1aa5@anarchist> References: <20130827220831.5a5f1aa5@anarchist> Message-ID: <87sixucwck.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > A while ago I mentioned that I was trying to get rid of zc.buildout to build > Mailman 3 and zope.testing to test it. This work is now complete and pushed > to trunk. Yee-haw! (and giddyap, GSOC students! fix them tests!) From raj.abhilash1 at gmail.com Thu Aug 29 03:37:28 2013 From: raj.abhilash1 at gmail.com (Abhilash Raj) Date: Thu, 29 Aug 2013 07:07:28 +0530 Subject: [Mailman-Developers] GSoC Updates Message-ID: <521EA5D8.8060103@gmail.com> Hi all, So I think my work inside mailman for signing and verification is almost complete, here are a few things that I have now working and it would be very nice if some of you can have a look at the code and let me know if the implementation is correct(the logical and the pythonic way). 1) There is a 'signature rule'[1] that can verify signature from the users whose public key is stored in 'var/gpg' directory insider 'pubring.gpg'. This rule also verifies that the email has only two parts one of which must be 'application/pgp-signature'. 2) The 'signmessage handler'[2] signs the message while preserving the sender's signature. The structure of the message for now is a multipart/alternative with each alternative part having one signature(one from list and another from sender). (I have into my todo what Daniel suggested previously[3] to have two signatures in one pgp-signature part) 3) A 'gpg'[4] utility which does all the crypto part from signing to verification, generation of list's key, importing key from data(will be used if we allow user's to copy paste their public key data insider postorius), importing key from a public keyserver(default is set as 'pgp.mit.edu' on random basis, please suggest something which you think can be a better default). In line 81 I am passing an empty string to the comment for the key but still the key generated is still having the default comment 'Generated by gpg.py'. Any idea why? Is it because the string I am passing is a null string and it should have a non-null string to set as comment? 4) There are few other changes like adding the signature rule in default-posting-chain chain and signmessage handler in default-posing-pipeline. Also I have added a new config variable as 'gpg_dir' whose default value is set to '$VAR_DIR/gpg'. There are tests written for almost all the modules above, some more tests maybe required to be added to then though) I am thinking to setup a working installation of this code once I find a place to do that, so that we can find bugs more easily. Moving on my plan includes adding the APIs for management of keys and options for list-admin and users in postorius and mm-client. If anyone has ever given a thought before about what all things should be there please help me with it. [1]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/mailman/rules/signature.py [2]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/mailman/handlers/signmessage.py [3]: http://www.mail-archive.com/mailman-developers%40python.org/msg13961.html [4]: http://bazaar.launchpad.net/~raj-abhilash1/mailman/master/view/head:/src/mailman/utilities/gpg.py --- Abhilash Raj From dkg at fifthhorseman.net Fri Aug 30 05:24:09 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 29 Aug 2013 23:24:09 -0400 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <521EA5D8.8060103@gmail.com> References: <521EA5D8.8060103@gmail.com> Message-ID: <52201059.10906@fifthhorseman.net> Hi Abhilash-- I haven't looked at the code much yet, but this is a pretty exciting report! I'm glad to hear everything you've done. On 08/28/2013 09:37 PM, Abhilash Raj wrote: > 1) There is a 'signature rule'[1] that can verify signature from the > users whose public key is stored in 'var/gpg' directory insider > 'pubring.gpg'. This rule also verifies that the email has only two parts > one of which must be 'application/pgp-signature'. i'm not sure about this last constraint. It's certainly possible to have a multipart MIME message with a deeper structure that has more parts if you're looking at the leaves of the MIME tree. the constraint should be: main content-type should be multipart/signed; that part should have exactly two immediate children; the last child should be application/pgp-signature. The first child could itself be multipart/mixed or multipart/alternative. > 2) The 'signmessage handler'[2] signs the message while preserving the > sender's signature. The structure of the message for now is a > multipart/alternative with each alternative part having one > signature(one from list and another from sender). > (I have into my todo what Daniel suggested previously[3] to have two > signatures in one pgp-signature part) have you tested what messages with this structure look like when viewed with any MUA that is PGP/MIME-aware? do you have any examples you could publish, so other people can test other MUAs? > 3) A 'gpg'[4] utility which does all the crypto part from signing to > verification, generation of list's key, importing key from data(will be > used if we allow user's to copy paste their public key data insider > postorius), importing key from a public keyserver(default is set as > 'pgp.mit.edu' on random basis, please suggest something which you think > can be a better default). please do not use pgp.mit.edu [0], it is out of date and poorly-maintained. Your best bet for reliable, redundant service is to use ha.pool.sks-keyservers.net. You can read more about this high-availability DNS round-robin pool on the sks-keyservers website [1]. [0] https://we.riseup.net/debian/openpgp-best-practices#dont-use-pgp-mit-edu [1] https://sks-keyservers.net/overview-of-pools.php > In line 81 I am passing an empty string to the comment for the key but > still the key generated is still having the default comment 'Generated > by gpg.py'. Any idea why? Is it because the string I am passing is a > null string and it should have a non-null string to set as comment? Take a look at the gnupg module (gnupg.py), which you're relying on, around. around line 976 in my version is the definition of GPG.gen_key_input, which skips "empty" strings: 983 if str(val).strip(): # skip empty strings 984 parms[key] = val unfortunately, the rest of that function definition appears to require a comment, inserting one by default if no comment is supplied by the user. I consider this a bug in gnupg.py, we should get it fixed there. I've just opened http://bugs.debian.org/721296 to try to get them fixed in debian, but they should probably be forwarded upstream, but upstream's bugtracker [2] appears to require a google account in order to open a ticket, which i do not have or want. If you have a google account, feel free to forward them upstream. [2] https://code.google.com/p/python-gnupg/issues/list In the meantime, i recommend just hand-crafting the input for gpg --batch --gen-key instead of using gnupg.GPG.gen_key_input() at all. If you're not sure about the format, i recommend reading /usr/share/doc/gnupg/DETAILS.gz on any debian or debian-derived system, or DETAILS in the gpg source [3]. [3] git://git.gnupg.org/gnupg > I am thinking to setup a working installation of this code once I find a > place to do that, so that we can find bugs more easily. that would be great! Hope these notes are helpful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Fri Aug 30 06:56:02 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 30 Aug 2013 13:56:02 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <52201059.10906@fifthhorseman.net> References: <521EA5D8.8060103@gmail.com> <52201059.10906@fifthhorseman.net> Message-ID: <87k3j3dbfh.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Kahn Gillmor writes: > On 08/28/2013 09:37 PM, Abhilash Raj wrote: > > > 1) There is a 'signature rule'[1] that can verify signature from the > > users whose public key is stored in 'var/gpg' directory insider > > 'pubring.gpg'. This rule also verifies that the email has only two parts > > one of which must be 'application/pgp-signature'. > > i'm not sure about this last constraint. It's certainly possible to > have a multipart MIME message with a deeper structure that has more > parts if you're looking at the leaves of the MIME tree. the constraint > should be: main content-type should be multipart/signed; that part > should have exactly two immediate children; the last child should be > application/pgp-signature. The first child could itself be > multipart/mixed or multipart/alternative. The last time I looked (~10 days ago), that was the implementation: look only at the message-level Content-Type, ensure it's multipart/signed, check that there are exactly two parts and that the second is "application/pgp-signature". Note that nested multipart parts are problematic. You can't strip unwanted parts from them (many lists strip .exes, others text/html, and so on) without breaking the original signature. We need to think carefully about what policies to support regarding signed multiparts. I would suggest that the initial default policy should be (1) verify the signature, if not DISCARD (2) if valid AND key belongs to explicitly allowed poster (I think probably nobody wants open-post signed lists, but what do I know? ;-) AND signed part is multipart, REJECT with "multipart not allowed for technical reasons" as reason (3) if valid AND key belongs to explicitly allowed poster, APPROVE (4) otherwise HOLD while we're figuring out a sane UI for configuring more complex policies. > have you tested what messages with this structure look like when viewed > with any MUA that is PGP/MIME-aware? +1 > do you have any examples you could publish, so other people can > test other MUAs? +1 > please do not use pgp.mit.edu [0], it is out of date and > poorly-maintained. Your best bet for reliable, redundant service is to > use ha.pool.sks-keyservers.net. You can read more about this > high-availability DNS round-robin pool on the sks-keyservers > website [1]. Thanks for the suggestion! From dkg at fifthhorseman.net Fri Aug 30 07:03:50 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 30 Aug 2013 01:03:50 -0400 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <87k3j3dbfh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <521EA5D8.8060103@gmail.com> <52201059.10906@fifthhorseman.net> <87k3j3dbfh.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <522027B6.5050303@fifthhorseman.net> On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote: > The last time I looked (~10 days ago), that was the implementation: > look only at the message-level Content-Type, ensure it's > multipart/signed, check that there are exactly two parts and that the > second is "application/pgp-signature". hum, what if the first part is an .exe of type application/octet-stream? :P > Note that nested multipart parts are problematic. You can't strip > unwanted parts from them (many lists strip .exes, others text/html, > and so on) without breaking the original signature. We need to think > carefully about what policies to support regarding signed multiparts. > I would suggest that the initial default policy should be > > (1) verify the signature, if not DISCARD > (2) if valid AND key belongs to explicitly allowed poster (I think > probably nobody wants open-post signed lists, but what do I know? > ;-) AND signed part is multipart, REJECT with "multipart not > allowed for technical reasons" as reason Doesn't this seem a little overbroad? what if the message is two inline parts, one text/plain and one text/x-diff (e.g. the common case of someone sending a patch to a project mailing list ? I understand wanting to REJECT if any of the internal parts need to be stripped, but if none of them need to be stripped, it seems like REJECT is too heavy-handed. Or is the knowledge about what might need to be stripped not available at that stage? If the stripping happens later, can we mark a message as "REJECT if you need to strip" somehow, and get the part-stripping code to respect that marking and REJECT it there? sorry for the ignorance, just exploring the options. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From stephen at xemacs.org Fri Aug 30 08:15:34 2013 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 30 Aug 2013 15:15:34 +0900 Subject: [Mailman-Developers] GSoC Updates In-Reply-To: <522027B6.5050303@fifthhorseman.net> References: <521EA5D8.8060103@gmail.com> <52201059.10906@fifthhorseman.net> <87k3j3dbfh.fsf@uwakimon.sk.tsukuba.ac.jp> <522027B6.5050303@fifthhorseman.net> Message-ID: <87ioynd7qx.fsf@uwakimon.sk.tsukuba.ac.jp> Daniel Kahn Gillmor writes: > On 08/30/2013 12:56 AM, Stephen J. Turnbull wrote: > > The last time I looked (~10 days ago), that was the implementation: > > look only at the message-level Content-Type, ensure it's > > multipart/signed, check that there are exactly two parts and that the > > second is "application/pgp-signature". > > hum, what if the first part is an .exe of type application/octet-stream? :P Windows users get another reason to switch? ;-) That should be handled by content filtering. *However*, content filtering needs to be taught to throw away the signature too if a signed part gets filtered. > Doesn't this seem a little overbroad? what if the message is two inline > parts, one text/plain and one text/x-diff (e.g. the common case of > someone sending a patch to a project mailing list ? I understand > wanting to REJECT if any of the internal parts need to be stripped, but > if none of them need to be stripped, it seems like REJECT is too > heavy-handed. Sure, but there's a GSoC scope issue here. Principle Number One has to be "Better Safe than Sorry", and this is easy for Abhilash to implement safely. It has to be an option, of course, for admins willing to risk junk getting through (eg, because their users don't use Outlook [Express]). > Or is the knowledge about what might need to be stripped not available > at that stage? If the stripping happens later, can we mark a message as > "REJECT if you need to strip" somehow, and get the part-stripping code > to respect that marking and REJECT it there? I doubt that Abhilash knows, and I know *I* don't. :-) My guess is that signature check in principle is going to be a Rule, while part-stripping is a Handler. I don't think Handlers can REJECT, Rules make that decision, and they come first, before the Handlers. So I see the process as involving two Rules. The first one checks the multipart/signed message itself. If invalid (either a broken signature or signer is not allowed to post), DISCARD (the risk of a spoof is too great). The second one checks the structure of the message. Presumably code can be reused from elsewhere to do this with more accuracy as you suggest, but the easy check is to disallow multiparts nested in multipart/signed. My proposal at this point is to accept an easy and safe (== restrictive) implementation for the purposes of GSoC and early beta testing. I don't mean to suggest it's at all satisfactory for a public release of this feature (although we might all be surprised and find out that it's fine for many purposes!) Steve