composer / composer/packagist

[Secure Code Delivery] Stream Updates to a Chronicle

Open
#797 18 comments 52 reactions 0 assignees View on GitHub
Dominant language
PHP
Stars
1.8k
Forks
488
Avg merge
2d 12h
Merged PRs (30d)
24

Description

Hi Packagist team.

I've been working on trying to make **secure automatic updates** available to software developers the world over, as discussed [here](https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers), [here](https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship), and [here](https://defuse.ca/triangle-of-secure-code-delivery.htm)

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
* Privilege separation

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:

1. Userbase consistency verification, for all tagged releases.
2. Public key trust, for implementing cryptographic signatures in Composer (or a Composer plugin)

## Solution

1. Setup a [Chronicle](https://github.com/paragonie/chronicle) instance.
2. 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
3. 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](https://theupdateframework.github.io/) 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.)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.