PPA (In)Release files use SHA1 digests for GPG signature

[Julian Andres Klode]

We are currently removing support for SHA1 in APT, which I think is reasonably with xenial being supported until 2021. In the process, I noticed that the InRelease files generated by launchpad uses SHA1 digests for the GPG signature. Please change that to SHA512 or SHA256 soon.

We might not start considering SHA1 as weak for the purpose of the GPG signatures yet, because that might break the hole world (various 3rd parties seem affected), but if we don't now, we might start doing that in a stable release update.

[Jason Gerard DeRose (jderose)]

If possible, I strongly recommend using SHA-384, although I'm not sure if there are any potential compatibility challenges in doing so.

Like SHA-512, SHA-384 uses the same 512-bit internal state size, but because SHA-384 only exposes 384 bits of of this internal state in the digest, it's immune to length extension attacks:

https://en.wikipedia.org/wiki/Length_extension_attack

From page 87 of *Cryptography Engineering* by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno:

"""
There is another fix to some of these weaknesses with the SHA-2 family of iterative hash functions: Truncate the output. If a hash function produces n-bit outputs, only use the first n - s bit as the hash value for some positive s. In fact, SHA-224 and SHA-384 both already do this; SHA-224 is roughly SHA-256 with 32 output bits dropped, and SHA-384 is roughly SHA-512 with 128 output bits dropped.
"""

They ultimately recommend using SHA-512 truncated to 256 bits (if you're going to use a SHA-2 hash), but that's not feasible in this case as GPG doesn't support truncated SHA-512.

In terms of standard SHA-2 family hash functions supported by GPG, SHA-384 is the best option in my opinion.

Note that I don't recommend SHA-224 as its 256-bit internal state size is too small by modern standards. SHA-384/SHA-512 are also considerably faster than SHA-224/SHA-256 when it comes to 64-bit software implementations.

[Anders Kaseorg (andersk)]

Length extension attacks are not relevant to apt. (For example, no part of the hashed data is secret, and the hash is not used as a MAC.)

[Launchpad QA Bot (lpqabot)]

Fixed in stable r17952 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17952>.

[Jason Gerard DeRose (jderose)]

@Anders - ah, yeah, you're right. I've been so in the habit of always using SHA-384 as my go-to SHA2 hash that it's been a while since I've thought through when message length extension attacks matter.

I agree that in this scenario, there shouldn't be any particular advantage when it comes to SHA-512 vs. SHA-384.

[Julian Andres Klode (juliank)]

Don't mess around with the bug assignment please.

[Colin Watson (cjwatson)]

Launchpad will now sign PPAs using a SHA-512 digest in the event that it needs to publish something in them anyway. We're still working on the code to re-sign all existing PPAs (the scale means that it isn't trivial), but we should be done with that soon.

[Greg (greg532)]

Any update on this? Unfortunately, it breaks my build.

[Colin Watson (cjwatson)]

On Thu, Mar 24, 2016 at 09:51:34AM -0000, Greg wrote:
> Any update on this? Unfortunately, it breaks my build.

Odd that it should break your build; it's a warning, not an error. This
might indicate a problem with your build system.

Anyway, I've finished the code to let us re-sign existing PPAs, and I'm
going to try to get it landed and deployed today. If possible I'll try
to get xenial PPAs re-signed today, but I'm racing against the Easter
holidays and so it's possible that we won't make it in time. In that
case I'll sort it out on Tuesday.

[Colin Watson (cjwatson)]

Easter status: didn't entirely make it before the holidays, but the necessary code is deployed and a ticket is in our sysadmins' hands with full instructions on re-signing all xenial PPAs.

[Doug McMahon (mc3man)]

Seems to have been fixed here in regards to ppa's

[juliwoodbcn (julianlozano)]

I'm still seen issues on :

http://ppa.launchpad.net/nginx/stable/ubuntu/dists/xenial/InRelease: Signature by key 8B3981E7A6852F782CC4951600A6F0A3C300EE8C uses weak digest algorithm (SHA1)

there is any place where to check the work status?

Regards

[Colin Watson (cjwatson)]

@mc3man: No, it's only fixed for those PPAs that have had any xenial publications in the last week or so.

@julianlozano: This bug is that place. See comment #10 for the current status. Please rest assured that I will update this bug when anything changes; until then I would appreciate it if people could refrain from asking for status.

[Colin Watson (cjwatson)]

All xenial PPA Release files have now been re-signed with SHA-512 digests.

Depending on how recently they were changed, Release files for older Ubuntu series in PPAs may still be signed with SHA-1 digests, which may be noticeable for a small number of users who have pre-xenial PPAs enabled on xenial systems (myself included). We do plan to re-sign these as well; it involves some downtime for the PPA publication system, particularly for trusty, so we won't do it straight away, but it'll happen gradually over the coming weeks. I don't think there's further need to track it here, though.

[cement_head (andorjkiss)]

What's the status of non-Xenial (non-Cannonical) PPAs in terms of fixing/updating to the SHA2 protocol?

Do each of these packages need to be notified individually?

Here is a list of PPAs that I've found to be with issue:

Google Chrome
Google Earth
Google Talk
Mendeley

[Anders Kaseorg (andersk)]

There is no such thing as a non-Canonical PPA. Those are just external Apt repositories. Their individual maintainers need to be notified, but for all the ones you’ve listed, they already have.

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