Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Debian package repository key changed to 4F77679369475BAA #6916
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:
That new key seems to have been created on 2019-01-11 after the previous change on 2019-01-02.
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.
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)
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
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.
This was referenced
Jan 14, 2019
Hi there. Dev ops newbie here. I can't seem to
There is someone in this issue thread:
that is saying
@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.
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
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...