Closed Bug 1252876 Opened 8 years ago Closed 6 years ago

Create a chain of custody for binaries that we ship

Categories

(Release Engineering :: Release Automation: Other, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: catlee, Assigned: mozilla)

References

Details

When shipping builds to users, it's important to be able to demonstrate that the entire process from source code to final bits are handled by trusted machines. We're building tools like Taskcluster with strong security in mind so that unauthorized clients can't request arbitrary builds to be signed or released, for example. However, simply having strong authentication doesn't give us an independently verifiable audit trail of what systems were involved in a release process.

We would like to create a 'chain of custody' for release tasks. Each process in the pipeline would require a validly signed message as input to start, and each process would generate a signed manifest as part of its output. Individual processes may not need to verify the entire chain of custody, perhaps only parts which make irrevocable, user impacting changes need to do more complete verification (e.g. pushing updates to AUS, signing binaries, copying binaries to CDN mirrors).

Some more concrete examples may help:
* ship-it requires multiple authenticated users to start a release. Starting a release generates a signed message containing the identifies of the users who initiated it. Downstream processes can validate that the release was initiated by ship-it, with the required number of users.

* Builds generate a signed manifest that indicate things like:
** names, sizes and hashes of all artifacts
** docker image id used, EC2 instance id, AMI id
** client id of task creator (e.g. ship-it or mozilla-taskcluster)

* Funsize tasks to generate signed partial updates require the task to be signed with a trusted key.

* The tasks that copy files to our final S3 buckets (the "beetmover" tasks) should verify the signatures of all upstream tasks.
This is future security work; we will not be requiring this for our initial migration to Taskcluster.
Assignee: nobody → aki
Depends on: 1298553
Depends on: 1309293
Depends on: 1317789
I think this is fully solved by chain of trust, combined with ship-it v2 and balrog multi signoff,
catlee: do you want to leave this open, or say cot v1 is resolved, and shipit v2 and balrog multi signoff are in progress in other bugs?

If we leave open, we could attach dependencies like the above two wip projects, and the funsize/pushapk cot bugs.
Flags: needinfo?(catlee)
I think we need all platforms using cot before calling this fixed. shipitv2 and balrog aren't blockers though IMO.
Flags: needinfo?(catlee)
Priority: -- → P1
I think we can call this fixed for Fx59+.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.