Clarifications and updates on APT + SHA1

The APT 1.2.7 release is out now.

Despite of what I wrote earlier, we now print warnings for Release files signed with signatures using SHA1 as the digest algorithm. This involved extending the protocol APT uses to communicate with the methods a bit, by adding a new 104 Warning message type.

W: gpgv:/var/lib/apt/lists/apt.example.com_debian_dists_sid_InRelease: The repository is insufficiently signed by key
1234567890ABCDEF0123456789ABCDEF01234567 (weak digest)

Also note that SHA1 support is not dropped, we merely do not consider it trustworthy. This means that it feels like SHA1 support is dropped, because sources without SHA2 won’t work; but the SHA1 signatures will still be used in addition to the SHA2 ones, so there’s no point removing them (same for MD5Sum fields).

We also fixed some small bugs!

13 thoughts on “Clarifications and updates on APT + SHA1

  1. It’s a warning indeed, but the warning itself is confusing. When I try to install a package now, I get this: “WARNING: The following packages cannot be authenticated!
    libowncloudsync0 owncloud-client-l10n owncloud-client
    Install these packages without verification? [y/N]”

    Now I can understand since SHA1 is deprecated, there’s no way to give a 100% verification. However, I would not go as far as to say packages with SHA1 verification are at the same level as packages with no verification at all.
    Therefore, IMHO, the warning should say something like:
    “WARNING: The following packages cannot be fully authenticated since they use a deprecated signing method.
    [package names]
    Install these packages without full verification? [y/N]”

  2. Is there a reason for this breaking change not being introduced gradually? i.e. first only issue warnings, but don’t break repos with only SHA-1, then after some time has passed and most important repos have started shipping SHA-2 hashes, then turn warnings into errors.

    Currently trying to build new machines with repos that only carry SHA-1 is impossible:

    Reading package lists…
    W: http://…/Release.gpg: Signature by key … uses weak digest algorithm (SHA1)
    E: Failed to fetch http://…/Release No Hash entry in Release file /var/lib/apt/lists/partial/…%5f64_Release, which is considered strong enough for security purposes
    E: Some index files failed to download. They have been ignored, or old ones used instead.

    Then apt exits with code 100 and breaks automated scripts. But even if it didn’t – the new index files are rejected and packages cannot be installed. As far as I can tell there is no workaround except badgering my upstream provider until they start shipping SHA-2 hashes.

    So in one move you changed the system from “everything is fine, no warnings, everything gets installed” to “lots of warning, errors, nothing installs”. Way to go.

    1. We are introducing the change as gradually as reasonably possible. There are two kinds of breakages: Weak GPG signature and missing hash entry in an Release file.

      In the first case, we only display a warning (W: ). This affects the majority of all repositories.

      In the second case, we display an error (E: ) as the logic is deep in the acquire subsystem and I would not like reworking security-related code like this (we might introduce a loop hole doing this). So I just added SHA1 to the existing blacklist (MD5 and Filesize were listed as untrusted hashes in 1.1).

      This second class affects only a very small minority of repositories (non-Chrome Google repositories, SpiderOak ONE, and the Nvidia CUDA one).

      The Google ones are unmaintained (talkplugin, earth), or not well-maintained (musicmanager).

      The Nvidia CUDA one is broken far worse, because it only has MD5, which does not work since 1.1~exp12 which was released in September 2015. They clearly had sufficient time to update their completely broken mess of repository support (as a bonus, you can also perform two MITM attacks when adding their repository).

      1. I don’t believe 6 months is a sufficient time for a large company like Nvidia, given that Linux driver support is a very minor (and often neglected) part of their operation. Especially given that there was no Steam OS or Ubuntu released with APT 1.1 (was there a Debian release? I’m not following Debian closely).

      2. I appreciate the reply (though I don’t appreciate the attitude), but I don’t think you appreciate the scope of the change you are pushing.

        Anyway, from talking to Nvidia representatives, it appears they have no intention of supporting Ubuntu 16.04 when it will come out (which I read as “we will not fix our repo”) but they will try to get it working for the next CUDA release which I was promised is “some months away”. So currently it looks like no CUDA for Ubuntu 16.04. And yes – that is probably not a large number of people.

        More to the point, I’m not sure why you exclude the Google Chrome repositories from the list of “broken” repos. I still get this error when I do `apt-get update`:

        W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1)

        (yes, its an error event if it says “W” because the result of it shown is an error message, apt-get exiting with an error code and the repo not updated).

        And Google Chrome users is *not* an insignificant number of users.

      3. No, the message is precisely not an error. It’s a warning. If APT exits with an error code, you must have some other repository that produces an error (check with 1.2.8 or 1.2.9, those make it clearer).

        The error case for SHA1 is in the process of being downgraded to a warning in

        https://github.com/julian-klode/apt/compare/feature/configurable-hash-trust…bugfix/sha1-deprecated

        But I’ll definitely not do that for MD5, so CUDA will still be broken, as MD5 is just far too insecure.

        So, we will have a saner deprecation period than I initially expected, giving everyone a huge amount of time to upgrade their repositories until we pull the plug in January.

      4. Regarding the repos – yes, there were some other Google repositories that errored, and I didn’t notice that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s