New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian package repository key changed to 4F77679369475BAA #6916

Closed
sth opened this Issue Jan 12, 2019 · 12 comments

Comments

Projects
None yet
6 participants
@sth
Copy link
Contributor

sth commented Jan 12, 2019

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.

@heupr heupr bot assigned Daniel15 Jan 12, 2019

@heupr heupr bot added the triaged label Jan 12, 2019

@cwitteveen

This comment has been minimized.

Copy link

cwitteveen commented Jan 12, 2019

@Daniel15

This comment has been minimized.

Copy link
Member

Daniel15 commented Jan 14, 2019

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

This comment has been minimized.

Copy link
Member

Daniel15 commented Jan 14, 2019

Bug filed upstream: aptly-dev/aptly#805

@ianrandmckenzie

This comment has been minimized.

Copy link

ianrandmckenzie commented Jan 15, 2019

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?

@patros

This comment has been minimized.

Copy link

patros commented Jan 15, 2019

@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

This comment has been minimized.

Copy link

jonathanmeier5 commented Jan 15, 2019

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

@Daniel15

This comment has been minimized.

Copy link
Member

Daniel15 commented Jan 15, 2019

@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

This comment has been minimized.

Copy link

jonathanmeier5 commented Jan 15, 2019

@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

This comment has been minimized.

Copy link
Member

Daniel15 commented Jan 15, 2019

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

@jonathanmeier5

This comment has been minimized.

Copy link

jonathanmeier5 commented Jan 15, 2019

No problem, thanks for the updates 👍

@sth

This comment has been minimized.

Copy link
Contributor Author

sth commented Jan 16, 2019

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

This comment has been minimized.

Copy link
Member

Daniel15 commented Jan 20, 2019

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

@Daniel15 Daniel15 closed this Jan 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment