Signature of deb repo is weak

[rpadovani]

Since the release of APT 1.2.7 keys which use SHA1 are considered weak and give a warning on apt update.

https://juliank.wordpress.com/2016/03/15/clarifications-and-updates-on-apt-sha1/

W: http://www.rabbitmq.com/debian/dists/testing/InRelease: Signature by key F78372A06FF50C80464FC1B4F7B8CEA6056E8E56 uses weak digest algorithm (SHA1)

[michaelklishin]

Changing a signing key is a very big deal. Since this is a warning, I don't think it's worth the change for now.

On 31 mar 2016, at 10:09, Riccardo Padovani notifications@github.com wrote:

Since the release of APT 1.2.7 keys which use SHA1 are considered weak and give a warning on apt update.

https://juliank.wordpress.com/2016/03/15/clarifications-and-updates-on-apt-sha1/

W: http://www.rabbitmq.com/debian/dists/testing/InRelease: Signature by key F78372A06FF50C80464FC1B4F7B8CEA6056E8E56 uses weak digest algorithm (SHA1)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[noahhaon]

I think you misunderstand, the message digest is weak, you can keep your key you just need to sign using SHA2.

[noahhaon]

Also the latest LTS version of Ubuntu will not install packages signed with SHA1 keys.

[noahhaon]

If you can tell me what build tools you use to sign your debs, I would be happy to investigate this further.

[michaelklishin]

@noahhaon thank you, I believe we use gpg. @dumbbell has more info on the release toolchain.

[shernshiou]

+1

[gmta]

As @noahhaon stated, Ubuntu 16.04 LTS users will be unable to install packages. AFAIK there is no workaround, apart from downloading and installing the package and all its dependencies by hand.

[noahhaon]

Hi, sorry I didn't get an earlier notification on this. I have some ideas and will do some digging today.

[noahhaon]

@michaelklishin Unfortunately I think this change is most easily handled in your build environment. You would need to add the following to the the .gnupg/gpg.conf file in the build user's homedir:

digest-algo sha256

Disappointingly, reprepro appears to have no options to passing arguments to gpg as it uses an embedded version, libgpgme. However, you can set the environment variable GNUPGHOME to point to the location of the directory housing gpg.conf, and drop the modified config file via make or similar. Not ideal, but at least something you could get into git.

Relevant bits for build the deb repo appear to live here:

https://github.com/rabbitmq/rabbitmq-server/tree/master/packaging/debs/apt-repository

c.f.

https://manpages.debian.org/cgi-bin/man.cgi?query=reprepro&apropos=0&sektion=0&format=html&locale=en

[michaelklishin]

@noahhaon that's something Puppet can do. @dumbbell can you please share your findings?

We are certainly willing to explore options that let us avoid generating a new key.

[noahhaon]

@michaelklishin from what I understand of the issue, there should be no reason for you to generate a new key.

Once you get the fix in, you should be able to verify the signature digest algorithm that reprepro used:

wget http://www.rabbitmq.com/debian/dists/kitten/Release
wget http://www.rabbitmq.com/debian/dists/kitten/Release.gpg
gpg -v Release.gpg

[michaelklishin]

@noahhaon OK, thanks, we'll see if we can do something about this before 3.6.2 (expected next week).

[noahhaon]

BTW I don't see any release artifacts (debs, etc) mentioned in these repos:

http://www.rabbitmq.com/debian/dists/kitten/Release
http://www.rabbitmq.com/debian/dists/testing/Release

[dumbbell]

@noahhaon: To answer your last question, reprepro uses a "pool" of packages to share them among several distributions, instead of duplicating files. You can find it at http://www.rabbitmq.com/debian/pool/.

Now, about the signing digest algorithm, I confirm we use the default SHA1 and that Ubuntu 16.04's apt displays a warning. That said, it let me install RabbitMQ.

As you suggest, we can set digest-algo in our gpg.conf to change that algo. However, this is discouraged by the documentation and best practices. The appropriate parameter is personal-digest-preferences.

Unfortunately, our key is an old DSA-1024 key and personal-digest-preferences doesn't apply to that specific kind of key if I understand correctly (according to the FAQ: https://gnupg.org/faq/gnupg-faq.html#hash_widths_in_dsa). With DSA-1024, the preference is "SHA1 RIPEMD160".

So either we use the non-recommended digest-algo argument or we create a new key.

Because our current key is really old and weak, I would prefer to go with a new key, following today's best practices. We'll discuss that internally.

[dumbbell]

After some tests on Ubuntu Server 16.04, it looks like apt-get update displays a warning, but I can still install RabbitMQ without trouble.

We decided to go with a new stronger key and start the transition. Because we can sign the repository again whenever we want, the 3.6.2 release cycle will continue independently.

