[Distutils] PGP keys required? (Re: PEP 243)

[Keith Jackson]

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