On Wed, Nov 23, 2016 at 04:46:57PM -0800, Seth Arnold wrote:
> 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.)
FWIW the reason we haven't regenerated old releases is that old versions
of apt end up getting confused by the InRelease change and sometimes
re-download the full Packages files, which ended up effectively DDoSing
our datacentre. Awkward.
> 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.
https://bugs.launchpad.net/launchpad/+bug/716535
The main chunk of work required here is that if we're using Valid-Until
then we need to make sure that the Release/Release.gpg/InRelease files
in question are automatically regenerated before validity expires, even
if nothing has been published to the suite in question in the
intervening time. For performance and other reasons, we'd have to be
careful to do this without regenerating Packages files.
Presumably we'd only do this for non-RELEASE suites (e.g. zesty-updates,
not zesty) in order to avoid violating the constraint that RELEASE
suites are immutable after release, and since Valid-Until isn't very
interesting for immutable suites anyway. While RELEASE suites are
mutable prior to release, we'd need to think quite hard about turning
them on there or else we could get ourselves into an awkward tangle on
release day.
All this would require some careful plumbing in the publisher. It
should be a lot easier than it used to be thanks to other work in this
area (for example, we have a general per-suite "publishing_options"
column now, and the work described in
http://www.chiark.greenend.org.uk/~cjwatson/blog/re-signing-ppas.html
included adding support for regenerating Release etc. files without
doing the rest of the work), but still needs to be done.
I know roughly what needs to be done, but there's no way I'll have time
for it before the new year. Would anyone like to volunteer to have a
go? It's a medium-sized task: no database schema changes required, not
the best part of our test suite but not the worst either, and it's in a
reasonably self-contained part of our codebase. As long as you have
some Python experience it should only take a few days. I'd be happy to
act as a mentor and help you find your way around.
--
Colin Watson [cjwatson@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
