4 ms·
I wrote the above on my phone, so I probably could have expanded more. I don't just mean pinning for a local build, I mean being able to publicly pin a version
by stormbrew 11y ago
I wrote the above on my phone, so I probably could have expanded more. I don't just mean pinning for a local build, I mean being able to publicly pin a version as being 'released' through signed commits, and that state propagating through mirrors in a way you can trust. This would make your git repo and your gpg key the source of truth on package versioning rather than offloading it to a mutable centralized service.
It'd still be valuable to be able to propagate revocations, to indicate versions that are no longer valid (because of security issues or what have you), but it would be entirely possible to have mirrors available for widely used packages that still have the correct signed sha for that version for projects that can't or shouldn't move on for whatever reason.
Basically I'm saying a released version of a package could quite easily be a tuple of the following:
- gpg key of project releaser
- sha of release tag
With auxiliary information relevant to discovering both newer versions and mirrors of older versions:
- canonical git repo where the tag and signature can be found, as well as future revisions of the same
- (optional) mirror repos where you can find the above if the canonical repo is not available.