To create the new key, I used the following popular checklist:
https://help.riseup.net/en/security/message-security/openpgp/best-practices

The new one has a RSA-4096 primary key to certify other keys, and two RSA-4096 subkeys; one to encrypt, one to sign. I tested it with a plain text file and our Debian repository and GnuPG picks SHA-512 as the digest algo without forcing it with digest-algo.

With the freshly installed Ubuntu mentionned above and this newly signed repository, apt-get udpate is obviously unhappy because I didn't import the new public key:

...
Hit:4 http://security.ubuntu.com/ubuntu xenial-security InRelease                                                     
Hit:5 http://fr.archive.ubuntu.com/ubuntu xenial-backports InRelease                                                  
Err:3 http://.../debian testing InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB64493E850B026F
...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://.../debian testing InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB64493E850B026F
W: Failed to fetch http://.../debian/dists/testing/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EB64493E850B026F
W: Some index files failed to download. They have been ignored, or old ones used instead.

With the new key imported, apt-get update is happy.

About the transition, we will follow the process described in the link mentionned above:

• Create a new key for releases
• Create a new key for nightlies
• Sign the new keys with the old keys
• Publish a "transition statement" for the Release key, signed with both relevant keys
• Publish a "transition statement" for the Nightlies key, signed with both relevant keys
• Announce the new keys with the transition statements on our website, the mailing-list and Twitter
• Start to use the new keys for our Debian repository
• Start to use the new key to sign the next release artifacts
• Start to use the new key to sign the next nightly artifacts

Update: The roadmap above was updated to take into account the transition of the Nightlies key which suffers the same weakness.

Update: We decided to use a single key with two signing subkeys for the release and nightly artifacts. That way, end user will only have to import one key, no matter whichi branch they want to use.

Update: Thanks to RPM poor support for PGP keys, we are back to two simple RSA-4096 keys; we can't use subkeys.

[noahhaon]

@dumbbell I was unaware that the signing key was DSA, which would require a key migration :( Your proposed course of action for the transition looks perfect - thanks for your work on this!

Some more background from the Debian folks here:

https://wiki.debian.org/Teams/Apt/Sha1Removal

Fixing half-broken repositories

The repository owner needs to pass --digest-algo SHA512 or --digest-algo SHA256 (or another SHA2 algorithm) to gpg when signing the file. Repositories with DSA keys need to be migrated to RSA first.

[dumbbell]

Thanks! That confirms my findings. And even if we could continue to use the old DSA-1024 key, it's a perfect opportunity to transition to something more current :-) I did that for my own key two years ago and it went more easily than I thought.

[noahhaon]

Sometimes it's better to just rip off the band-aid :)

Looks like Debian is not going to enforce the SHA1 deprecation until Jan 1, 2017 , and apparently Ubuntu 16.04 is throwing a warning so you have a bit of time.

Thanks again!

[dumbbell]

We need to transition the key for the nightly builds too! I'm updating the roadmap above.

[dumbbell]

So RPM support for PGP key and signature is ten years old and quite poor. In particular, we can't use subkeys. Thus, we are back to two simple keys...

[michaelklishin]

New keys are now in place, I've also restored http://www.rabbitmq.com/rabbitmq-signing-key-public.asc temporarily because apparently enough people depend on the sole existence of the file.

[michaelklishin]

Announcement of the new keys.

[dumbbell]

The Debian repository is now signed with the new release key; it was made available a few minutes ago.

apt(1) from Ubuntu 16.04 is now happy!

[gsker]

Why is this closed if the InRelease file digest hash is still SHA1?
I still get the warning after all these months.

    wget -O - http://www.rabbitmq.com/debian/dists/testing/InRelease |& grep Hash
    Hash: SHA1
And the output from apt update:
    W: http://www.rabbitmq.com/debian/dists/testing/InRelease: Signature by key
        0A9AF2115F4687BD29803A206B73A36E6026DFCA uses weak digest algorithm (SHA1)

This was never about the Signing key. It was about that Warning.

[michaelklishin]

@gsker I'm no Debian expert but this was about a whole bunch of things that had to be changed at once. FWIW this happened over 4 months ago and except for those who haven't imported the new key, we didn't have any apt warning reports since then. There are Package Cloud and Bintray Debian repositories available in case that's not good enough for you.

Please post your observations to rabbitmq-users since we don't reopen issues that were closed and part of a release.

[dumbbell]

This was never about the Signing key. It was about that Warning.

@gsker: This was both a problem with the signing key and the signature. The previous key was a DSA/1024 key which didn't permit to use a SHA-512 digest. Thus we had to replace it first with something more current.

The warning re-appeared recently because of a regression in our build process. The digest preference was not honored and GnuPG used SHA-1. We restored the configuration to select SHA-512 explicitely and the repository is signed again. The regression should be solved now.