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

[Giovanni Bajo]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> W dniu 06.02.2013 15:38, Giovanni Bajo pisze:
>> 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.
> 
> I agree that pypi "should" be the good guy we can trust. I argue that
> none of the things offered in this thread can achieve that.
> 
> There is a deeper problem here, apart from the current "OMG MITM"
> issue that woke everyone up and realized how insecure their
> infrastructure is.
> 
> Even with a CA system, signatures, and ssl connection between the user
> and pypi, installing $STUFF from pypi is the exact equivalent to
> googling for a .exe on the internet. In this case you make the user
> implicitly agree to installing "foo.exe" that came signed by "Foo
> Corp" along with all of its dependencies.
> 
> The "django" use case is interesting because we trust the "trademark"
> that django carries more than anything else (and in fact this is
> currently the only trust that people can apply to software from pypi).
> What is more problematic is the association of trust to a particular
> software and the trust to the whole pypi distribution channel. Without
> a gatekeeper system, pypi cannot be treated as a storage for safe
> software. It can just be an FTP site that has signed executables.
> 
> In the end, you must let go of something: current user experience or
> security.
> 
> We can either let the UI tell the user that he's doing unsafe stuff,
> giving full local user access to whoever owns the particular pypi
> project that user choose to install (along with the full recursive set
> of dependencies) _or_ start changing what pypi is.

Can you please describe the UX you are devising? Say I start blank, I want to install 3-4 packages that globally bring another 10 packages as dependencies (made by different developers). What would be your suggested workflow? What should an user do?

> If pypi becomes a gatekeeper / appstore with "review" process and the
> like then what you describe is perfectly fine (to the extent that the
> central review system can scale and stay effective).

I think it's a false alternative. You're suggesting that either you *only* trust PyPI (like appstore or any Linux distro, where you only trust Canonical for all the packages you install through apt), or you *only* trust the end developers, by manually building a list of GPG signatures.

I think that what we are suggesting here instead is a good compromise between security and usability, just like the current CAs in SSL have been for many years a good compromise between the final solution (yet to be devised) and using only self-signed certificates. In fact, CAs are still a very good compromise that work for 99.9999% of people and websites. I understand that we will need a final solution for SSL, but I think that for PyPI, forcing your suggestion is basically an instance of making perfect the enemy of good. 

Perfect security doesn't exist. At the end of the day, I can talk you into registering the wrong fingerprint for a package, I can phish you on the package name, I can compromise Django's developers' GPG keychains. Or, most important of all, I can simply go exploit a 0-day vulnerability on a totally-regular, phone-call sig-validated instance of Django installed on your server. An attacker will simply go for the lowest hanging fruit.
-- 
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/d236f988/attachment.bin>