auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
ohai! 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: https://vulns.xyz/2022/05/auth-tarball-from-git/ Let me know what you think - that's all, kpcyrd
[arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
Le 29/05/2022 à 14:40, kpcyrd a écrit :
ohai!
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:
https://vulns.xyz/2022/05/auth-tarball-from-git/
What is the advantage over properly pinning the tag using its blob value
(`git rev-parse v${pkgver}`, see e.g.
https://github.com/archlinux/svntogit-community/blob/packages/gitea/trunk/PKGBUILD#L25=)?
This is how we solved tag pinning for years, and is much simpler to do
in the PKGBUILD.
Regards,
Bruno/Archange
Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
On 2022-05-29 12:40:22 (+0200), 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: > > https://vulns.xyz/2022/05/auth-tarball-from-git/ > > Let me know what you think - that's all, Hi, in your article you are missing the commit pinning strategy, which should usually be used (admittedly a few of my packages also don't use that yet... :S) for scenarios where git based VCS sources are used and signed tags should be validated. According to how one can use VCS sources [1], it is possible to pin to a commit. This commit can be the signed tag object as retrieved by using git ls-remote [2]. There is no tooling in the context of our package tooling that allows for automating this (e.g. bump to new version, automatically retrieve the given commit checksum to pin), but it is a viable option to pin a given signed release by its commit checksum and have the `?signed` check as well, while continue using VCS sources. Best, David [1] https://man.archlinux.org/man/PKGBUILD.5#USING_VCS_SOURCES [2] https://man.archlinux.org/man/git-ls-remote.1 -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
Le 29/05/2022 à 19:58, David Runge a écrit : On 2022-05-29 12:40:22 (+0200), 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: https://vulns.xyz/2022/05/auth-tarball-from-git/ Let me know what you think - that's all, Hi, in your article you are missing the commit pinning strategy, which should usually be used (admittedly a few of my packages also don't use that yet... :S) for scenarios where git based VCS sources are used and signed tags should be validated. According to how one can use VCS sources [1], it is possible to pin to a commit. This commit can be the signed tag object as retrieved by using git ls-remote [2]. There is no tooling in the context of our package tooling that allows for automating this (e.g. bump to new version, automatically retrieve the given commit checksum to pin), but it is a viable option to pin a given signed release by its commit checksum and have the `?signed` check as well, while continue using VCS sources. I would even argue that if someone wants to spend time on developing some helper tool, I would rather see an updpkgsums-like one that retrieves the commit or tag hash from the pkgver and source url and update the _commit or _tag variable in the PKGBUILD. ;) Regards, Bruno/Archange
Re: [arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
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: > > https://vulns.xyz/2022/05/auth-tarball-from-git/ 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-rfcs.rst [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 signature.asc Description: PGP signature
Re: [arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
On Sun, May 29, 2022 at 10:25:52PM +0200, Jonas Witschel wrote: > > 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]. I think namcap should get support for warning against this. There is quite a bit of room for improvement over this I reckon. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
On 30/5/22 06:25, Jonas Witschel wrote: 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. I thought this was already the standard. There were lots of bug reports (and a todo list?) to remove people using a tag a while back. Is there just a lack of detailed PKGBUILD guidelines? Allan
Re: [arch-dev-public] Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
On 2022-05-30 07:46, Allan McRae wrote: > On 30/5/22 06:25, Jonas Witschel wrote: > > 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. > > I thought this was already the standard. There were lots of bug reports > (and a todo list?) to remove people using a tag a while back. > > Is there just a lack of detailed PKGBUILD guidelines? I could not find it in the package guidelines, so there is definitely a documentation issue. Therefore I amended the wiki accordingly: https://wiki.archlinux.org/index.php?title=Arch_package_guidelines&diff=731044&oldid=726554 On 2022-05-29 23:20, Morten Linderud wrote: > I think namcap should get support for warning against this. There is quite a > bit > of room for improvement over this I reckon. This sounds like a good idea as well in order to increase visibility, since it can be hard to keep up with guideline changes (especially if not communicated via a mailing list discussion or an RFC, unlike this one). Cheers, Jonas -- Jonas Witschel Arch Linux Developer, Trusted User and security team member PGP key: FE2E6249201CA54A4FB90D066E80CA1446879D04 signature.asc Description: PGP signature
