New Linux Repository Signing Keys for Jenkins 2.543 and 2.541.1

Using Jenkins
, ,
1

Beginning December 23, 2025, the Jenkins weekly releases will use new repository signing keys for the Linux installation packages. The same change will be made in Jenkins LTS releases beginning January 21, 2026.

Technical details are described in [pkg.jenkins.io/release.ci.jenkins.io] Jenkins Packaging GPG key expires on the 26 March 2026 · Issue #4922 · jenkins-infra/helpdesk · GitHub.

Instructions will be included in the changelog for the release and in a blog post. Conversations about the change can be posted as replies to this topic.

The new GPG key has the following identity:

pub   rsa4096 2025-12-22 [SC] [expires: 2028-12-21]
      5E386EADB55F01504CAE8BCF7198F4B714ABFC68
uid                      Jenkins Project
2

I would like to point out, that the given command example for debian/ubuntu adds the weekly release repository. So anyone on LTS could find themselves ending up on using 2.547 instead of 2.541.1.

3

Thanks for noting that. We removed the LTS section from the blog post while we were waiting for the release of 2.541.1. Now that 2.541.1 is released, I’ve submitted a pull request to restore that section in the blog post. The pull request is:

1 Like
4

Having run the two commands indicated for the LTS release on Ubuntu 24.04 I see:

$ curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key | sudo tee   /usr/share/keyrings/jenkins-keyring.asc > /dev/null
$  echo deb \[signed-by=/usr/share/keyrings/jenkins-keyring.asc\]   https://pkg.jenkins.io/debian-stable binary/ | sudo tee   /etc/apt/sources.list.d/jenkins.list > /dev/null
$ sudo apt update
E: Conflicting values set for option Signed-By regarding source https://pkg.jenkins.io/debian-stable/ binary/: /usr/share/keyrings/jenkins-keyring.asc !=
E: The list of sources could not be read.
5

The message:

seems to be best addressed by the answer on Ask Ubuntu:

The guidance there is to remove the duplicate entries in your sources.list.d directory or sources.list file that mention the Jenkins repository.

6

Thanks for your help. That fixed the problem.

7

Two best practices here that don’t seem to have been followed:

Usually during a transition period (from the issuance of the new key till the expiration of the old one)

  • https://pkg.jenkins.io/debian-stable/binary/Release.gpg should be signed with both keys, so the new key works right away (and folks can update their verification), but nothing has yet broken you for anyone who is still using the old one.
  • You’d also usually upload a cross-signature (to keyservers at least) show that the old key endorses the validity of the new key.

This way you avoid any outage, and deliver the intended web-of-trust protection against an supply-chain attack. If you train folks to just blindly trust curl https://pkg.jenkins.io/debian/jenkins.io-2026.key, then anyone who has compromised that download server/mirror/CDN/etc has also compromised the public key they will use to verify the files they get from there, which defeats the point of having the code-signing in the first place.

Then, after the old key expires (or whatever “end of transition period” you want to advertise, you can stop signing Release.gpg with the old key, and folks who didn’t update to the new one one will stop working.

1 Like