Re: dpkg-sig support wanted?
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Wed, Nov 23, 2005 at 09:18:40PM +0100, Goswin von Brederlow wrote:
>> Use 1: I have this deb in my apt-move mirror and I want to know if it
>> was compromised on yesterdays breakin
>> Boot a clean system with debian keyring and check all deb
>> signatures.
>
> Find some don't pass because they were signed with keys that have been
> removed from the keyring.
Those I remove and refetch from a clean source again. False negatives
are no big deal. 99% of the debs will verify leaving only a
managable amount of wokr behind.
>> Use 2: I have this Ubuntu CD and want to know which debs are from
>> debian and which got recompiled
>> Look for all debs that have a deb signature of the debian archive
>> (to be added to dinstall at some point).
>
> Never to be added, because it would change the .deb from that which was
> originally uploaded, for no benefit.
Fair enough.
>> Use 3: The debian servers were compromised and the security team takes
>> too long to check the archive for my taste
>> Being a normal user I obviously have no mail archive of all the
>> old changes files laying around so that road is closed. But everyone
>> has a Debian stable CD with keyring. See Use 1.
>
> And see why it doesn't work. Not to mention keys added since stable
> released, and packages uploaded by those maintainers.
>
> More than just keys removed from the keyring, there's the issue of keys
> being compromised -- it's not even unknown for developers to post secret
> keys to mailing lists -- the issue that a package that's once been in the
Compromised keys are compromised keys. No matter what you use for
authentification they don't change. One has to look for revocation
certificates and remove bad keys from the keyring prio to checking
signatures.
> archive may well by now have known security holes (which is why we have
As for known security holes in packages. They are known. The signature
of a deb only tells me that no new holes were added. And yes, that is
what we have security.debian.org for.
> security.debian.org after all), and that this is entirely moot anyway
> since the vast majority of packages can't be verified by dpkg-sig.
Ah, I see the light.
Signatures are useless because packages have no signatures.
Lightbulbs do not work because without lightbulbs it is dark.
You can't breath air because there is no oxygen in a vacuum.
>> > buildd.debian.org gives full logs, to developers or users.
>> While the log contains the md5sum of each build deb it does not
>> contain any signature against tampering.
>
> No, that's what the signed .changes file is for.
Which aren't readily available to the public.
>> Tampered debs can be uploaded by sending a fake mail to the admin and
>> filtering out his responce. A deb signature of the buildd and a
>> subsequent dak check would prevent this.
>
> So would having the buildd sign the mails to the buildd admin, which would
> have the benefit of not giving a couple of dozen completely untrustworthy
> keys special access to the archive. (AIUI, signed mails to the admin are
> on the TODO list; at present buildds don't have keys of their own at all)
Nothing in signed debs gives any keys additional access to the
archive. Checking for a buildd signature would only restrict the
access further from what we have already, not weaken it.
>> >> something that provides DD-to-user package signatures at least in some
>> >> cases is very desirable indeed.
>> > debian-devel-changes provides this.
>> That covers only the sourcefull uploads and the arch specific -changes
>> lists are not archived and therefore useless for non constant
>> monitoring.
>
> Far easier to fix that, than retrofit 150G of debs to a flawed and
> redundant scheme like this.
>
> Cheers,
> aj
Where is there any flaw? You still haven't shown any that changes
files don't also have.
As to redundant. Yes they are redundant to changes files, IF ONLY one
could get a changes file when needed and have multiple signatures in it.
MfG
Goswin
Reply to: