3 ms·

A really powerful thing that I think is extremely underutilized for this is the ability to sign git tags. Using that it should be very possible to allow for tru

A really powerful thing that I think is extremely underutilized for this is the ability to sign git tags. Using that it should be very possible to allow for trusted pinning against a source code version that is easily replicated in mirrors.

eru 11y ago
Why not pin against the git hash?
- jon-wood 11y ago
  Because while its difficult, I don't think its impossible to force a hash collision, making it theoretically possible to push malicious code that would look as if it was the trusted version you want to use.
  - pflanze 11y ago
    Signed Git tags reference the same hash (commit id) that you could pin against directly.
- 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.

eru 11y ago

Why not pin against the git hash?

jon-wood 11y ago
Because while its difficult, I don't think its impossible to force a hash collision, making it theoretically possible to push malicious code that would look as if it was the trusted version you want to use.
- pflanze 11y ago
  Signed Git tags reference the same hash (commit id) that you could pin against directly.
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.