bug-fileutils
[Top][All Lists]
Advanced

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

Re: [ANNOUNCE] GNU fileutils 4.1


From: Dave Dittrich
Subject: Re: [ANNOUNCE] GNU fileutils 4.1
Date: Wed, 23 May 2001 18:15:08 -0700 (PDT)

Hey Paul,

> A nit: dd can only tell you the checksum for the file that it reads,
> not for the file that it writes.  So you need to do something like the
> above step anyway, for the last copy in your chain.

Understood, which is why I'm backing out one change I made (to do
checksumming of both input and output blocks - I only need it to
checksum input blocks).

> I'm not sure, though, that dd is the right place for this; perhaps it
> would be better to have a separate tool?  dd tends to suffer from the
> kitchen-sink problem.  Maybe it's better to put this into md5sum
> instead?

md5sum just reads stdin and checksums it.  It doesn't have any of the
other features of dd, like byte swapping, alternate output blocking
for efficiently filling streaming media buffers, etc.  It was rather
trivial, actually, to add md5 checksumming to dd.  After my initial
attempt, I also had someone suggest other internationally accepted
hashing algorithms, and "bubble-babble" format hashes to facilitate
verbal verification of hashes.

Because of the acceptability requirement for the courts, it is most
advantageous to get this into the official dd release, rather than a
separate program that may not be widely used.  I think its use
will increase as people learn you can build quality backup mechanisms
if simple write/read verification features are in dd.

> > I want to have a method of maintaining chain of custody and
> > integrity throughout the process of imaging and file transfer, even
> > in the face of bad media or one lost/damaged CD-ROM out of a set of N.
>
> It seems to me that the most important part of your proposed change is
> the documentation for it.  That will help to explain to users why the
> change is important (as well as justify it to the maintainer).  The
> documentation should address issues like how to checksum the output,
> and also how to store the checksums safely (do you checksum the
> checksums?  that sort of thing).  I don't think a treatise is needed
> (though it would be nice), but a simple howto would be quite helpful.

We had already planned on documentation.

--
Dave Dittrich                           Computing & Communications
address@hidden             University Computing Services
http://staff.washington.edu/dittrich    University of Washington

PGP key      http://staff.washington.edu/dittrich/pgpkey.txt
Fingerprint  FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5




reply via email to

[Prev in Thread] Current Thread [Next in Thread]