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

Bob Ippolito bob at redivi.com
Sun Feb 1 21:10:44 EST 2004


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




More information about the Distutils-SIG mailing list