Il giorno 06/feb/2013, alle ore 14:41, Zygmunt Krynicki 
<zygmunt.kryni...@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   ::  ra...@develer.com
Develer S.r.l.  ::  http://www.develer.com

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig

Reply via email to