Ocramius
commented
7 years ago This would be practically feasible only with PHP 7.2 and libsodium in it (feature freeze coming up fast!).
I already worked on WoT signatures in https://github.com/Roave/composer-gpg-verify, but that only works for git and gpg.
In order for this to work, we also need:
- A release tool that makes it easy to sign
zippackages (github and co generate and re-hash them periodically, which is useless) - A setup tool to make
gpgmore approachable to folks that don't understand asymmetric crypto - Rely only on either the
opensslorsodiumextensions for all operations in order to ensure compatibility for all those folks running on an "unfortunate" system setup (windows)
paragonie-scott
JABirchall
Ayesh
alcohol
sebastianbergmann
joepie91
Hi Packagist team.
I've been working on trying to make secure automatic updates available to software developers the world over, as discussed here, here, and here
There are many challenges involved (and several differing threat models), but in general, these are the problems that such a secure automatic update solution needs to solve:
However, we don't need to go whole hog on a total solution to this problem right out of the gate; and in fact, many of these challenges are irrelevant to Packagist. (This information is given just to provide background to the overall problem being solved.)
I'd like to propose a plan that allows Packagist that only solves two problems:
Solution
That's it?
More-or-less, yeah.
If this gets closed, I'll grant the Packagist Chronicle access to cross-sign onto a Chronicle that PIE is setting up for large projects to cross-sign onto. It may be wise to setup several other Chronicles that replicate the Packagist Chronicle.
The rest of the work needs to be done elsewhere.
What does this give us?
Like I said: Userbase consistency verification. All software updates will now be auditable; verifiable by anyone. That's a win that even ambitious projects like The Update Framework doesn't currently provide.
In addition, by tracking public key additions/removals, we can obviate the need to setup a certificate authority (and all the X.509/ASN.1 headaches), while still providing the same security guarantees.
We would be, in effect, creating a PKI based on public key pinning and certificate transparency for the PHP community from day one. No more unaccountable single points of failure, like the TLS certificate authority system in the days before CT. (If successful, I intend to replicate this effort in other software ecosystems.)