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

[Zygmunt Krynicki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 06.02.2013 16:24, Giovanni Bajo pisze:

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

You would first download django (either signed or not) and get
prompted if you want to trust the signer for that project (or if the
file was not signed, to trust this particular file for django in the
future).

As you go you would see many prompts like that, roughly identical to
what you get when SSH-ing to a new system.

Note: At each step you could stop to manually examine the freshly
downloaded file. The user interface should be brief but to the point.

The most important aspect is what happens the second time you install
those packages -- you never get prompted (unless a package was
unsigned and got updated in the mean time).

I realize this interface is not perfect but it solves practically all
of the current issues. Most importantly it can be applied to all
existing software today, so we get the benefits without asking
everyone to fix their story.

It still remains open though, how users should get notified about
malware (other than being burnt and manually revoking some trust
records and spreading that through their network of connections).

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

Well not entirely. I agree there is something in the middle and this
is why in the 'distrust' tool 'dist' stands for 'distributed'. I
believe that with the collective power of developers and users
installing software using that trust system we can quickly build a
pretty full network of trusted software (via peer trust, if you trust
some package and I trust you, I can instruct the software to trust
your choices as mine). Also, everyone can share their signed trust
records.

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

I agree that the proposed solutions protect against many class of
attacks and I will welcome them with open arms.

In any case, nothing here prevents both approaches from being
developed. When combined (if someone chooses to do so) they would give
even stronger protection.

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

That is all true. Then again, what I'm advocating for is not about
security but trust. Those seem related but are really separate in many
respects.

Thanks for the detailed responses
Zygmunt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREpDfAAoJECiU6TooxntHr98QAKqXcIt3op4syaCPARfFk8qj
kLvvchJgtoMSUiphbF9fvV+2I2PWjnlTci0S6QEjBG75ivt2E9Vm9U9SqcgE26v4
MzOmku0QO88dKo9n4xmHPz2Z6miZ6n0q5FiIEfXPzl2O7yPOSsU7RCs/IWvN60Qn
mqp/NhrSbkTFWWjFDZjo39ZwhDJuEgqovcCVtnMHA+uREZKW+yt1nBDLDkFd60Zr
zOwv3VoFaRONk7lpwHa7ntjbRF3ev6uVIMRTpekwO1OM/KN3ZC255DCb6Re4aBY1
uuDh5/3g8ySfD3RiD3kWCWampzG7a3cDq+I/vVisdt90/1TsaSeNyiwFgBSDm/GC
bsmkWv9yXDS/0tZE8sWryk/juODucTJq1uH+tftLRpsszrrrOsrEXIHKxIRZyl9K
WzRTq4yH0OUICB/cQc5lBJEMI/v1jpY+TaMP6vzwiOwGfpeVIQwYPXsDb/oHJ4cr
nb8x4tlJqtDg0AxQ2XIcqpL6c4bceaPfYJ7ZXNizjBKQqoxQ9NHg2MTrVXbh6GnR
ZqAck3nWNTOEerO4RhsJT1GRBwyk+WAZwynVijh2Q49MeAkpd9xnJqqD/UfFFraD
uuP58lZwyETzY/Ks6lvYusKlZ93+Hl3Snh5KDIZIIACUY2rOD6h8KCY6Jl8j4M91
hUC/hmjgFyJE+iW4ngu/
=9e11
-----END PGP SIGNATURE-----