[Python-Dev] Status of packaging in 3.3 (original) (raw)

Vinay Sajip vinay_sajip at yahoo.co.uk
Fri Jun 22 17:36:47 CEST 2012

Paul Moore <p.f.moore gmail.com> writes:

As a user, I guess not that much. I may be misremembering bad experiences with different things. We've had annoyances with self-signed jars, and websites. It's generally more about annoying "can't confirm this should be trusted, please verify" messages which people end up just saying "yes" to (and so ruining any value from the check).

Like those pesky EULAs ;-)

But you say "I got a code signing certificate". How? When I dabbled with signing, the only option I could find that didn't involve paying and/or having a registered domain of my own was a self-signed certificate, which from a UI point of view seems of little use "Paul Moore says you should trust him. Do you? Yes/No"...

I got mine from Certum (certum.pl) - they offer (or at least did offer, last year) free code signing certificates for Open Source developers (you have to have "Open Source Developer" in what's being certified). See:

http://www.certum.eu/certum/cert,offer_en_open_source_cs.xml

If signed binaries is the way we go, then we should be aware that we exclude people who don't have certificates from uploading to PyPI.

I don't think that any exclusion would occur. It just means that there's a mechanism for people who are picky about such things to have a slightly larger comfort zone.

Maybe that's OK, but without some sort of check I don't know how many current developers that would exclude, let alone how many potential developers would be put off.

I don't think any packager need be excluded. It would be up to individual packagers and package consumers as to whether they sign packages / stick to only using signed packages. For almost everyone, life should go on as before.

A Python-supported build farm, which signed code on behalf of developers, might alleviate this. But then we need to protect against malicious code being submitted to the build farm, etc.

There is IMO neither the will nor the resource to do any sort of policing. Caveat emptor (or caveat user, rather). Let's not forget, all of this software is without warranty of any kind.

Fair enough. I don't object to offering the option to verify signatures (I think I said something like that in an earlier message). I do have concerns about making signed code mandatory. (Not least over whether it'd let me install my own unsigned code!)

Any workable mechanism would need to be optional (the user doing the installing would be the decider as to whether to go ahead and install, with signature, or lack thereof, in mind).

Regards,

Vinay Sajip

More information about the Python-Dev mailing list