Re: dpkg-sig support wanted?
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote:
>> 2) A signature from dinstall saying "this package was installed in the
>> Debian archive" would provide a means of automatic "assurance" of the source
>> of a binary package, when I'm putting together custom CDs or package repos.
>
> You can already use release signatures for this. Further, changing the
Only if you have a release signature corresponding to every deb and
the Packages files where that deb was in. If you collect debs over any
amount of time that would become a huge archive.
> deb after upload would make it much more difficult to check the deb was
> what was uploaded -- you can no longer just use md5sum, you've instead
> got to use special tools.
So? Is that so bad?
Also so far nothing is changing debs after upload. The deb signatures
so far are all done prior to uploading and even changes file
generation. Only a dinstall signature would change that, making the
changes file less easy to verify while keeping everything else the
same.
>> 3) I can verify the provenance of a particular package in my own custom
>> repos at any time (did that come from Debian? Did someone build it
>> internally? What's going on?) I can kinda-sorta do that if I manually sign
>> each binary package I download & verify against the Packages->Release chain
>> with a special "came from Debian" key, and I can verify the source of the
>> source (heh) package via the dsc signature, but having a complete "chain of
>> custody" on a binary package seems like a "nice" thing to have.
>
> Sure; but why do that inside the .deb? You can verify a detached signature
> just as easily as an inline one (gpgv sig file // gpgv file), and you
> can verify a signature of a hash just as easily as a signature of a file.
> If you're worried you might lose the detached, signed information, either
> keep it with the data it's authenticating (pool/main/f/foo/foo.origin,
> eg), or keep good backups, or both.
I've requested that the changes files be kept along with the debs in
pool several times. It aparently isn't going to happen. Also a
detached signature needs more space since it uses another inode and a
full block on the filesystem instead of just the few bytes inside the
deb.
And yes, I am worried about loosing the detached signatures. Why risk
it if we have a perfect mechanism without it?
>> At the very least, though, I can't find a hole which makes binary package
>> signatures, done properly, any less secure than per-archive signing.
>
> That's easy: you trust the Packages file to be correct when using apt,
> and it's not verified at all by per-package signatures.
In what way trust and how does that change anything?
At best you can prevent a newer version of a package to appear in the
Packages file by compromising it. You can't subvert a package itself.
But you can already ship yesterdays Release.gpg, Release and Packages
file to a user and thereby prevent any updates.
On the other hand, without package signatures ftp-master adds a
vulnerability. You can hack into it, replace debs, recreate the
Packages, Release and Release.gpg file and thereby infect users. With
signed debs that could still be detected by every user in apt-get.
It is not that I don't trust ftp-master but that I don't even have to
trust it.
>> Is your
>> objection to binary-package signing that it is "no better" than archive
>> signing, or that it is actively *worse* than per-archive signing (again, if
>> both are done "properly", whatever we may define that to mean).
>
> My objection is that it's *useless* for *Debian*. Debian has too many
> sources for packages for key management to be plausible, and keeps
> packages unchanged over too long a period for the keys to be guaranteed
> secure for the lifetime of a package. Additionally, packages can be
> authenticated both via Packages.gz files and .changes files, which
> already exist and are usable.
Changes files are not publicly accessible on demand so they are not
practical for any authentication. And even if you have a changes file
at hand by chance its signature has exactly the same security as
debsig has. It is as secure as the DDs key. The major difference is
the accessibility.
And Packages.gz has a 24h lifetime at worst. It is only a temporary
means to validate a deb.
So both methods are, to put it in your words, *useless* for *users*.
Please have a bit of an open mind and don't just think about what the
archive needs.
>> One scenario, which initially seems compelling, but which I've since
>> rejected, is that of "offline signing" of binary packages -- the idea that
>> the archive can be authenticated via signatures applied to packages before
>> they hit the archive.
>
> This is what .changes files are for, and it's useful both for recovering
> from compromises and in a "cvs blame" sort of sense. Note that they also
> give more information than a simple signature on the .deb.
>
> Hrm, I see queue/done (which contains .changes files going back to the
> dark ages) isn't even being mirrored to merkel properly at the moment.
> That's not so constructive.
That isn't publicly available. If you want changes file to be anywere
as usefull as debsig signatures then put them into pool along with
each deb. Unless users can download changes files when needed they
just can't count.
> Cheers,
> aj
MfG
Goswin
Reply to: