<div dir="ltr">So we obviously have egg on our face about the domain expiry. Our sys admin should be fixing this now. <div><br></div><div style>I'm a bit crunched for time with other deadlines right now, but one quick thing I'd like to correct is that TUF works with package managers / metadata, etc. TUF certainly handles package managers and appropriately protects their metadata, which in turn makes sure that dependency resolution is secure, etc. </div>
<div style><br></div><div style>TUF does also prevent against replay attacks on old package versions (or at least those that were not valid within the lifetime of the timestamp.txt file and aren't earlier than the last time the user fetched a package.) Note that TUF does not preclude you from asking for foo-1.0 when foo-1.1 was released if there is a valid signed version of foo-1.0. It just makes sure that if you ask for foo you get foo-1.1.</div>
<div style><br></div><div style>I'll be happy to give a detailed look at the other proposal before PyCon and send some notes. (Unfortunately I have a conflicting venue I need to attend so will miss PyCon.)</div><div style>
<br></div><div style>Thanks,</div><div style>Justin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 10, 2013 at 9:18 AM, Giovanni Bajo <span dir="ltr"><<a href="mailto:rasky@develer.com" target="_blank">rasky@develer.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il giorno 10/feb/2013, alle ore 14:43, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> ha scritto:<br>
<div class="im"><br>
> On Sun, Feb 10, 2013 at 11:30 PM, Giovanni Bajo <<a href="mailto:rasky@develer.com">rasky@develer.com</a>> wrote:<br>
>> This is by far the biggest problem to be solved, and my document brings a proposal here. It would be great if the TUF guys reviewed it.<br>
><br>
> Ensuring we fully address the problems that are addressed by TUF is<br>
> more important than the question of whether or not we use the TUF<br>
> software itself. However, the concern I have with your proposal is<br>
> that I saw zero information regarding how it deals with attackers<br>
> supplying old versions of software,<br>
<br>
</div>It's true that it's something that my document doesn't cover, but there is a reason.<br>
<br>
The way TUF handles it, is through an automatic signing of a file called "timestamp.txt", using a fast expiring signature. This files basically contains (simplifying) a reference to the latest version of the software. Since the signature expires, an attacker cannot replay it.<br>
<br>
On PyPI, a maintainer is able to decide which is the current/available set of releases of a packages through the web interface of PyPI. This means that the maintainer can click a few buttons on the web UI, and the timestamp.txt should change to its desire, including reviving an old version of the software. So in a way, we're offering a feature that already *breaks* the feature that TUF is trying to protect against. An attacker with the user's PyPI password can revive any old version of the software.<br>
<br>
In the TUF complete model, this is less of an issue because all commands "release this", "unrelease this" are made through GPG-validated signatures. So to fully implement this, we would also need to modify setup.py to offer any package release management feature of PyPI.<br>
<br>
TL;DR: an integration of TUF doens't "magically" fix the replay attack of older versions, unless we also specifically modify distutils to include package management administrative commands to it, with GPG validation/signing, and we expose the corresponding webserver API from PyPI. We still need a design here.<br>
<br>
NOTE: within my proposal, an attacker with write access to the PyPI file storage area can't do a replay attack; in fact, even if it overwrites the contents of django-1.1.2.tar.gz{,.sig} with django-1.1.1.tar.gz{,.sig}, and even if the signature would be verified, the package metadata will show the 1.1.1 version, and thus pip would be able to detect the attack. I've clarified this in my document.<br>
<div class="im"><br>
> or, indeed, any description of the<br>
> threat model at all.<br>
<br>
</div>Can you please elaborate on what you expect to find as "thread model"? Every task in my document that is supposed to give an enhanced security explicitly lists the possible attacks that are prevented by implementing the task. This is my definition of "threat model", but maybe you are thinking of something different.<br>
<br>
Or maybe you would prefer to see all those sections together at the beginning of the document?<br>
<div class="im"><br>
> The parts of your proposal that I believe need to<br>
> be closely reviewed are:<br>
> - GPG vs PKCS#1<br>
<br>
</div>Do you have any specific open-source multi-platform implementation of PCKS#1 in mind? I think we don't want to write our own crypto here, especially since PCKS#1 is *really* tricky.<br>
<div class="im"><br>
> - your custom trust model vs TUF target delegation<br>
> - any threats that TUF covers and your proposal does not<br>
<br>
</div>To do this, we first need a proposal from TUF authors on how they plan to integrate it with pip/PyPI. On their website, there is (was) a preliminary document on this, but it just scratched the surface.<br>
<br>
Let me stress agan that TUF is just a component of the solution, because it's not a design for a package manager, just for a single-software update. There are important differences in how trust is handled (eg: for a specific software, you can embed the trust in the first version, and upgrade from there), while in a package manager the idea is that the user always starts with no trust on any package, but it still wants to install software given only its name.<br>
<div class="HOEnZb"><div class="h5">--<br>
Giovanni Bajo :: <a href="mailto:rasky@develer.com">rasky@develer.com</a><br>
Develer S.r.l. :: <a href="http://www.develer.com" target="_blank">http://www.develer.com</a><br>
<br>
My Blog: <a href="http://giovanni.bajo.it" target="_blank">http://giovanni.bajo.it</a><br>
<br>
<br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Catalog-SIG mailing list<br>
<a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/catalog-sig" target="_blank">http://mail.python.org/mailman/listinfo/catalog-sig</a><br>
<br></blockquote></div><br></div>