Re: [RFH] The need for signed packages and signed Releases (long, long)
>>"Anthony" == Anthony Towns <firstname.lastname@example.org> writes:
Anthony> The problem with signed debs within Debian is that they
Anthony> don't give you any information. They can indicate that
Anthony> J. Random Developer produced the package. They can't tell
Anthony> you if that package came from unstable, testing, stable,
Anthony> oldstable, from archive.debian.org, or from some random site
Anthony> the maintainer uses for random hacking -- unlike Progeny and
Anthony> Red Hat we can't simply change every package we distribute
Anthony> when we make a release, since it'd kill our mirrors. They
Anthony> could tell you the package came from Debian, although doing
Anthony> so would mean the deb we distribute would have a different
Anthony> md5sum to that in the .changes, and would be different to
Anthony> the .deb you uploaded.
This is not an either or question, though soetimes it is
presented as such. Our current practice does give a secure path to
install packages on a machine, given that you download from the
official mirrors, and follow the chain explicitly.
It does not help with packages that are not on the official
repository, are locally created, come from partial mirrors or
personal cd sets.
For official releases, it is important to know the provenance
of every package; for me, personally, I'll trust aj's packages, and
install them as long as dependencies are satisfied, and they are
newer than what I have, regardless of whether they are from testing
or not -- but in this case, unless they are part of a download from
an official mirror, I can't verify the package.
Additionally, a signed package gives an second path of
verification of origin -- as long as I have the key of the author
(whether or not he is a debian developer, in good standing, or
The objection to signed packages is one based on the truism
that signed packages can't be the _oinly_ mechanism; we do need a
trusted path like we have implemented now. But signed packages are a
welcome addendum to the security practices we implement.
Hope is a waking dream. Aristotle
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C