Debian package repository key changed to 4F77679369475BAA

[sth]

Just recently the key used to sign Debian packages was changed to a new key with id 23E7166788B63E1E. Now that key seems to have changed again:

W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 4F77679369475BAA

That new key seems to have been created on 2019-01-11 after the previous change on 2019-01-02.
Is this change intentional?

Are key changes announced somewhere? The signatures are completely pointless if I'm supposed to just redownload a new key whenever there is a signature error. If someone manages to upload a changed package to https://dl.yarnpkg.com/debian they most likely can also upload a new key to that location.

[cwitteveen]

@sth #6903 (comment)

[Daniel15]

Sorry about that! This was totally unexpected. On 11th January, I added a new subkey (4F77679369475BAA) for the nightly repo, as a response to this comment: #6865 (comment)

Still have the warning with nightly repo

The reason the stable and nightly repos use separate keys is so the build environments can be isolated, and the nightly key being compromised won't affect the stable key. The environment used to sign the nightly repo only contains the nightly subkey, not the stable subkey, and the nightly one can be revoked separately.

This key was only supposed to be used for the nightly repo. However, there appears to be a bug with Aptly. We're explicitly signing the stable repo with 23E7166788B63E1E: https://github.com/yarnpkg/releases/blob/gh-pages/debian-source/add-deb.sh#L26-L27

aptly -config=./.aptly.conf publish update -gpg-key=23E7166788B63E1E stable
aptly -config=./.aptly.conf publish update -gpg-key=23E7166788B63E1E rc

However, it appears to be ignoring this and using the wrong subkey (4F77679369475BAA). I want to investigate whether this happens in an isolated test case (new GPG key with two subkeys, and two new Aptly repos) and report it upstream if so.

If we can't determine the bug or fix Aptly, next rotation I'll just switch to using an entirely separate key for the nightly repo, rather than just a separate subkey.

Also, apologies for the delay in replying... I was on vacation.

[Daniel15]

Bug filed upstream: aptly-dev/aptly#805

[ianrandmckenzie]

Hi there. Dev ops newbie here. I can't seem to apt update until the key can be properly read. Is there a workaround until a fix is in place?

There is someone in this issue thread:
ansible/ansible#30754

that is saying sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 4F77679369475BAA will fix the problem, but I don't want to try it until I understand it. Would anyone be willing to explain this to me?

[coderpatros]

@ianrandmckenzie that will add that key as a trusted package key. Pretty low risk in this scenario. But you could always remove it after the issue is resolved.

[jonathanmeier5]

Is there any timeline as to when this will be fixed, or will it depend on the aptly bugfix?

[Daniel15]

@jonathanmeier5 - Nothing should be broken at the moment. The only issue is that the stable repo is being signed with the nightly repo's key, however both public keys are included in the public key published at https://dl.yarnpkg.com/debian/pubkey.gpg so it shouldn't be an issue.

[jonathanmeier5]

@Daniel15 I guess to rephrase my question: do you have any idea when you will return to signing the stable yarn release with only the most recent stable sub-key? Ideally, we would prefer to not accept signatures from the nightly sub-key in our builds long term.

[Daniel15]

Yeah, it mainly depends on the aptly bug. Unfortunately I don't really have time to look into it myself right now :(

[jonathanmeier5]

No problem, thanks for the updates 👍

[sth]

I looked into it and it turns out aptly passes through all options correctly. The real problem is GPG which does its best to be hard to use.

You can tell it which key to use ("The signing key is chosen by default or can be set explicitly using the --local-user and --default-key options.") but GPG will only use that key id to find the associated primary key and then will use that key's newest subkey to sign. In this case not the one intended.

If you want it to actually use the key you tell it to use, you have to append an exclamation mark to the key id...

[Daniel15]

Thank you so much @sth! I've just re-signed the repo using the proper subkey, thanks to your advice.