[Catalog-sig] [Draft] Package signing and verification process

[Giovanni Bajo]

Il giorno 06/feb/2013, alle ore 14:41, Zygmunt Krynicki <zygmunt.krynicki at canonical.com> ha scritto:

> W dniu 06.02.2013 11:57, Christian Heimes pisze:
>> Am 05.02.2013 22:28, schrieb Zygmunt Krynicki:
> 
>>> I agree. I think that pypi should not have to be trusted. Real 
>>> people trust other (few, limited) real people. We don't normally 
>>> trust large bodies (corporations, groups) as that trust cannot
>>> be effective.
>> 
>> No, you have to trust PyPI on some degree. PyPI is *the* authority
>> of the relationship between users and projects. PyPI is the only
>> entity in process that can truly verify that a key holder was a
>> project maintainer at some given point in the past.
> 
> But that information is worthless to me. Anyone can upload a new
> project to pypi.
> What I want is to know if all the software that I
> install via pip is from the trusted set of developers. If someone
> introduces a new dependency I want to examine it and trust the
> developer of the new dependency. This should never happen automatically.

I disagree with this statement. I think that PyPI *should*, by the default, be the central authority to be trusted specifically for this item, that is the association between developers, projects and their GPG signatures. This is important because most people would be perfectly fine with trusting PyPI and can not be reasonably asked to acquire valid GPG key fingerprints through external channels for all packages they want to install. We cannot sacrifice this UX part as it is crucial for the pip/PyPI experience.

On the other hand, it is perfectly fine to make sure you can configure pip to disable all trusts on PyPI (= not asking PyPI what is the official GPG fingerprints associated with a project). This is an advanced security feature that you might want to employ on your servers, but it cannot be the default. 

> All that I want pypi to do is to have non borked database where I can
> register my software. With signed code and developer-project
> association I don't care if pypi gets owned tomorrow, it hosts no
> valuable data.

I respect your need, but it is a *subset* of the needs of most people. Most people want to be able to write "pip install django" and get django, with all the dependencies. That's it. They are doing it today through HTTP with not even a signature verification on the download, and they will be perfectly fine with trusting PyPI just like they trust Canonical when they write apt-get install (actually, technically we require *less* trust than those using apt-get, since the packages are not signed by PyPI but by the original developer).

>> If you don't trust PyPI then you have to create and maintain your
>> own mapping of key fingerprints to projects.
> 
> Yes, that is what I want to do.

That's OK, we can make sure in the design that you will be able to do it.
-- 
Giovanni Bajo   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130206/5bc93fdb/attachment-0001.bin>