On 2022-05-29 12:40, kpcyrd wrote:
I blogged about a new tool that can be used to verify a tarball from a signed git tag, while still pinning the sourcecode with >= sha256sum:
I agree with the previous posters that a comparison with the established method of pinning the hash of the tag object instead of the tag name would be in order. As far as I can see, for auth-tarball-from-git to provide an advantage over the established method, an attacker would need to have access to all of the following: 1. Commit access to the upstream Git repository. 2. Access to the private part of one of the PGP keys in $validpgpkeys (through a compromise or a malicious upstream). 3. The ability to produce a collision for hardened SHA-1 [1] with the additional constraint that both messages need to have valid signatures by the compromised PGP key from above. At the current point in time this seems to be infeasible, therefore I do not see a real advantage of the added complexity of using auth-tarball-from-git over the established method. Nevertheless I would love to see more (ideally all) packages using pinned tag object hashes over tag names, which I think would provide a tangible security benefit. The best way to achieve this might be writing a RFC [2] that deprecates pinning only the tag name. This best practice of using pinned tag object hashes could then be enforced by a tool like your recently created archlinux-inputs-fsck [3]. Note that this project currently does not recognise PKGBUILDs with pinned tag hashes as secure (because it does not distinguish between regular tag names and object hashes). For the reasons outlined by the previous posters I don't think this assessment as currently made by archlinux-inputs-fsck is justified [4]. Best, Jonas [1] https://git-scm.com/docs/hash-function-transition/ [2] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0001-using-rf... [3] https://github.com/kpcyrd/archlinux-inputs-fsck [4] https://github.com/kpcyrd/archlinux-inputs-fsck/issues/1 -- Jonas Witschel Arch Linux Developer, Trusted User and security team member PGP key: FE2E6249201CA54A4FB90D066E80CA1446879D04