Open
Description
Description of issue or feature request:
Project releases should include in-toto metadata that can be used to validate the integrity of the release's software supply chain.
Current behavior:
Developer signatures can be provided for each release of the project, both on GitHub and PyPI. However, these signatures do not guarantee that some part of the source->release process was
not compromised.
Expected behavior:
The packaged release should include metadata and a way to verify that the project was packaged as intended. All steps of the source->release procedure should be properly signed and confirmed to be valid, as defined by the project developers.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
[-]Add in-toto metadata to releases to validate the integrity of its software supply chain[/-][+]Add in-toto metadata to releases to validate the integrity of their software supply chain[/+]jku commentedon Feb 17, 2022
I'm going to remove "good first issue": The description may be clear to an in-toto expert but as an example I wouldn't have any idea where to start implementing this.
Also editing the title to what I think the suggestion is
[-]Add in-toto metadata to releases to validate the integrity of their software supply chain[/-][+]Add in-toto metadata to python-tuf releases[/+]lukpueh commentedon Mar 15, 2022
With python-tuf builds becoming reproducible (see #1269) we can provide multiple in-toto links for any given release build each signed with a different maintainer key, and create a corresponding in-toto layout that encodes the key authorization and a signature threshold requirement.
See
apt-transport-in-totofor a detailed description of this scenario (note, the tool deals with Debian packages and therefor includes a lot of code that hooks intoapt, but the in-toto metadata scaffolding would be alike for Python wheels)