[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Mar 2015 17:34:29 -0700
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
Solar Designer <solar@...nwall.com> writes:
> On Sun, Mar 22, 2015 at 04:48:51PM -0700, Russ Allbery wrote:
>> Debian is indeed moving in exactly that direction, using the
>> Valid-Until attribute of the archive metadata. This currently isn't
>> (yet?) enabled for the main stable archive, but is for the unstable and
>> testing archives, the security archive, and the backports archive.
> How do you handle the case when a given package build remains the
> recommended version in its branch beyond the signature's initial
> Valid-Until date? Do you issue a new signature for it?
Debian signs the entire repository state, not each individual package.
This has its pluses and minuses. The obvious drawback is that if you come
across a Debian package outside of a repository structure, it is not,
itself, signed, so you can't verify its validity (the exception is source
packages, which have an independent signature). The advantage of having a
global repository state signature is that you can do things like this
without difficulty. It has the mixed advantage and disadvantage that
partial mirrors that modify the package set have to make their own
signature and all clients that talk to them have to use different keys to
verify those packages.
Basically, the signing algorithm for a Debian repository rolls up all the
hashes for each individual package in the archive and signs the whole
thing (per-architecture, so you can do partial mirrors of only certain
architectures without invalidating the overall signature).
There's been a lot of discussion of independently signing the binary
packages as well, but so far Debian hasn't bothered since there are some
challenges around key rotation since binary packages can be long-lived,
and there aren't many real benefits given the global repository signature.
Mostly just validating packages outside the repository structure, but such
a situation is inherently vulnerable to replaying old packages with known
vulnerabilities anyway.
--
Russ Allbery (eagle@...ie.org) <http://www.eyrie.org/~eagle/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
