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

Bug #1556666 reported by Julian Andres Klode
This bug affects 38 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Colin Watson

Bug Description

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.

Tags: qa-ok

Related branches

Colin Watson (cjwatson)
Changed in launchpad:
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
status: New → In Progress
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

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:


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.

Revision history for this message
Anders Kaseorg (andersk) wrote :

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.)

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Colin Watson (cjwatson)
tags: added: qa-ok
removed: qa-needstesting
Revision history for this message
Jason Gerard DeRose (jderose) wrote :

@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.

Luca Tansini (tansini13)
affects: launchpad → ubuntu
Revision history for this message
Julian Andres Klode (juliank) wrote :

Don't mess around with the bug assignment please.

affects: ubuntu → launchpad
Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Revision history for this message
Greg (greg532) wrote :

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

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 1556666] Re: PPA (In)Release files use SHA1 digests for GPG signature

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.

Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Revision history for this message
Doug McMahon (mc3man) wrote :

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

Revision history for this message
juliwoodbcn (julianlozano) wrote :

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?


Revision history for this message
Colin Watson (cjwatson) wrote :

@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.

Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Changed in launchpad:
status: Fix Committed → Fix Released
Revision history for this message
cement_head (andorjkiss) wrote :

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

Revision history for this message
Anders Kaseorg (andersk) wrote :

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.


To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.