[arch-general] Proper use of signify in PKGBUILDs
I recently adopted the openbsd-manpages package[1], and wanted to verify downloaded files using OpenBSD's signify(1) tool. For each release of OpenBSD, you download the base public key[2], the architecture-specific files and the SHA256.sig[3] for those files. The files are verified by running: signify -Cp openbsd-65-base.pub -x SHA256.sig *.tgz The problem is that PKGBUILD thinks that the signify signature is a PGP signature, and tries to verify it against a non-existent file/PGP key. I've worked around this by renaming SHA256.sig to SHA256. Have any other packagers/maintainers experienced this problem, and if so are there any better solutions other than the one I mentioned? [1] https://aur.archlinux.org/packages/openbsd-manpages/ [2] https://ftp.openbsd.org/pub/OpenBSD/6.5/openbsd-65-base.pub [3] https://ftp.openbsd.org/pub/OpenBSD/6.5/amd64/SHA256.sig -- Stephen Gregoratto
On 7/21/19 2:19 AM, Stephen Gregoratto via arch-general wrote:
I recently adopted the openbsd-manpages package[1], and wanted to verify downloaded files using OpenBSD's signify(1) tool. For each release of OpenBSD, you download the base public key[2], the architecture-specific files and the SHA256.sig[3] for those files. The files are verified by running:
signify -Cp openbsd-65-base.pub -x SHA256.sig *.tgz
The problem is that PKGBUILD thinks that the signify signature is a PGP signature, and tries to verify it against a non-existent file/PGP key. I've worked around this by renaming SHA256.sig to SHA256.
Have any other packagers/maintainers experienced this problem, and if so are there any better solutions other than the one I mentioned?
[1] https://aur.archlinux.org/packages/openbsd-manpages/ [2] https://ftp.openbsd.org/pub/OpenBSD/6.5/openbsd-65-base.pub [3] https://ftp.openbsd.org/pub/OpenBSD/6.5/amd64/SHA256.sig
The non-standard "signify" utility is not supported by makepkg, and doesn't have a "solution" at all, really. It's never been an issue before, because as far as I'm aware people don't actually use it in the wild -- excepting, of course, OpenBSD itself, and you're attempting to package something produced by OpenBSD, which I suppose explains why you have such signature files to try verifying. ... As a matter of curiosity, how does renaming the file from SHA256.sig to SHA256 help you validate the contents using signify? Moreover, what good do the checksums do you, when it's the files themselves that you want to verify? The latter problem is why I'm incredibly frustrated by projects that use PGP, too -- when the only thing they sign is a file containing checksums, and not the actual source file. -- Eli Schwartz Bug Wrangler and Trusted User
On 2019-07-21 02:42, Eli Schwartz via arch-general wrote:
How does renaming the file from SHA256.sig to SHA256 help you validate the contents using signify?
I rename it in the source array: "SHA256::${_mirrorurl}/${pkgver}/amd64/SHA256.sig" That way makepkg doesn't think it's a PGP signature. Note that the SHA256.sig file has the checksums embedded in the file, as the signature/additional comments are at the top and take up at most two lines.
Moreover, what good do the checksums do you, when it's the files themselves that you want to verify?
Signify verifies the signature and then verifies the checksums of each file. While I could just use the sha256sums array, I prefer using signify as that is how the OpenBSD project distributes their files securely. Since these files can also be downloaded in the clear (FTP), verifying them becomes an absolute must.
The latter problem is why I'm incredibly frustrated by projects that use PGP, too -- when the only thing they sign is a file containing checksums, and not the actual source file.
I'm not sure what the problem is here, isn't validating the signature and checksums not good enough? -- Stephen Gregoratto
On 7/21/19 4:11 AM, Stephen Gregoratto wrote:
On 2019-07-21 02:42, Eli Schwartz via arch-general wrote:
How does renaming the file from SHA256.sig to SHA256 help you validate the contents using signify?
I rename it in the source array:
"SHA256::${_mirrorurl}/${pkgver}/amd64/SHA256.sig"
I asked you "how is simply downloading the signify file as a makepkg source useful, when makepkg won't use the signify file to programmatically verify the downloaded openbsd-manpages source tarball". You responded to the question: "Do you or do you not download this file, and how do you prevent GnuPG from trying to erroneously read it". (Since you've already stated this in the original post to arch-general, I don't know why you need to repeat it again, but okay.) If you want to continue talking right past what I say, it will be very difficult for me to effectively carry on a conversation with the intent of providing help and guidance on the "proper use of signify in PKGBUILDs".
That way makepkg doesn't think it's a PGP signature. Note that the SHA256.sig file has the checksums embedded in the file, as the signature/additional comments are at the top and take up at most two lines.
I was very much able to download the file and look at it myself. Once again, I do not see how that answers my question. Also: it's essentially a non-detached GnuPG signature in that respect, and files with the GnuPG signing data inline in the file itself, rather than being properly detached, are just as troublesome as files in strange and non-standard crypto tools. makepkg cannot recognize a foo.tar.gz.gpg file for the same reason actually nothing can: the internal tarball headers are obscured by an OpenPGP packet section, and you need to fiddle with the files using GnuPG first, and doing so will by default write to stdout (and is anyways difficult to distinguish from detached signatures without the actual file at all).
Moreover, what good do the checksums do you, when it's the files themselves that you want to verify?
Signify verifies the signature and then verifies the checksums of each file. While I could just use the sha256sums array, I prefer using signify as that is how the OpenBSD project distributes their files securely. Since these files can also be downloaded in the clear (FTP), verifying them becomes an absolute must.
Since this is apparently a very tough question to answer, maybe rewording it will help: who is running signify? According to makepkg, this is just "a source file". You don't need to tell me about the importance of verifying files downloaded over FTP. This is not a philosophy class and no one disputed the importance of this, so let's just assume we're all on the same page and get back to the thread topic: "successfully using signify in a PKGBUILD". That being the topic, would you like to clarify how your proposed model for executing the `signify` utility within a makepkg operation would work? Because to be honest, that's the only thing I've been asking about.
The latter problem is why I'm incredibly frustrated by projects that use PGP, too -- when the only thing they sign is a file containing checksums, and not the actual source file.
I'm not sure what the problem is here, isn't validating the signature and checksums not good enough?
Validating the signature of a file containing checksums, and *not* validating the checksums, is exactly what isn't "good enough". makepkg has no way to assert that the checksums in a "SHA256" file match the sha256sums=() array. If I'm going to copy the upstream project's sha256sums, downloading the file I copied them from doesn't provide additional security. -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, 21 Jul 2019 02:42:39 -0400, Eli Schwartz via arch-general wrote:
The latter problem is why I'm incredibly frustrated by projects that use PGP, too -- when the only thing they sign is a file containing checksums, and not the actual source file.
But it doesn't matter, since when the checksum is signed, it's more or less the same as signing the source file/s, that's why almost all simply sign a file containing one or more checksums. Why should this be frustrating? If we are able to ensure that a checksum isn't faked, IOW if can trust the checksum, than we are safe that a source file passing a check against the proven checksum is correct, too.
On 7/21/19 4:40 AM, Ralf Mardorf via arch-general wrote:
On Sun, 21 Jul 2019 02:42:39 -0400, Eli Schwartz via arch-general wrote:
The latter problem is why I'm incredibly frustrated by projects that use PGP, too -- when the only thing they sign is a file containing checksums, and not the actual source file.
But it doesn't matter, since when the checksum is signed, it's more or less the same as signing the source file/s, that's why almost all simply sign a file containing one or more checksums. Why should this be frustrating? If we are able to ensure that a checksum isn't faked, IOW if can trust the checksum, than we are safe that a source file passing a check against the proven checksum is correct, too.
i can't speak for why it bothers Eli, but it bothers me because that's exactly what GPG detached sigs are already: signed hash checksums. The signify method is a signed hash checksum of a (list of) hash checksum(s). To me it feels like an unnecessary abstraction when one could just provide .sig files for each file and be more widely compatible. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On 7/21/19 9:19 AM, brent s. wrote:
i can't speak for why it bothers Eli, but it bothers me because that's exactly what GPG detached sigs are already: signed hash checksums. The signify method is a signed hash checksum of a (list of) hash checksum(s). To me it feels like an unnecessary abstraction when one could just provide .sig files for each file and be more widely compatible.
The problem is a lot bigger, because "widely compatible" includes "being compatible with makepkg's official validation mechanism" and that unnecessary abstraction means it cannot, in fact, be used in makepkg after all. -- Eli Schwartz Bug Wrangler and Trusted User
participants (4)
-
brent s.
-
Eli Schwartz
-
Ralf Mardorf
-
Stephen Gregoratto