Re: unofficial package repository and the bugs system
Manoj Srivastava wrote:
> A while ago, Ian proposed a signature scheme for packages,
> which covered package integrity checking in a thorough, and saecure,
> fashion. I thik I prefer his method to the one proposed today.
When I said that this has been already proposed, I was thinking of Ian's
proposal and particularly to his second revision, posted on this list on
28 Feb 97.
It wasn't my intention to go in deep detail on how a cerification system
would work in a secure way, because Ian (our expert on the matter)
explained it very well and deeply.
I only wanted to let you note that the actual discussion about external
uncontrolled repositories of .deb should put a little more urgency in
implementing the certification of packages (AFAIK only identification of
maintainers has been done).
Ian, in his proposal, went deeply in detail on how to handle
certifications of keys, and revoking compromised ones, but didn't
explained how those certificates could be included inside the packages
and how dpkg would have handled them.
I think he was only thinking about packages maliciously tampered (which
should be rejected), and not about packages coming from people outside
Debian (whose packages can or cannot be accepted depending on user's
My idea (which wasn't a proposal, but only a tentative to move the
discussion) was trying to bring those issues into attention (in my
ususal caotic way, obviously :-), because I strongly think that a
discussion on "allowing or not" the creation of unofficial repository
will surely end with the creation of one or more of such repository,
while we are still without any certification and aren't even discussing
it. How many months will pass when someone will bundle to our 2 official
CDs a third one including such repositories?
I don't see any particular evil in such repositories, if we only could
offer to our users a trusted way to distinguish between packages coming
from Debian and few other trusted sources (think of non-us in which we
have pgp that is "essential" to certification), and a package created by
someone who disliked that an upstream author didn't add color to some
output, like something that I've read (not deeply) today.
Think of someone taking source and diff from the ftp site, adding some
arbitrary patch that he liked (and that our maintainer maybe discarted),
and rebuild it without even changing the version number in the changelog
or the maintainer field in the control file.
We absolutely need some simple way to protect our users (who are used to
trust Debian and its .deb binaries) from this.
| email@example.com firstname.lastname@example.org email@example.com
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .