Add RFC for upstream package source handling
Add an RFC that proposes choosing transparent sources by default and adds guidelines for the handling of cryptographic signatures for Arch Linux package sources.
See the rendered version.
Signed-off-by: Robin Candau antiz@archlinux.org
Signed-off-by: David Runge dvzrv@archlinux.org
Merge request reports
Activity
added 1 commit
- fbdc1b86 - Add RFC for upstream package source handling
added 1 commit
- 6149d383 - Add RFC for upstream package source handling
As seen with @dvzrv, I shared this RFC to the distributions mailing list, so we can hopefully get some input from other distributions / package maintainers that face similar challenges.
Edited by Robin Candau- Resolved by David Runge
It's nice to see transparent sources being preferred over intransparent but crypto-graphically verifiable custom tarball.
Regarding reproducibility and checksums, I want to bring up a discussion about the usage of GitHub(or other forge) auto-generated patches like
this-rfc.patch::https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46.patch. Fetching patches this way is convenient but harms reproducibility because the generated patch can change and no longer match the checksum. One of the reasons that this happens is the short commit hash grows over time as the git repo grows(archlinux/packaging/packages/chromium!3 (closed)). For GitHub, there appears to be other cases where the patch content can change when the short commit hash doesn't grow(archlinux/packaging/packages/gcc!2 (closed)). Naturally one way to improve reproducibility is by disallowing fetching git forge autogenerated patches but keeping them in the PKGBUILD repo. - Last reply by Robin Candau
- Resolved by David Runge
Some pypi tarballs (eg. many projects from the Jupyter stack) ship JS assets which are not in git. The alternative is downloading them at build time. Should some recommendation be added for these cases?
- Last reply by Robin Candau
added 1 commit
- 25ca58cf - Use a more precise wording for the VCS Object source type
- Resolved by David Runge
Overall a lot of good stuff here. There is several words introduced here which is 50/50 described and explained and sometimes just assumed to be words people know. I think we need to figure out whom the target audience of the text is. Is it only the expert that has been packaging for years, or also new packagers interested in the topic?
If we want to target the latter case then we need to be a bit more educational in some parts.
- Last reply by David Runge
added 10 commits
-
4c426b57...5319b12b - 6 commits from branch
archlinux:master - c4defad3 - Add RFC for upstream package source handling
- 302a4d7c - Use a more precise wording for the VCS Object source type
- 6113c8ad - Wording improvements
- 934ae63a - Add section about handling of patches
Toggle commit list-
4c426b57...5319b12b - 6 commits from branch
added 1 commit
- 176ac31f - Rename "Advice for source selection" section to "Conclusion"
added 1 commit
- 4bcdbf88 - Add better introduction for "Transparency" section
added 1 commit
- cba8d5e7 - Add information on offline proofs to "Sigstore" section
added 1 commit
- d45fec9b - Extend summary to clarify target audience and scope of the RFC
added 1 commit
- f56e0487 - Be less specific about sigstore identity providers.
added 1 commit
- 7e859dc2 - Remove the use of "graph" from future work with in-toto
-
This RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/ZUXBOXGW7RJF3SJ25IRX7FKDUUU3PUQX/
I agree with all the content. Only comments would be to limit the use of 3rd party verification as that places part of the process outside your control and you cannot be assured any such service will continue indefinitely.
There are a few opportunities for grammar/style improvements. Consider the alternate wording for introductory paragraphs to simply make it a tad more concise:
According to the "Triangle of Secure Code Delivery", transparency is considered one of the pillars of secure package delivery. For any distribution this transparency extends to the source code from which those packages are built. Transparent sources allow easy audit of individual changes via version control systems. This also allows (auto-generated) release artifacts to the version controlled files they originate from.
and
Nontransparent sources do not provide access to their version control systems. Only large aggregate changes are publicly visible which may include custom source tarballs (sometimes containing artifacts from unknown sources). These type of sources frustrate the ability to audit changes, apply patches and reliably maintain a project.
(
intransparentis a word, circa 1840, butnontransparentis in much more common use [it's not even underlined in red here])For custom tarballs, the following is a shortening to consider:
Custom source tarballs created on unknown systems, potentially by unknown users are less transparent and auditable because their content cannot be guaranteed to only contain artifacts from the version controlled repository.
Also under the GPG section
"allows to"isn't really a thing."can"works much better, e.g.... which can cryptographically verify a statement about a certificate issued by another.
I also think there needs to be a paragraph on the repackaging of upstream (or custom) binaries. I've notice a significant recent jump in those type packages. I've always viewed anything but an 100% verifiable upstream binary (e.g. vscode from MS, etc..) as being less trustworthy than custom tarballs. They should receive mention in this document.
All and all Great Job! Operational Frameworks and Plans are necessary, but always one of the less glorious matters to do. Like doing taxes...
Edited by David C. Rankin
