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:
- Reproducibility
- Authenticity
- Cryptographic signatures with trusted public keys
- Userbase Consistency
- (The focus of this ticket) -- everyone sees the same thing
- Freshness
- TLS or timestamped online signatures prevents downgrade ("Denial of Update") attacks
- Needs to be run at a regular interval (e.g. 15 minutes)
- Availability
- Implementation security
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:
- Userbase consistency verification, for all tagged releases.
- Public key trust, for implementing cryptographic signatures in Composer (or a Composer plugin)
Solution
- Setup a Chronicle instance.
- Update Packagist's backend to publish all of the following events to the Packagist Chronicle from step one:
- Software releases
- Added public keys per vendor
- Revoked public keys per vendor
- Update Packagist's UI to add a space for public key additions/revocations
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.)
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.)