Re: dpkg-sig support wanted?
* Anthony Towns:
> Personally, I think it's cryptographic snake oil, at least in so far
> as it relates to Debian. I remain interested in seeing any realistic
> demonstration of how a Debian user could reasonably rely on them for
> any practical assurance.
The assurance doesn't come from the signature, but from the procedures
that create it and leave a cryptographically secured audit trail on
the binary package. The approach chosen by dpkg-sig makes it possible
to add further signatures while the package is propagated through
Debian's infrastructure (unless there are some instances of
compare-by-hash hard-wired into it, but there aren't AFAIK).
Of course, with current state of technology, there can't be a digital
signature that directly says that "installation of this package will
not cause any harm". But this doesn't mean that we should give up
completely.
>> since May 31. The diff at
>> <http://cvs.debian.org/dak/jennifer?root=dak&r1=1.56&r2=1.57> shows
>> that the additional check was *removed*, not *added* more than a week
>> ago.
>
> Yes; CVS was corrupted in May and hadn't been updated 'til the other
> week. http://azure.humbug.org.au/~aj/blog/2005/11/16#2005-11-16-dak
So, just to be clear, revision 1.58 (which has been committed in the
meantime) is equivalent (if not identical) to the production version,
and adding metadata in the way dpkg-sig does is no longer possible?
>> Since there is no way for Debian Developers to review the way Debian
>> packages are created (and it's totally out of question for end users),
>
> buildd.debian.org gives full logs, to developers or users.
But what do you do if there is a discrepancy between the hash in those
logs and the package which is actually in the archive? I don't know
how common this would be; the hashes on buildd.debian.org are not in a
readily extractable format, it seems.
Oh, and I looked again at the buildd stats after some time. Good to
see that m68k is not lagging behind as dramatically as it used to.
Debian is not doomed after all. 8-)
>> something that provides DD-to-user package signatures at least in some
>> cases is very desirable indeed.
>
> debian-devel-changes provides this.
AFAIK, binary NMus aren't announced on debian-devel-changes.
Reply to: