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

Re: md5sums



Hi, 
>>"Charles" == Charles Briscoe-Smith <cpbs@debian.org> writes:

 Charles> Hi all,
 Charles> A few thoughts about these md5sums files:

 Charles> First, what do we want file md5sums for?  As far as I know,
 Charles> the point of the md5sums is to detect accidental corruption
 Charles> of installed files:

	Trip wire does that.

 Charles> to check whether you have mistakenly edited an installed script which
 Charles> wasn't a conffile,

	Ok. But this is not an operation that everyone wants (I
 personally have never needed to do that -- and I can, since I have a
 local mirror, and I can use dpkg --unpac in /tmp and compare
 files). Given that there are old, slow, and low disk space machines
 out there, one should not push all this to every machine out there. 

 Charles> or to check which packages need reinstalling after you've
 Charles> been careless with "rm".

	This does not need md5sum files. The *.list files are enough
 for that.

 Charles> For detecting accidental deletions, I agree with those who've said that
 Charles> there's no point including this information in the package.

	That information is already tracked. Look at
 /var/lib/dpkg/info/*.list. You can track deletiojns using that. 

 [SNIP -- old slow machines]

	Ok. The problem here is that not every one wants the
 performance hit if the md5sum creation or storage, and even if we
 make that optional, the decision would be irrevocable. Again, if it
 is on the machine, then malicous crackers can crrupt the md5sum
 database too. Here follows a scheme that is scalable, and more
 secure, by pulling all security issues to the security of a public
 key, and we can concentrate on making that hard to break.

 a) A tree of md5sum files for packages is maintianed on the Archive,
    and replicated by the mirror array. The files are only removed
    after X years, X >=4. <package>-<version>-<arch>-files.md5sum
 b) These files are created at the point the package is installed into
    the Archive (dinstall).
 c) Also at the same time, we take a md5sum of the
    <package>-<versdion>-<arch>-files.md5sum file it self, and create,
    in a non replicated dir on Master, a one line index snippet file
    <package>-<versdion>-<arch>.md5sum 
 d) Once a day, after dinstall is done, the index snippet files are
    concatenated into a replicated Index.md5sum-current file.
 e) Once a week, the latest Index.md5sum-current file is moved to
    Index.md5sum file, and the is signed by a ``Official Debian
    Signing Key''. The signature is a detatched signature, and is
    never mirrored.
 f) The ``Official Debian Signing Key'' should be on a secure machine,
    and have signatures from at least 2 of three ``Official Debian
    Keys'', which are entrusted to different office holders appointed
    by the Leader, and these keys are never on a public machine.


	So how does it all work? When you say check <package>;  the
 script 

 1. gets the detatched signature from a known IP (possibly master). 
 2. Then, like apt, it down loads the Index file, and the
    package  md5sum file, from any mirror. 
 3. It checks the signature on the Index file
 4. It checks the md5sum of the <package>-<version>-<arch>-files.md5sum
    file.
 5. It checks the files mentioned in the latter with the local
    machine.

	The critical part is getting the  ``Official Debian Signing
 Key''  well enough replicated and into the web of trust that one
 knows that one has a known good value of the public key. Possibly,
 the public key should be on all mirrors, and CD's, and we publish the
 signature of the key all over, to lower the possibility of forgery.

 Charles> But those points have already been made....  The point I wanted to make
 Charles> is that storing the md5sum (or another checksum) of the file isn't
 Charles> enough.  We also need to store ownership (user and group), permissions,
 Charles> and, for symlinks, destination.  While we're at it, file size and last
 Charles> modification date would be good, too.  Arguably, the ownership and
 Charles> permissions of a file are easier to accidentally corrupt than its
 Charles> contents.


	Congratulations. You have just reinvented tripwire. more or less. 

	manoj
-- 
 It is easier for a camel to pass through the eye of a needle if it is
 lightly greased. Kehlog Albran, "The Profit"
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: