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

Re: [RFH] The need for signed packages and signed Releases (long, long)

>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> 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   <srivasta@debian.org>  <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

Reply to: