lnd: GPG key used to sign releases & tags have expired

FWIW: I was able to meet @Roasbeef at LNConf and verify his key as:

9769 140D 255C 759B 1EB7  7B46 A963 87A5 7CAA E94D

I have signed this key and uploaded to keyservers: http://keys2.kfwebs.net/pks/lookup?op=vindex&search=0xA96387A57CAAE94D&fingerprint=on

Unfortunately he is not interested in signing other keys, so this key will remain outside of the PGP Web Of Trust.

My new key: https://keys.openpgp.org/vks/v1/by-fingerprint/BD599672C804AF2770869A048B80CD2BB8BD8132

That is your old key 😉 Here is the new one it seems: 9769 140D 255C 759B 1EB7  7B46 A963 87A5 7CAA E94D

It’s just my form of key hygiene.

Unfortunately, letting a key expire means that all the sigs also expire – anyone who by luck managed to verify the key in person with you (like I did a couple years ago) is back to zero. This makes it difficult to determine if a key is yours or that of an imposter (however unlikely that may be).

Please consider cross-signing new and old keys to establish some link we can rely on.

Thanks.

They can all still be verified (there’re even other older releases with prior expired keys as well). What happens is that you receive a warning that the key is expired, just as you would if the key has no trust level from your PoV.

@Roasbeef the issue is with automated checks, which treat this warning as an error, and fail.

@Roasbeef, Whether you extend the expiration or rotate your key, setting a one year expiration still acts as a soft dead mans switch. In both cases you need to take action.

If you only want to take advantage of the latest algorithms, perhaps you could rotate your Sign subkey instead of creating an entirely new primary secret.

Please reopen; current release’s manifest signature cannot be verified without ugly libfaketime hacks, which is not viable for packaging.

FWIW gpg2 at least does not error on signatures from expired keys, simply outputs a warning. I was running into some packaging trouble earlier and misattributed it to the key expiration; what actually happened was that I whitelisted F8037E70C12C7A263C032508CE58F7F8E20FD9A2 when I should have whitelisted BD599672C804AF2770869A048B80CD2BB8BD8132.

However, this is just about the AUR packaging of the prebuilt binaries; the AUR package that builds from source can only verify using git verify-tag [tagname] (the Makefile assumes a git environment, so building from the source tarball is not trivial; or if it is, I didn’t find it in the documentation), which does error because of key expiration.

I cannot comment on any other packaging systems, but it is not strange to assume they might also run into trouble.

Given that, it seems like circumventing the official signature, and relying on multiple people building a release, and signing its hash might be the most sustainable way forward. Not quite clear on details yet.

Yep, we have plans to go in this direction, but baby steps first.

Since Go 1.13, and with minor tweaks, reproducible builds are possible.

Given that, it seems like circumventing the official signature, and relying on multiple people building a release, and signing its hash might be the most sustainable way forward. Not quite clear on details yet.

I’ve spoken with @guggero briefly on the conference, and it seems he was quite happy to have reproducible builds introed into the lnd repo 👌🏻.

A temporary hack around verify-tag that I’ve found is:

git verify-tag "${TAG}" || \
    { git verify-tag --raw "${TAG}" 2>&1 | grep EXPKEYSIG && echo "Accepting expired key!"; }

Although, I have no idea how safe the above is…

A key can be extended at any point, even after expiration.

My question is: What is the point of generating a new key, as opposed to extending the validity of the existing one?

It causes needless verification fails of all previous signatures (non trivial to handle), forces everyone to download, and verify new key periodically (error prone - any key update error might leave people vulnerable).

It’s just my form of key hygiene. This is also something that’s bound to happen unless a key has an unlimited life time, which IMO is undesirable.