Provide detached binary signatures

[setpill]

Background

I'm trying to package the latest release for Arch (AUR package lnd-bin). Unfortunately, makepkg assumes that any somefile.txt.asc file is a signature for somefile.txt, whereas the different signed manifests are now self-contained. I intend to file a bug with makepkg about this, but in the meantime, would it be possible to provide separate manifests and signatures? Discussion on Arch bug tracker indicates that lnd's binary signing scheme is unsupported.

Your environment

• version of lnd
  • v0.12.0-beta
• which operating system (uname -a on *Nix)
  • Arch 5.10.10
• version of btcd, bitcoind, or other backend
  • Not relevant

Steps to reproduce

If needed I can share the PKGBUILD file, but it's a bit overkill to understand the problem at hand.

[guggero]

I think you can solve this by running gpg --output manifest-<username>-<version>.txt --verify manifest-<username>-<version>.txt.asc first. That will extract the signed manifest file and should allow you run the makepkg command.

If that doesn't work, I'd be interested in seeing the PKGBUILD file.

[setpill]

Unfortunately there is not much room in the PKGBUILD to execute arbitrary steps before the source files are automatically verified. I am currently working on a hack to trick the script into thinking it is unsigned, only to do the signature checking "manually" (still scripted) later. If that doesn't work, I'll recreate the initial "naive" PKGBUILD for v0.12.0 that breaks. In the meantime, you can see the old (v0.11.1) PKGBUILD at https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lnd-bin&id=af46491b041c3694b1d7f555dda403679f1e1874

[setpill]

Alright, I was able to make it work. Minor security regression because now I can no longer pin the pgp pubkey fingerprints in the PKGBUILD, but that's something that needs to be fixed in makepkg.

[setpill]

Reopening because on further investigation, cleartext signatures seem to have some pitfalls.

From discussion on the makepkg bug report:

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.

From the gpg manpages:

Note: When verifying a cleartext signature, gpg verifies only what makes up the cleartext signed data and not any extra data outside of the cleartext signature or the header lines directly following the dash marker line. The option --output may be used to write out the actual signed data, but there are other pitfalls with this format as well. It is suggested to avoid cleartext signatures in favor of detached signatures.

I've tested and it's possible to insert lines into manifest-roasbeef-v0.12.0-beta.txt.asc (outside of the signed message block) without invalidating the signature. This is not possible with detached signatures. It's possible to only process the signed part with the gpg command above, but if simply verifying the clear-signed file and then cat ing the entire file into some command, unverified input may unexpectedly be processed.

[Roasbeef]

