[arch-general] Proper use of signify in PKGBUILDs

[Eli Schwartz]

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