oss-sec mailing list archives
Re: CVE for Kali Linux
From: Russ Allbery <eagle () eyrie org>
Date: Sun, 22 Mar 2015 17:34:29 -0700
Solar Designer <solar () openwall 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 () eyrie org) <http://www.eyrie.org/~eagle/>
Current thread:
- Re: CVE for Kali Linux, (continued)
- Re: CVE for Kali Linux Kristian Fiskerstrand (Mar 22)
- Re: CVE for Kali Linux Jeremy Stanley (Mar 22)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Stephen Kitt (Mar 22)
- Re: CVE for Kali Linux Daniel Micay (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 22)
- Re: CVE for Kali Linux Russ Allbery (Mar 22)
- Re: CVE for Kali Linux Solar Designer (Mar 22)
- Re: CVE for Kali Linux Russ Allbery (Mar 22)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 23)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 24)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 24)