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

[Keith Jackson]

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?