Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 133624 - Please install MD5SUM / SHA-1 for all contents onto distribution disc images
Please install MD5SUM / SHA-1 for all contents onto distribution disc images
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Depends On:
  Show dependency treegraph
Reported: 2004-09-25 06:25 EDT by C.H.
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 14:24:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description C.H. 2004-09-25 06:25:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914

Description of problem:
Please create MD5SUM and SHA-1 hash files for all content
files on distribution files and place them on the distribution
disc images.

(cd /prototype/releasetree ; find . -type f -print0 | xargs -0 md5sum
--binary) > MD5SUMS ; mv MD5SUMS /prototype/releasetree

(cd /prototype/releasetree ; find . -type f -print0 | xargs -0 openssl
sha1 ) > SHA1s ; mv SHA1s /prototype/releasetree

et. al.

Then one could just 
(cd /mnt/dvd ; md5sum --check MD5SUM 1> /dev/null && echo ALLOK ) 
and see if anything's amiss.

This would greatly help pre-install verification of the burned images
contents anytime one might wonder if one has corruption.
(Yes, I mean in addition to the 'media check' option that the installer
program itself offers.)

e.g. this was NECESSARY with respect to seeing what if anything 
got lost when 'overburning' the oversized X86_64 FC3T2 DVD image, for

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.modify the scripts that make the release trees / disk images

Additional info:
Comment 1 Ed Bailey 2004-09-27 15:00:45 EDT
Reassigning to appropriate component...
Comment 2 Bill Nottingham 2004-09-27 15:12:01 EDT
FWIW, I don't see the x86-64 DVD as an argument for this; it was just
a broken image, plain and simple.

Not sure what this gains you over mediacheck aside from that case, and
all the RPMs have built-in signatures as well.
Comment 3 C.H. 2004-10-13 22:18:37 EDT
From the original poster --

Please also add a 'ls -lR' output list indicating the file
SIZES as well.  Many users (q.v. fedora-test-list) including myself
often have problems determining the proper SIZE of the downloaded
Fedora DVD images because apparently a lot of the distribution sites,
mirror sites, and file transfer tools do not properly list file sizes
in excess of 2 gigabytes. q.v.

Without and official downloadable lslR.txt file with the proper
sizes of the ISO / DVD images and the contents of those distributions
it's more difficult to tell what's correct.

The lslR.txt should be IN the ISO images (for all their files)
as well as a distinct one OF the ISO / DVD images which would be
downloadable from the /iso/ directory along with the images.
Comment 4 C.H. 2004-10-14 07:17:36 EDT
Re: the comment above 
'FWIW, I don't see the x86-64 DVD as an argument for this; it was just
a broken image, plain and simple.

Not sure what this gains you over mediacheck aside from that case, and
all the RPMs have built-in signatures as well.'

Well IMHO mediacheck at installation takes 100% of the time to check
every byte of the disc (presumably) with MD5 or some similar checksum.
It only gives 'pass/fail' information, and does not indicate WHAT may be
wrong if there's any discrepancy.

If a MD5SUM / SHA1 / file sizes file index was made as part of
the disc's content, one could always tell at any time whether each
file individually was correct.  I think there is a good argument for
this in general principle, since at any time an I/O error, DVD
scratch, dust on the disc or whatever could cause hard error
corruption of certain files and not others.  If 'mediacheck' fails
one has little recourse but to download or burn a totally different
disc since it's either 100% "bad" or 100% "good" as far as one can
tell. If one has file-by-file validation, one can always be judicious
and go ahead and use the good files.

Furthermore, if one has copied the disc contents to a server to
serve installation via NFS / FTP / HTTP et. al. then one cannot
do a 'mediacheck' because the files are not on the 'media' any more,
but one could still use the MD5SUM / SHA1 / SIZES files to validate
the copied file tree, thus providing a great time savings and
security of validating the files against what truly was correct for
the original distribution before one has started copying / moving
them around, and risking whatever corruptions might have happened in
the process even if one ultimately locally computes the MD5s et. al.

I'd guess there's ample time between the 'freeze' and the disc
images being created & released to the public that the MD5s et. al.
could be automatically calculated, saving thousands of users from
having to do it ab initio.

Actually I've always thought it'd be nice to have AIDE / tripwire
style databases created and populated for a distribution's
files for everything the distribution installs (e.g. coexisting with
stored with the RPMs) so that right from the installation one could
validate one's system's OS files' integrities and provide the
foundation for ongoing maintenance of those databases as sysadmin
caused changes to the installed files et. al.  Similarly I thought
it'd be nice to see distributions install CVS repositories
with checked in copies of all the 'config files' that were likely
to be edited locally, thus making it easier to track / revert
changes if some local sysadmin broke something at a given revision.
But that's all another subject, I suppose.

Note You need to log in before you can comment on or make changes to this bug.