Rejecting SHA1-signed repositories by default (Ubuntu edition)

Seth Arnold seth.arnold at canonical.com
Thu Nov 24 00:46:57 UTC 2016


On Thu, Nov 24, 2016 at 01:19:12AM +0100, Julian Andres Klode wrote:
> as previously (sort of) announced I want to turn off SHA1 on January 1st
> by default in apt (in the 1.2 and 1.3 series xenial/yakkety ship). We
> already turned this off for fields inside the (meta) index files,
> this step now involves rejecting SHA1-based GPG signatures as well.

> The idea is that SHA1 gets rejected by default, but the
> error may be lowered to a warning instead. I do not intent

Hello Julian, thanks for working on this.

Currently retrieving 12.04 LTS package listings using 16.04 LTS's apt
packaging results in warnings like the following:

W: http://mirrors.kernel.org/ubuntu/dists/precise-updates/InRelease:
Signature by key 630239CC130E1A7FD81A27B140976EAF437D05B5 uses weak digest
algorithm (SHA1)

It'd be nice if the 'fail' could be configered per-release or per-deb
lines or something similar, so that I could still retrieve information
about older releases but newer releases get the enforced better security.

(Since 12.04 LTS EOLs in ~six months maybe this isn't worth addressing.
But I wanted to mention it all the same.)

May I also ask for the Valid-Until: lines to be turned on for zesty and
newer releases at the same time? I've heard various reasons why we don't
use it:

- An attacker could simply supply valid lists from before we started
  enforcing valid-until

- An attacker could simply block access to the update servers entirely.

I think these aren't in themselves good enough reasons to not use
Valid-until headers:

- If we had made this change back in, say, 10.04 LTS, we could have been
  publishing signed-and-dated files for six years by now. Today's
  users would be protected if we had done this then. Even if we have to
  grandfather these files in gradually, the sooner we start the sooner
  we will see benefit.

- A user may not think much of "I couldn't contact the update server
  today" whenever they happen to notice it. But if apt reports "the
  last valid update information is from N months ago" they may start to
  investigate why they do not get updates:

  - Perhaps their release is no longer supported
  - Perhaps some configuration mistake prevents it accidentally
  - Perhaps an attacker prevents it intentionally

Please consider making these changes at the same time.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20161123/4caa4e10/attachment.pgp>


More information about the ubuntu-devel mailing list