RE: [Distutils] PGP keys required? (Re: PEP 243)
From: Michael T. Babcock
Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper? Initially these would all be an "authority" of some form, of course. This at least allows the authentication of authors' packages as being intact and submitted by themselves, which then allows a good method of filtering à la "I like this author's software", etc. via rating systems and the like.
-1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key. Paul
"Moore, Paul" wrote From: Michael T. Babcock Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper?
-1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key.
It should be at least an option, anyway. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote:
"Moore, Paul" wrote From: Michael T. Babcock Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper?
-1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key.
It should be at least an option, anyway.
Isn't most of the stuff used to support GPG under the GNU GPL license? I think that would preclude it from being incorporated into the mainline of distutils. Personally, I don't think it would be a popular enough feature to justify the changes. For the people who do care, a "meta-index" could be created where the developer could, email a pgp-signed or s/mime signed message containing the URLs and sha1 hashes of the files to some robot-address that would insert it into the "meta-index" if the credentials were ok. -bob
On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote:
On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote:
"Moore, Paul" wrote From: Michael T. Babcock Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper?
I'm not a lawyer, but this makes me uncomfortable. Seems to bring up a whole can of liability worms.
-1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key.
It should be at least an option, anyway.
Isn't most of the stuff used to support GPG under the GNU GPL license? I think that would preclude it from being incorporated into the mainline of distutils.
Yes, but I don't think that prevents distutils from running a shell command to invoke gpg. I'd really like to see this as an option. As soon as people start putting more things up in a repository, the more likely it will become that someone tries to trojan things. I'd also like to see M2Crypto or pyOpenSSL support for S/MIME sigs. Personally I'd be willing to settle for a separate machine that maintained the sha1 hashes of all the code. At least then you'd have to crack two machines to trojan software. distutils could have built in support for getting the sha1 hash and verifying it. I'm much more concerned with the code integrity then authenticating who wrote it. This is open-source, so I'm not going to have any legal options against someone who wrote bad code. What I am concerned about is minimizing the likelihood that someone can trojan a distutils repository. Given how frequently this has happened to other sites, it seems like a reasonable concern.
Personally, I don't think it would be a popular enough feature to justify the changes. For the people who do care, a "meta-index" could be created where the developer could, email a pgp-signed or s/mime signed message containing the URLs and sha1 hashes of the files to some robot-address that would insert it into the "meta-index" if the credentials were ok.
Yes, but of course this begs the age old key distribution problem. I'm all in favor of some kind of optional support for PGP or S/MIME signatures, I exist in an X.509 world, so I could take advantage of it for my own work. That said, I think that code integrity in the repository is a much bigger issue that authenticating who put the code into the repository. (yes i do understand that the sig will also handle integrity, but it is probably overkill) All a sha1 hash would say is that: The distutils repository only contains the code that was legitimately submitted. That doesn't mean someone didn't submit a trojan, but it does mean that for major projects like wxPython that if the hash verifies then most likely things are ok. Sorry for the long post, but I think if we're going to do a python repository, we should be concerned about the integrity of the repository. --keith p.s. How does CPAN deal with these issues?
On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote:
On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote:
On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote:
"Moore, Paul" wrote From: Michael T. Babcock Would it be worthwhile to stipulate that anyone who wants to submit a package to an automated distutils system have a PGP/GPG key signed by an appropriate Python authority or another developper?
I'm not a lawyer, but this makes me uncomfortable. Seems to bring up a whole can of liability worms.
-1. The effect would be to bar new submitters, who wouldn't have the necessary signed key, as well as to people like myself who can't be bothered trying to maintain a PGP key.
It should be at least an option, anyway.
Isn't most of the stuff used to support GPG under the GNU GPL license? I think that would preclude it from being incorporated into the mainline of distutils.
Yes, but I don't think that prevents distutils from running a shell command to invoke gpg. I'd really like to see this as an option. As soon as people start putting more things up in a repository, the more likely it will become that someone tries to trojan things. I'd also like to see M2Crypto or pyOpenSSL support for S/MIME sigs.
Well, right now there is no repository, PyPI links to the author's page. There are repositories for Mac ports, though, but we're not terribly worried at the moment (I maintain one of them, python.org has the other maintained by Jack). The package index has MD5 hashes and URLs to tarballs (that can be anywhere). Obviously you have to trust me or Jack, and the integrity of our servers, but I don't think that's a huge problem right now. I do have a CA-signed SSL cert for pythonmac.org and I could put a package index there.. so you could verify that there wasn't some sort of spoof or man in the middle attack, but it just hasn't been worth doing so far.
Personally I'd be willing to settle for a separate machine that maintained the sha1 hashes of all the code. At least then you'd have to crack two machines to trojan software. distutils could have built in support for getting the sha1 hash and verifying it. I'm much more concerned with the code integrity then authenticating who wrote it. This is open-source, so I'm not going to have any legal options against someone who wrote bad code.
What I am concerned about is minimizing the likelihood that someone can trojan a distutils repository. Given how frequently this has happened to other sites, it seems like a reasonable concern.
Personally, I don't think it would be a popular enough feature to justify the changes. For the people who do care, a "meta-index" could be created where the developer could, email a pgp-signed or s/mime signed message containing the URLs and sha1 hashes of the files to some robot-address that would insert it into the "meta-index" if the credentials were ok.
Yes, but of course this begs the age old key distribution problem.
So does anything else?
I'm all in favor of some kind of optional support for PGP or S/MIME signatures, I exist in an X.509 world, so I could take advantage of it for my own work. That said, I think that code integrity in the repository is a much bigger issue that authenticating who put the code into the repository. (yes i do understand that the sig will also handle integrity, but it is probably overkill)
All a sha1 hash would say is that: The distutils repository only contains the code that was legitimately submitted. That doesn't mean someone didn't submit a trojan, but it does mean that for major projects like wxPython that if the hash verifies then most likely things are ok.
md5 and sha1 hashes are fine, Python comes with those.. but crypto isn't really an option because there are people who are concerned about the associated export/import laws that will not let it go into mainline Python (I tried).
Sorry for the long post, but I think if we're going to do a python repository, we should be concerned about the integrity of the repository. --keith
p.s. How does CPAN deal with these issues?
They don't, and I haven't really heard of any problems. From what I understand, the author uploads a package to PAUSE (w/ a login/password, probably not even over SSL), and it gets replicated throughout CPAN in a few hours. -bob
On Jan 31, 2004, at 2:34 PM, Bob Ippolito wrote:
On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote:
On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote:
On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote:
Yes, but I don't think that prevents distutils from running a shell command to invoke gpg. I'd really like to see this as an option. As soon as people start putting more things up in a repository, the more likely it will become that someone tries to trojan things. I'd also like to see M2Crypto or pyOpenSSL support for S/MIME sigs.
Well, right now there is no repository, PyPI links to the author's page. There are repositories for Mac ports, though, but we're not terribly worried at the moment (I maintain one of them, python.org has the other maintained by Jack). The package index has MD5 hashes and URLs to tarballs (that can be anywhere). Obviously you have to trust me or Jack, and the integrity of our servers, but I don't think that's a huge problem right now. I do have a CA-signed SSL cert for pythonmac.org and I could put a package index there.. so you could verify that there wasn't some sort of spoof or man in the middle attack, but it just hasn't been worth doing so far.
I'm not concerned about man in the middle attacks. As far as I know, there has never been one documented in the wild. Seems more like something security people like to sit around and worry about. :) Mostly what I worry about is someone hacking the repository and handing out trojan binaries. This has happened to a number of major sites already, and can cause real problems, e.g., if someone trojans openssl for example. For now, I'm fine with having the md5/sha1 hashes on a different machine then the code. Now a cracker has to get access to both machines. We could even out of band mirror the hashes on other web sites. If I got pgp or s/mime mail from you or Jack, I would put hashes up on a LBNL machine.
Yes, but of course this begs the age old key distribution problem.
So does anything else?
:), No it always comes back to bite you. I think we could come up with a scheme that doesn't involve key distribution for more then a few of us. If we want to mirror the hashes of the packages, I think signed mail amongst a small subset of us would work fine.
I'm all in favor of some kind of optional support for PGP or S/MIME signatures, I exist in an X.509 world, so I could take advantage of it for my own work. That said, I think that code integrity in the repository is a much bigger issue that authenticating who put the code into the repository. (yes i do understand that the sig will also handle integrity, but it is probably overkill)
All a sha1 hash would say is that: The distutils repository only contains the code that was legitimately submitted. That doesn't mean someone didn't submit a trojan, but it does mean that for major projects like wxPython that if the hash verifies then most likely things are ok.
md5 and sha1 hashes are fine, Python comes with those.. but crypto isn't really an option because there are people who are concerned about the associated export/import laws that will not let it go into mainline Python (I tried).
I think the hashes are great. I would still like to see optional support for some kind of dig sig. This could be completely optional, and require the separate installation of M2Crypto or PyOpenSSL. Mostly, I'd just like to design something that doesn't rule out using digital signatures.
Sorry for the long post, but I think if we're going to do a python repository, we should be concerned about the integrity of the repository. --keith
p.s. How does CPAN deal with these issues?
They don't, and I haven't really heard of any problems. From what I understand, the author uploads a package to PAUSE (w/ a login/password, probably not even over SSL), and it gets replicated throughout CPAN in a few hours.
It's a good thing I'm not a cracker. :) That is just frightening to me. I doubt I'll be getting anything from CPAN any longer. I've always thought CPAN was the best part of perl, and I'd sure like to see the python community do something even better. ;) --keith
On Feb 1, 2004, at 8:46 PM, Keith Jackson wrote:
On Jan 31, 2004, at 2:34 PM, Bob Ippolito wrote:
On Jan 31, 2004, at 4:59 PM, Keith Jackson wrote:
On Jan 29, 2004, at 3:26 AM, Bob Ippolito wrote:
On Jan 29, 2004, at 6:15 AM, Anthony Baxter wrote:
Yes, but I don't think that prevents distutils from running a shell command to invoke gpg. I'd really like to see this as an option. As soon as people start putting more things up in a repository, the more likely it will become that someone tries to trojan things. I'd also like to see M2Crypto or pyOpenSSL support for S/MIME sigs.
Well, right now there is no repository, PyPI links to the author's page. There are repositories for Mac ports, though, but we're not terribly worried at the moment (I maintain one of them, python.org has the other maintained by Jack). The package index has MD5 hashes and URLs to tarballs (that can be anywhere). Obviously you have to trust me or Jack, and the integrity of our servers, but I don't think that's a huge problem right now. I do have a CA-signed SSL cert for pythonmac.org and I could put a package index there.. so you could verify that there wasn't some sort of spoof or man in the middle attack, but it just hasn't been worth doing so far.
I'm not concerned about man in the middle attacks. As far as I know, there has never been one documented in the wild. Seems more like something security people like to sit around and worry about. :)
Mostly what I worry about is someone hacking the repository and handing out trojan binaries. This has happened to a number of major sites already, and can cause real problems, e.g., if someone trojans openssl for example. For now, I'm fine with having the md5/sha1 hashes on a different machine then the code. Now a cracker has to get access to both machines. We could even out of band mirror the hashes on other web sites. If I got pgp or s/mime mail from you or Jack, I would put hashes up on a LBNL machine.
The pythonmac-sig proposed-but-nobody-is-working-on-it solution is for Jack and I to use some secure mechanism, let's say s/mime or pgp, to send the hash of our package *index* every time we make an update. That way, one hash is sent that confirms the integrity of every hash in the index.
Yes, but of course this begs the age old key distribution problem.
So does anything else?
:), No it always comes back to bite you. I think we could come up with a scheme that doesn't involve key distribution for more then a few of us. If we want to mirror the hashes of the packages, I think signed mail amongst a small subset of us would work fine.
I'm fine with that, I use a script to update my package index anyways (though I suspect Jack might do his by hand ;). It wouldn't be much trouble for me to add the code to send a s/mime email to someone, my Mail.app is already configured to use s/mime (though it's off most of the time, because of stupid mailing lists and email clients that don't like them).
I'm all in favor of some kind of optional support for PGP or S/MIME signatures, I exist in an X.509 world, so I could take advantage of it for my own work. That said, I think that code integrity in the repository is a much bigger issue that authenticating who put the code into the repository. (yes i do understand that the sig will also handle integrity, but it is probably overkill)
All a sha1 hash would say is that: The distutils repository only contains the code that was legitimately submitted. That doesn't mean someone didn't submit a trojan, but it does mean that for major projects like wxPython that if the hash verifies then most likely things are ok.
md5 and sha1 hashes are fine, Python comes with those.. but crypto isn't really an option because there are people who are concerned about the associated export/import laws that will not let it go into mainline Python (I tried).
I think the hashes are great. I would still like to see optional support for some kind of dig sig. This could be completely optional, and require the separate installation of M2Crypto or PyOpenSSL. Mostly, I'd just like to design something that doesn't rule out using digital signatures.
I'd like to see it too, the problem is that nobody wants to write the code and convince people to put it in Python and use it ;)
Sorry for the long post, but I think if we're going to do a python repository, we should be concerned about the integrity of the repository. --keith
p.s. How does CPAN deal with these issues?
They don't, and I haven't really heard of any problems. From what I understand, the author uploads a package to PAUSE (w/ a login/password, probably not even over SSL), and it gets replicated throughout CPAN in a few hours.
It's a good thing I'm not a cracker. :) That is just frightening to me. I doubt I'll be getting anything from CPAN any longer. I've always thought CPAN was the best part of perl, and I'd sure like to see the python community do something even better. ;)
Yeah, well, most of the software in CPAN is pretty poorly designed anyways ;) -bob
On Feb 1, 2004, at 6:10 PM, Bob Ippolito wrote:
The pythonmac-sig proposed-but-nobody-is-working-on-it solution is for Jack and I to use some secure mechanism, let's say s/mime or pgp, to send the hash of our package *index* every time we make an update.
That way, one hash is sent that confirms the integrity of every hash in the index.
A single S/MIME email from you or Jack would totally suffice for me for the short term. That way I could look in the archive, verify the sig, and know that the hashes are valid. (Assuming you and Jack aren't really black hats. :) --keith
participants (4)
-
Anthony Baxter -
Bob Ippolito -
Keith Jackson -
Moore, Paul