(outside of the signed message block

Is this surprising behavior though? As long as the contents/hashes being changed invalidates the signature, then I'm not sure that there's an issue with it.

[setpill]

It's one of those "not surprising if you think about it but it's easy to overlook" kind of things, which is probably the biggest reason for any security flaw to exist in software. For example, if I take a naive approach, and do

gpg --verify manifest-roasbeef-v0.12.0-beta.txt.asc && sha256sum --ignore-missing -c manifest-roasbeef-v0.12.0-beta.txt.asc

there will be a warning about improperly formatted lines, but I can choose to ignore those, expecting them to be the signature and pgp block demarcation. I might (naively, erroneously) expect there to be an error if any line was added to the .asc (outside of the signed block). There won't be. If github were to provide a message signed with roasbeef's pgp key that does not include any sha sums, and appended a sha256sum of a malicious binary, it could sneak it past this verification scheme. Couldn't quickly find one for roasbeef but e.g. I retrieved this message from guggero's keybase, signed with the same key as the releases:

-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v2.1.3
Comment: https://keybase.io/crypto

yMNqAnicbVJtUFRVGN6VBQRyoiI/CCa4ZE3Njp77ee5dJlELAqpBGEN02HbP3Xvu
7g3Zpf1g24RpHGOCMFSgoEYMcaESNBxsSHQqksBAzOKjRMemcsDio2RkE/you4z+
8/w4Z877Pu9znvd5T8+yEE2ktmpj7taUFd4E7UB3vUdj9PrjdxCiQ/IRhh1EAV48
8HYJu9ymAkUiDAQgKcAIFGI5XhYxFAQsyKIEIE8xlCSQDECI42nIYVHgeJHHECFo
oS2IlziKYzls4VgAEKEnZMVuxc4ip2J3q7QyI1sgkAGkSQAonqEYLFsogHjMUCzH
CrRMQggpoBbaHK5ghSpORC68RnGoMfViWpR3H/w93YCUWYZXd0ySiIYIiBwnQECx
EkIyQJCmafU9IIikBXMSzQKWQWoDmBN4DgocY+EXdXsW6WhWxogCtCBCSWRkSWJJ
lmdkAYhQADIpBIEu7LSjQqyirR6r2quDKNUTarBYseCgr3eTTixJivu+BabtitXm
tqtOBUvdvqJgzotF010Wk6jYpWBWTxRjp0tx2AkDqSItbiVIQ6pDIimS51k9gd8o
UpzYpAQRLOR4oC49UeTExcFuOCRIkgRIqI4B0yKLWVkkAWYpwGFZ5EiWoUTASBQU
WSRLsizTSDWUETGmoQiDLrvw63YHYeA4VSeyqpwuxWpHbo8TE6XfdufrNNpITVjo
kuAH00RGRN/7dsSJaM1x1dP4PbO4MfaYZvma6T8jHuxLqp7x/7ey52Nf09fsBXO6
pvNq4tGOV9hq8ybiLfORHDZtS82V1squhdeGB9Nmnvys8susHOMFIq5uZ2RM3ajv
7JFf//m3I7Dh0ORTmYe7Yp4PyWwY1f2wsfDt8i532TNxFWnQ3xR7c8DWuv74yKWA
9Jzx0NS688k3p693dcXsziubejZq/Ma+4YPFX/24zSp/Gpj75Lq9Rh6cbBsei7g4
l+26EzeeUaNLSU3Xxdcva0/2tnttykvmjG/yp/JqN3u+uNUslEcsmOqr1j9eG1Mx
3Lr3UktnG16VdSDbYVxaX+3/eWIolSwjtlp1U6cPzmT3nQ599MDT5N8rc19IHDV/
NHYKbajdXxPenHm2Y114dkniq2Fe1HrG3T5EZ3a+YxzctPChv2Xi1P7f/T3gcG3+
UN1gbNxktNeR/IHyh7mQeOBKwudJvW0BV/zuvHdzNvNZV3tbU3eee1goTyru31ve
MlYePdgYyLUG5nzfR91++aS054Zn1xMNxE9lBRlhI9oKWL/lL1tjUkJqlWG2Los1
NF+eOTpcvatkX/7liRWl1d89dK3fsrq283Z4728vvlk032doOFY5mT5v1zJnZsOW
/nIu6tZFI6+9NtAfWvHIdKq4dvmSVfr+O2vfDzQ5dI/pkrcRnSW+kPn3Tp7vVlbb
Tow7W1JG5P8BRMLBZg==
=IZfi
-----END PGP MESSAGE-----
04df1bd78c4e218f7b2af4fcef7646e879eca3104854bf64eee613d2eec5bda4  lnd-darwin-amd64-v0.12.0-beta.tar.gz

(The content of the tar.gz is the text "malicious")

The correct way of handling it is to output the contents of the signed message block after verifying it, before parsing it, but that leaves me wondering why not provide them separate in the first place, when that is less likely to lead to mistakes?

Is there a reason why clearsigned manifests might be preferred over detached signatures?

[setpill]

Further discussion on the Arch bug tracker indicates that manifests are suboptimal for automated checks, as they involve either upstream-specific filtering of the manifest lines, or using insecure --ignore-missing, as well as needing checking that the file pointed at is not outside of the expected directory. I have now implemented the checking and filtering in the PKGBUILD for my AUR package, though this doesn't exactly make the PKGBUILD more transparent/easy to read, which is a desirable trait.

The solution with least pitfalls is to provide detached signatures for the individual binary archives themselves.

[cfromknecht]

@setpill after looking into this, moving away from a manifest would be a much bigger change, but we've modified the signature/verification flow to use detached signatures. we're planning to tag an 0.12.1-beta.rc4 so that we can test out the new setup, would be great to get your feedback and see if this helps out your use case!

[setpill]

Can confirm this works. I noticed that @Crypt-iQ has not linked their keybase and github accounts, so I've left checking of their signature out for now.