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 [[email protected]] -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
