Dropping SHA-1 support in APT

Tomorrow is the anniversary of Caesar’s assassination APT will see a new release, turning of support for SHA-1 checksums in Debian unstable and in Ubuntu xenial, the upcoming LTS release.  While I have no knowledge of an imminent attack on our use of SHA1, Xenial (Ubuntu 16.04 LTS) will be supported for 5 years, and the landscape may change a lot in the next 5 years. As disabling the SHA1 support requires a bit of patching in our test suite, it’s best to do that now rather than later when we’re forced to do it.

This will mean that starting tomorrow, some third party repositories may stop working, such as the one for the web browser I am writing this with. Debian Derivatives should be mostly safe for that change, if they are registered in the Consensus, as that has checks for that. This is a bit unfortunate, but we have no real choice: Technical restrictions prevent us from just showing a warning in a sensible way.

There is one caveat, however: GPG signatures may still use SHA1. While I have prepared the needed code to reject SHA1-based signatures in APT, a lot of third party repositories still ship Release files signed with signatures using SHA-1 as the digest algorithms. Some repositories even still use 1024-bit DSA keys.

I plan to enforce SHA2 for GPG signatures some time after the release of xenial, and definitely for Ubuntu 16.10, so around June-August (possibly during DebConf). For xenial, I plan to have a SRU (stable release update) in January to do the same (it’s just adding one member to an array). This should give 3rd party providers a reasonable time frame to migrate to a new digest algorithm for their GPG config and possibly a new repository key.


  • Tomorrow: Disabling SHA1 support for Release, Packages, Sources files
  • June/July/August: Disabling SHA1 support for GPG signatures (InRelease/Release.gpg) in development releases
  • January 2017: Disabling SHA1 support for GPG signatures in Ubuntu 16.04 LTS via a stable-release-update.

15 thoughts on “Dropping SHA-1 support in APT

  1. It would make more sense to create a second tier of hashes, and move all deprecated hashes to this second tier. Hashes on this second tier are checked, and must match, but are not *sufficient* to consider the repository valid. BTW, size information also needs to be treated like this (it already is, AFAIK).

    And it probably pays off to _not_ make the second-tier hashes optional, either, so they must be present and match. Together with size information, using multiple hashes (from different families) where all must match will be an effective last line of defense against a broken primary hash. The more the better, as long as the cost to calculate and store such hashes does not become prohibitive.

  2. They are indeed still checked. But that takes longer to explain, and dropped is what people need to know.

    Others have argued that we stop checking multiple hashes, but doing so makes things easier for us.

    You can drop untrusted hashes though. I’m not sure it makes sense to force people to keep them.

    1. I’m also unsure what the real benefit is here. Of course it makes total sense to fix the single SHA1 hash in the GPG signature. But we already have two hashes in the Packages files, which is safer than SHA1 alone. So I think there is even more nuance here where a single set of SHA1 or MD5 should be untrusted but the combination is safer. But then how to effect change… (The threat might already have been enough, though.)

      1. Both MD5 and SHA1 are structurally similar, both are somewhat derived from MD4.

        We will very likely have SHA-3 checksum support in stretch as well on the client side, and on the archive side in buster. Then we have two mostly independent algorithms which we can check and we’ll be much more future proof.

        I have to look at packaging the Keccak reference implementation first, though. It’s a bit ugly: They have a Makefile in XML, which is translated with xsltproc to a real makefile… – but if I get it packaged, we’d at least have a static libkeccak we can hopefully link into APT.

  3. Well, if someone can remove hashes from the signed release file, they could also change them, so I have to agree that it is not a problem have old (weak/broken) hashes as optional, as long as they are always validated when present.

    However it is not advisable to trust people to understand any sort of crypto nuances. As it is, we will actually have most people replacing sha1 with sha2 and removing md5, instead of adding sha2 and keeping the two others, due to a misguided notion that this is *safer*. There is a price to be paid by trying to simplify the message too much.

    Case in point: use of TLS on “.deb” archive mirrors: the security theater mindset being absorbed by the masses is “http bad, https good”. Which would only be true if we had perfect TLS implementations, something that is so far from the truth, it is not even remotely funny.

    We see more and more mirrors activating TLS support, which brings in a large, known dangerous attack surface to those mirrors that did not have TLS enabled before. And users needlessly enabling https on sources.list thinking it makes them “safer” (against *what*?), when it is in fact exposing them to remote attacks through the TLS layer.

    Soon, people will start pushing for the use of https on Ubuntu’s and Debian’s default source.list…

    (the above TLS threat analysis does not hold true for modern browsers, which have a TLS layer that is active almost all the time and have to accept https upgrade redirects, so they’re already always exposed).

    1. The argument for TLS is that you want to hide which packages you install. That is, it’s only used for confidentiality. This does not really work, though: If you install a update that is 5MB a day after a 5 MB update was released, people will still know what you installed.

      There’s no huge security issue though: The fetcher process runs as a very restricted user that only has access to the partial/ directory of APT. The files will still be verified in the main process before being used.

  4. Thank you very much for pushing this and providing no workaround. This does absolutely not fuck over your users.

  5. Great, seems there is no way to bypass this for our local, internal repo. Definitely not fucking over your users.

    1. Thank you for your kind words. Anyway, it’s much better than it could be. Once gpg revokes it’s trust for SHA1, you won’t have absolutely no SHA1 anymore, anywhere. And GPG also provides no way to mark an algorithm as trusted again, BTW.

Comments are closed.