Open Stack

> On Nov 14, 2014, at 1:57 PM, Thomas Goirand <zigo at debian.org> wrote:
> 
> On 11/14/2014 08:48 PM, Matthias Runge wrote:
>> On 13/11/14 19:11, Donald Stufft wrote:
>> 
>>> As far as I’m aware npm supports TLS the same as pip does. That secures the
>>> transport between the end users and the repository so you can be assured
>>> that there is no man in the middle. Security wise npm (and pip) are about
>>> ~95% (mad up numbers, but you can get the gist) of the effectiveness as the
>>> OS package managers.
>> 
>> Oh, e.g rpm allows packages to be cryptographically signed, and
>> depending on your systems config, that is enforced. This is quite
>> different from just tls'ing a connection.
>> 
>> Matthias
> 
> Just like the Debian Release file is signed into a Release.gpg. So, the
> RPM system signs every package, while in Debian, it's the full
> repository that is signed. That's 2 different approaches that both
> works. pip doesn't offer this kind of security, but at the same time, is
> there any kind of check for things that are uploaded to PyPi? Is there
> at least a peer review process?

The entirety of PyPI is signed. It’s not possible to get a copy of our equivalent
to Release.gpg that isn’t cryptographically proven to have been sent by a server
possessing our RSA private key.

No, PyPI is not a curated repository, nor are any of the language repos that
I’m aware of. That really has nothing to do with securely fetching a particular
package, it only has to do with whether the contents of said package are safe
to use. It means that people installing a package from PyPI have to decide if
they trust the author of the package prior to installing it, but if they do
trust that author then it is roughly as safe to install from PyPI as it is to
install from Debian. The Linux distros are curated repositories so you need to
decide if you want to trust the gatekeepers of the distro instead of the authors
of the software you’re using (or really you probably need to trust both since
a malicious author could likely hide back doors that would go unnoticed during
packaging as a .deb).

> 
>> You do realize that TLS provides cryptographic proof of authenticity
>> and integrity just like PGP does right? (It also provides the cool
>> benefit of privacy which PGP signing does not).
> 
> Do you realize that with the TLS system, you have to trust every and all
> CA, while with PGP, you only need to trust a single fingerprint?

You absolutely do not need to trust every single CA, or even any CAs at all.
If I recall npm pins which CA they trust. Pip doesn’t (yet) do this because
of some historical reasons but it’s on my list of things as well. It’s no
harder to limit the set of CAs or even individual certificates that are accepted
as valid than it is to limit the set of PGP keys you trust.

> 
>> All this isn't to say that TLS is 100% as good as using something
>> like PGP for signatures though.
> 
> I don't agree. I don't trust the CNNIC or the hong-kong post office,
> though their key is on every browser. I do trust the Debian PGP key
> generated by the Debian team.

See above, you’re operating under a misconception that TLS mandates using
the same set of CAs as the browsers use.

> 
>> TLS is a fairly decent way of securing a package infrastructure
>> though, it prevents all of the major attacks that PGP signing does in
>> practice but it moves the "high value" target from the build machines
>> to the web servers [...]
> 
> And ... to a huge list of root CA which you have to trust.

Already discussed above.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA