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

Re: md5sums



Hi, 
>>"Christoph" == Christoph Lameter <christoph@lameter.com> writes:

 Christoph> debsums is used for md5sums generated *before* generating
 Christoph> the .deb. They will detect any tampering attempts or any
 Christoph> other accidents in the whole packaging in and out
 Christoph> process. Its an attempt to guarantee that the files are
 Christoph> the way they were on the *maintainers* system.

	You already have this guarantee when thepackager creates the
 .deb file, which contins filesa as they exist on their machine, and
 creates a md5sum of the .deb file, and signs it. No extra security is
 gained until after the package has been installed.

	I would rather that the packaging system create the md5sum on
 demand, just after the package has been unpacked, on machines where
 the user has requested it. There is no loss of security in that, if
 you make sure that md5sum of the .deb file matches.

	Trip wire does precisely that.


 Christoph> tripwire adds md6sums *after* installing a .deb and a virus infected
 Christoph> system could already have modified files.

	Goes to show that non security experts should not be designing
 security systems ;-O. Look, I infect files in the package *after* the
 maintainer as uploaded it and magically get around the pgp signed
 md5sum of the .deb file, I can put in fake md5sum files in there
 too. Jeeze. 

	Do not intall packages without checking .deb files. Then run
 trip wire immediately afterwards. then unpack the .deb file in /tmp
 and compare the md5sum of the trip wired file with the package yuou
 unpacked by hand. 


	md5sum files in the package offer no extra security of the
 installation that checking the .deb file before installation does
 not. And it does not waste disk space for users that do not want the
 additional security (and tripwire exists for those that do) and does
 not increase time for every developer packaging the system,

	manoj
 
-- 
 /* [...] Note that 120 sec is defined in the protocol as the maximum
 possible RTT.  I guess we'll have to use something other than TCP to
 talk to the University of Mars. PAWS allows us longer timeouts and
 large windows, so once implemented ftp to mars will work nicely. */
 (from /usr/src/linux/net/inet/tcp.c, concerning RTT [retransmission
 timeout])
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Reply to: