Re: unofficial package repository and the bugs system
Jim Pick wrote:
>
> Fabrizio Polacco <fpolacco@icenet.fi> writes:
> > What I would like to see is a version of dpkg (not dselect or deity)
> > that checks a "signature" (or a sort of) on each package and inform
> > users of the "unofficiality" of each package, asking permission to
> > install as root. Such dpkg should not only accept Debian's
> > signature, but also signatures from some third party (for example a
> > commercial distribution derived from Debian and that has a
> > commitment with us), or packages built directly by the user itself.
>
> There is a system for checking after the fact - check out:
>
> http://dpkgcert.jimpick.com/
>
> Of course, it's be running for a whole month and a half and nobody
> has used it other than myself. Oh well. :-)
>
Very nice, but it check file integrity _after_ installation.
What I was thinking was a system to check the _origin_ of each package,
to be attached to each .deb
I remember that some kind of this has been already proposed:
For example an md5sum of the data.tar.gz internal to the .deb,
pgp-signed from the Debian Installer (Guy's scripts) and automatically
added _inside_ the .deb just before putting them on the ftp site (and
maybe after some automatic testing).
Or maybe an external pgp-sign of the data.tar.gz .
Then dpkg tests it (during unpacking on the user's machine) against a
public key included in some essential package and, depending on the
result, proceed installing the package as root (like it does now) or
informs the user of the unknown origin of the package (and of the
possible danger) and prompts for the permission to install it.
Adding an Origin field to the dpkg-database including the id of the
signature could be necessary too.
There should be a way for the user to add another key to let dpkg trust
packages originated from another party (maybe a commercial firm that
sells an office set in .deb :-) .
As default we should have two keys: debian.org and non-us.debian.org (we
can't ask Guy to sign those packages and then upload to germany! :-) and
it's not secure to share a private key ). Also debian-jp is a candidate
for a third key.
The idea of not using maintainer's keys is because maintainers can
disappear or become no-more-trusted while their keys would be used to
trust old packages burned on CDs. More: revoking a key is a big job: the
less the keys are, the less the trouble is.
> I don't want to impose any rules on
> the contributors to the unofficial repository, but if they are
> making .deb packages - I'd bet they are going to be fairly
> respectful of Debian rules anyway. Why tick off your users?
No tick off.
even if we would, we can't impose any rule to any external repository,
so we have to adopt precautions to help our user distinguish trusted and
untrusted packages. I remember someone (and I remember also who) asking
for seeing maintainer's info in dselect screen because he wanted to
decide if install or not a package depending on his personal trust on
the maintainer. And we were talking about "official" packages downloaded
from ftp.debian.org!
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| 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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: