Wednesday, 23 November 2016

Re: Rejecting SHA1-signed repositories by default (Ubuntu edition)

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:

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.