Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#69459 - Makepkg assumes .asc files are detached signatures

Attached to Project: Pacman
Opened by Setpill (setpill) - Thursday, 28 January 2021, 14:25 GMT
Task Type Bug Report
Category makepkg
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 5.2.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:

Maintainers of lnd switched their binary signing scheme from a manifest + detached signature to multiple manifests (from different devs) with attached signatures. Makepkg does not understand this, and errors out when you have some_source_file.asc but no some_source_file.

I've managed to work around this limitation for now by renaming the signed manifests to .txt (instead of .txt.asc) and performing gpg signature checks in prepare(), but this is an ugly workaround that neuters validpgpkeys.

Steps to Reproduce:

1. In a PKGBUILD, source any .asc file that consists of a signed message with attached signature. E.g. https://github.com/lightningnetwork/lnd/releases/download/v0.12.0-beta/manifest-roasbeef-v0.12.0-beta.txt.asc
2. Try to build it.
This task depends upon

Comment by Morten Linderud (Foxboron) - Thursday, 28 January 2021, 14:32 GMT
This is upstream doing something weird and not really a makepkg issue as far as I can see. How would this realistically be solved?
Comment by Setpill (setpill) - Thursday, 28 January 2021, 14:47 GMT
Why is upstream doing something weird? gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc functions perfectly fine. It's just that the verify_file_signature() function in /usr/share/makepkg/integrity/verify_signature.sh builds in an assumption that does not hold.

The solution would be to fix that function to be able to handle attached signatures.
Comment by Morten Linderud (Foxboron) - Thursday, 28 January 2021, 14:56 GMT
No, it's actually avoiding a pitfall of gnupg where `gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc` is ambiguous if it's validating a clear signed file or it's a detached signature of `manifest-roasbeef-v0.12.0-beta.txt`.

For detached signatures you *need* `gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc manifest-roasbeef-v0.12.0-beta.txt`, else you can encounter scenarios where it's not clear what is being authenticated.
Comment by Eli Schwartz (eschwartz) - Thursday, 28 January 2021, 15:33 GMT
makepkg does not support manifests either. Ask upstream to provide detached PGP signatures directly on the actual archives.
Comment by Setpill (setpill) - Thursday, 28 January 2021, 15:53 GMT
I've reopened the issue in upstream about providing detached signatures, however I don't think it's likely I can convince them to sign each binary archive individually. They have 3 maintainers signing the releases, and provide builds for ~30 platforms. Is there anything wrong with just doing `sha256sum --ignore-missing -c "manifest-v$_pkgver.txt"` in prepare()? (Assuming, of course, that the manifest is signed with a whitelisted pgp key)
Comment by Eli Schwartz (eschwartz) - Thursday, 28 January 2021, 17:13 GMT
Signing each binary individually means uploading 60 files instead of 30, then? Still sufficient quantity that:
- they should be scripting this, at which point the number does not matter
- they should consider a dedicated website listing that lets them use something other than the Github Releases simple file list.

e.g. you could then list lines to reduce cognitive overhead like

Source code:
lnd-source-v0.12.0-beta.tar.gz (GPG)

Windows Binaries:
lnd-windows-386-v0.12.0-beta.zip (GPG)
lnd-windows-amd64-v0.12.0-beta.zip (GPG)

Linux Binaries:
lnd-linux-386-v0.12.0-beta.tar.gz (GPG)
lnd-linux-amd64-v0.12.0-beta.tar.gz (GPG)
lnd-linux-arm64-v0.12.0-beta.tar.gz (GPG)

MacOS Binaries:
lnd-darwin-amd64-v0.12.0-beta.tar.gz (GPG)

Other binaries:
lnd-netbsd-amd64-v0.12.0-beta.tar.gz (GPG)
lnd-openbsd-386-v0.12.0-beta.tar.gz (GPG)
lnd-solaris-amd64-v0.12.0-beta.tar.gz (GPG)
lnd-dragonfly-amd64-v0.12.0-beta.tar.gz (GPG)

Github Pages could do this. Would entail either linking to the chaotic Releases attachments, or checking the files into a github repo "lightningnetwork.github.io" which might grow in size quite fast due to retaining old releases.
Comment by Setpill (setpill) - Sunday, 31 January 2021, 11:11 GMT
> No, it's actually avoiding a pitfall of gnupg where `gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc` is ambiguous if it's validating a clear signed file or it's a detached signature of `manifest-roasbeef-v0.12.0-beta.txt`.

I don't think this is accurate. The script already contains the following code:

```
149 │ case "$ext" in
150 │ gz) decompress="gzip -c -d -f" ;;
151 │ bz2) decompress="bzip2 -c -d -f" ;;
152 │ xz) decompress="xz -c -d" ;;
153 │ lrz) decompress="lrzip -q -d" ;;
154 │ lzo) decompress="lzop -c -d -q" ;;
155 │ Z) decompress="uncompress -c -f" ;;
156 │ "") decompress="cat" ;;
157 │ esac
158 │
159 │ $decompress < "$sourcefile" | gpg --quiet --batch --status-file "$statusfile" --verify "$file" - 2> /dev/null
```

For clearsigned files, "cat" decompression works perfectly fine if the `--verify "$file"` is ommitted and `$sourcefile` has the value of `$file`. The only pitfall is that the clearsigned file shouldn't be used directly but rather the output of a `gpg -o` command.

@eschwartz you assert this is how upstream should do things, but it is not clear to me why. Is there anything about that way of doing things that would actually increase security?
Comment by Eli Schwartz (eschwartz) - Sunday, 31 January 2021, 14:04 GMT
Once again: makepkg does not support manifests, period. There are entirely too many non-standard ways to create such manifests (yes, we've been asked about several of them in the past) AND the fact that they typically -- and in your case definitely -- permit short-circuiting checks by verifying files outside of the $SRCDEST and/or contain multiple elements that need to be ignored makes for either awkward filtering or (in the event of coreutils *sum-compatible files) insecurely using --ignore-missing.

We're not implementing all of them, and we're not implementing some of them just to have people protest that theirs was left out.

It's a big fat hassle and has no real advantage if upstream does things correctly. There are only a tiny handful of upstream projects that provide signed manifests but not signed archives. Most projects, if they provide manifests at all, provide UNSIGNED manifests. The last AUR package that was used to justify this feature request no longer needs it because upstream now signs the binary directly.
Comment by Eli Schwartz (eschwartz) - Sunday, 31 January 2021, 14:11 GMT
Implementing non-detached PGP verification is exceedingly unlikely to happen, since it renders the original file useless except via processing with gpg, and --skippgpcheck exists, and makepkg is supposed to handle transparent decompression, and because non-detached PGP signatures make no sense except for messages rather than source files (which again, we don't support, so why exactly should we add code to not support it but kind of maybe support it just a teeny bit).
Comment by Setpill (setpill) - Sunday, 31 January 2021, 17:14 GMT
Ack re: arguments against manifests and clearsigned sigs. Unfortunately I have no direct influence on upstream's signing scheme. I'll pass along the feedback, but in the meantime I still have to make do with what's there. I've implemented hardening against the pitfalls you mentioned, though I'm afraid that doesn't make the PKGBUILD exactly easier to parse.

Loading...