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

[Zygmunt Krynicki]

-----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.

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).


> 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.

I think that that level of security should not be an advanced feature
for the reasons I stated above.

>> 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).

I think I've addressed that in the comment above. The example to apt
is inappropriate as the basic model differs. Canonical or Debian
developers are the gatekeepers that I trust. There is no gatekeeper on
pypi.

>>> 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.

I'll gladly help to make that happen.

Thanks
ZK

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREm/oAAoJECiU6TooxntHF+EQAIpo/wQ/Q9NNSUrwiELrKT2W
pG2s6kPxvKrpzvuPzY3TKmtvMKQRdpnVYSzy2uS/IKoKC/xzxzQLTgL1W7xfmm/p
QGPijz1aoejI8e7q8zf7AGAOAtg0lBLon1OqInYr8XYpcwv/AR5dz9XzDrAZx9FN
Lb8GOsZAdtLHYHdDVYNK6EGKAWWC6r6y51nrMnHk1RtCcJE66O5b0caAqv+OecwS
PvgvRpkCNCdCgU4VrmxnmPTUJwV0JYtEeZpxBbKcIB3k4x6+QJNi8ye1EDUb1xRl
LKnAbaxW2n1MyWyiTWAbN9bckyEaD9v9Q2V+mBQ67volniWpVpj5l/54oXDiBfWd
xnGWCPmmwO6XKgv/UjDO4nkBiZ8PaQodY68pue+g8e/giJ//HoETnp5GpvEywTCJ
SRJnaq/XZw2jhYnYTWFfC//aO7U6Msk8pEuDG+chS+kVo7uUodz+k4Mpd8Z4MCYw
IbpOrsWXgaC53JGyjTyc9faFJjEm803q/Cp/+KBDmk+cOJbI5CNGt1nyzzyssuVL
aXK6idXPO+9tatRjgKHCV7RYoAQUfCHRroSa962z/epmqieWW+tiIfWzoWEXpihJ
wtev1et1Owgwf6WgYQJ9n9LrxM9nSN3GryuLVdlzPMxMNcg+RAoCl95H3OJ7tRWp
2SA1/Xa6Rq49y0qcO4Ya
=ObXe
-----END PGP SIGNATURE-----