[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550FC733.1050800@openwall.com>
Date: Mon, 23 Mar 2015 10:56:35 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
On 23.03.2015 03:34, Russ Allbery wrote:
> 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).
You can to accompany the package with Release{,.gpg} (or just InRelease)
files. Kinda fat detached signature. I do it when I download files like
hd-media/boot.img.gz for installer.
> 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).
I'm not sure what you mean here. Presumably you can have any subset of
the packages and they will be happily verified against Release file?
--
Alexander Cherepanov
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.
