[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-sig support wanted?

On Thu, Nov 24, 2005 at 06:28:04PM +0100, Florian Weimer wrote:
> 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.

Mmm. I'd phrase that differently: "with the current state of technology,
there's no way of assuring that "installation of this package will not
cause any harm"". 

Which is fine; we can't assure that yet, so there's no point worrying
about it. We can provide a weaker assurance though, namely "to the
best of our knowledge, installation of this package will not create
any security vulnerabilities", or even "to the best of our knowledge,
this package does not have any release critical bugs".

Those are issues that users are interested in, and digital signatures
provide a reliable way to communicate those assurances to users.

The problem is, we can't make the latter assurance meaningfully at build
time; and more importantly both assurances are time-dependendant --
more information keeps coming to hand, and users will naturally want
the latest possible.  So we didn't know foo was exploitable last week,
big deal -- do we know it's still not exploitable today?

We currently pass on those assurances via the Release-Packages-deb path
on our archive; and expecting users to use apt-get to ensure they've got
a current assurance.

> 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?

Yes, jennifer's identical apart from some $Id$ strings. The issue's more
that ar members are checked for correctness than that additional
metadata's specifically disabled. AIUI, some of the hystrionics on
channels I no longer frequent have discouraged folks from doing dpkg-sig
advocates any favours. *shrug*

> >> 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? 

Same thing you do if you find a discrepency between the md5sum in the
Packages file and a .deb -- investigate where the corruption is and
report it?

> I don't know
> how common this would be; the hashes on buildd.debian.org are not in a
> readily extractable format, it seems.

If you just want to check hashes, you should just use changes files. If
you _actually_ want to check hashes, and this isn't just a thought
experiment, working out a usable way to deliver .changes for whatever
purpose you've got in mind would be a good idea. (Again though, I don't
see a point to them, beyond reverification of the archive in the event
of an exploit. Of course, maybe that's what you want to do...)

> 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-)

I find it amusing that all bar arm and m68k are above the 98% barrier
that caused such consternation earlier in the year...

> >> 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.

As others have pointed out, ddc's for source uploads, binary-only uploads
are on the arch-specific lists. AFAIK binNMUs aren't treated specially
in that respect.


Attachment: signature.asc
Description: Digital signature

Reply to: