Rejecting SHA1-signed repositories by default (Ubuntu edition)

[Marc Deslauriers]

Hi,

On 2016-11-23 07:46 PM, Seth Arnold wrote:
> 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.
> 

There is also: An attacker could simply supply the Trusty file that includes a
Valid-Until line to Xenial users.


> 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

Marc.