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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