On July 28, 2014 at 9:13:03 PM, Giovanni Bajo (ra...@develer.com) wrote: > > My solution is far far simpler than TUF. To me, it’s a reasonable compromise > between complexity > of implementation, time/costs required for all involved parties, and > decreased security.
The package signing portions of it have little to no benefit over just using TLS, or just using an online key and not involving the authors at all. I don't believe that the additional complexity for little to no additional security past what is already there is worthwhile. > > PEP 458 includes both offline root keys and an "N of M" signing model > > specifically so > compromise of a single administrator account can't break the whole system > (aside from > DoS attacks). > > > It depends on your definition of “compromise of a single administrator”. > Obviously > if you compromise the root signing key, then yes, the N/M model helps, but > that key doesn’t > exist in my PEP in the first place (which means that my PEP is simpler, > requires less work > on administrators, less key management, etc.). If with “compromise of an > administrator” > you intend that an attacker can login into PyPI and become root, than I > maintain that PEP458 > and my PEP are mostly equivalent, in that they offer close to no protection; > the attacker > can compromise all packages. The lack of an offline key also means your PEP provides little to no additional benefit over TLS or just having an online key and not involving the authors at all. > > >> 2. What level of damage mitigation are we aiming to attain in the event > > >> of a full PyPI > compromise? (i.e. attacker has full control over absolutely everything > published > from PyPI) > > > > > > I’m not sure I understand the question or how it differs from the > > > previous one. The thread > model section on "PyPI server compromise” in my PEP has some details though. > > > > And it amounts to minimal additional defence beyond where we are today. > > > Yes. I don’t claim otherwise either. I'm not sure I'm understanding you correctly, if you don't claim that this PEP provides more than minimal additional defense beyond where we are today, then what is the point of it? Why would we replace something that already exists for something that doesn't exist and is more complex if it doesn't provide more than a minimal amount of additional defense? > > >> 3. Assuming an attacker has fully compromised DNS and SSL (and hence can > > >> manipulate > or replace *all* data purportedly being received from PyPI by a given > target), what additional > level of integrity is the "end-to-end" signing process adding? > > > > > > In all cases in which the trust file is cached / edited with no automatic > > > updates, it > fully guarantees that no compromised packages can be installed in the user > machine. > This wouldn’t be the standard setup for most users. > > > > Except it allows known-vulnerable versions to be installed. > > > Well, known-vulnerable versions are a problem in deployments, not > development. If > you’re fully compromising DNS and SSL of a deployment machine, there are far > easier way > to attack your target. Moreover, in deployments, most people do fix versions > of packages > they install. I don’t think anybody is running deployments in which they > install whatever > latest version of Django PyPI serves them. In that case, serving a different > version > would still make pip abort installation. > > Protecting development machines against code execution is fully achieved by > my PEP > with a manually-edited (or peep-like edited) trust file. If someone does ``pip install thing``. They are going to get whatever the latest version is according to a file which is only secured by TLS. Maybe that's version 2.2.1 instead of 2.2.2 where 2.2.1 has a known security flaw that allows arbitrary code execution or something else bad. > > > >> 4. What level of guarantee will be associated with the signing keys, and > > >> are package > authors prepared to offer those guarantees? (The only dev community I've > really talked > to about that is a few of the Django core devs, and their reaction was "Hell, > no, protecting > and managing keys is too hard”) > > > > > > If package authors are unwilling to handle signing keys, PEP 458 is also > > > doomed, and > moreso since it would use an obscure, custom, one-purpose signing key and key > tools, > with no extensive documentation on proper handling on multiple operating > systems and > development scenarios. I thus don’t see how this question is pertinent in > evaluating > my PEP vs PEP 458. Right, I don't think anyone here have said that implementing TUF is a forgone thing. It's a perfectly valid answer that we don't do package signing, or we only do package signing by PyPI itself and we don't involve the authors at all because we don't believe the cost is worth it. This is a question that needs answered still, and it's as valid of a question on the TUF PEP as it is on this PEP. Are people even going to bother using this? Even the most amazing solution ever is worthless if nobody uses it. > > > > The signing algorithm isn't the interesting part of TUF - it's the key > > management and > trust delegation. This question is relevant to both proposals, as the case > where PyPI > is signing on behalf of the developer is a critical one to handle in order to > keep barriers > to entry low. > > > > A "solution" that leads to end users just turning off signature checking > > (because most > packages aren't signed) is undesirable, as it means missing out on the > additional integrity > checks for the PyPI-user link, even if those packages are still vulnerable to > PyPI compromise. > > > you don’t need to turn off signature checking, you can simply allow > installation of packages > with missing GPG signatures. So again, if developers refuse to touch keys, > you’re not > affecting security of users installing signed packages. You're not affecting the security of people who only choose to install signed packages, however if any reasonable set of dependencies as a high chance of requiring allowing unsigned dependencies then that does affect the security of things. IOW the likelihood that people are going to be willing to use this thing at all is an import consideration, and one that the TUF PEP handles by offering the unclaimed/recently-claimed/claimed roles to allow authors to opt out of managing keys and present their users with a lesser secured system. Now a problem with the TUF PEP is similar to what I just said above, if most people opt to stay in unclaimed then the benefits of TUF over just using TLS or using a single online key that PyPI uses to sign everything and the authors don't participate is severely limited. This is one of the questions that weigh heavily on my mind about if TUF is worth it. Will enough authors opt in to manage their own keys? How likely will it be that any particular set of reasonable dependencies will require at least one package in unclaimed? -- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
