Re: md5sums files... and beyond

Hi, In case anyone wonders about the status of replacing md5sums with something stronger _in_ the binary packages, this should be considered to be suspended until the next development cycle. (at least, from my PoV). It have been pointed out that those current checksum aren't sufficient to validat

Re: md5sums files

On Wed, 2010-03-03 at 03:06 +0100, Wouter Verhelst wrote: > > I must say I was somewhat surprised by these numbers. Out of 2483 > packages installed on my laptop, 2340 install md5sums. While that > might've been useful at some point, I don't think it still is. Hi all, Can you think of any sensib

Re: md5sums files

On Mon, 08 Mar 2010, Brian Nelson wrote: > Don Armstrong writes: > > So there's a period on upgrade where the file has been overwritten > > with an file before the new file has been generated? > > > > That's just wrong. > > Why? Considering the old hash file may be invalid anyway after > you've u

Re: md5sums files

Don Armstrong writes: > On Sat, 06 Mar 2010, Andreas Metzler wrote: >> Russ Allbery wrote: >> > Figuring out a better solution for why the files in >> > /var/lib/ispell and /var/lib/aspell are excluded from the md5sums >> > generation because they change after installation is probably >> > neede

Re: md5sums files

On Mon, Mar 08, 2010 at 10:47:18AM +0100, Agustin Martin wrote: > On Fri, Mar 05, 2010 at 02:07:01PM -0600, Peter Samuelson wrote: > > > > [Russ Allbery] > > > Figuring out a better solution for why the files in /var/lib/ispell > > > and /var/lib/aspell are excluded from the md5sums generation bec

Re: md5sums files

On Fri, Mar 05, 2010 at 11:45:38AM -0800, Russ Allbery wrote: > Don Armstrong writes: > > On Wed, 03 Mar 2010, Wouter Verhelst wrote: > > >> In this day and age of completely and utterly broken MD5[0], I think we > >> should stop providing these files, and maybe provide something else > >> instea

Re: md5sums files

On Fri, Mar 05, 2010 at 02:07:01PM -0600, Peter Samuelson wrote: > > [Russ Allbery] > > Figuring out a better solution for why the files in /var/lib/ispell > > and /var/lib/aspell are excluded from the md5sums generation because > > they change after installation is probably needed if we're going

Re: md5sums files

> Peter Samuelson writes: > > How many times do I have to say "the .deb also includes checksums of > > control.tar.gz and data.tar.gz, thanks to use of the gzip container > > format" before you notice? [Goswin von Brederlow] > - You download and verify the deb with the checksum in Packages.gz. >

Re: md5sums files

Michael Banck writes: > On Sun, Mar 07, 2010 at 01:25:44AM +0100, Goswin von Brederlow wrote: >> > I don't think that just because something is required, it should be >> > necessarily part of dpkg. So far, we are talking about a policy of >> > including md5sum in our .debs, *not* about changing

Re: md5sums files

Peter Samuelson writes: >> Peter Samuelson writes: >> > Be that as it may, I don't think the md5sums file was ever intended to >> > be an integrity check of the .deb itself. Fortunately, the .deb also >> > includes checksums of control.tar.gz and data.tar.gz, thanks to use of >> > the gzip cont

Re: md5sums files

On Sun, Mar 07, 2010 at 01:25:44AM +0100, Goswin von Brederlow wrote: > > I don't think that just because something is required, it should be > > necessarily part of dpkg. So far, we are talking about a policy of > > including md5sum in our .debs, *not* about changing the .deb format to > > requir

Re: md5sums files

* Anthony Towns [100307 07:42]: > "Big"? It only makes a difference if: > [...] > c) the system memory is corrupted just enough to screw the file but > not everything else For many machines installing packages is the biggest thing they ever do. So with a very low error rate, that perhaps causes

Re: md5sums files

On Sun, Mar 7, 2010 at 10:28, Goswin von Brederlow wrote: > Anthony Towns writes: >> Advantages of doing it when uploading: >>  - provides some sort of double check of what's being uploaded >>  - saves CPU time on users' machines >   - avoids having bad checksums due to the user having bad hardwa

Re: md5sums files

> Peter Samuelson writes: > > Be that as it may, I don't think the md5sums file was ever intended to > > be an integrity check of the .deb itself. Fortunately, the .deb also > > includes checksums of control.tar.gz and data.tar.gz, thanks to use of > > the gzip container format. [Goswin von Bre

Re: md5sums files

led on my laptop, 2340 install md5sums. >> The surprising part, perhaps, is that dpkg itself didn't just generate >> the other 143 md5sums files at installation time. > > The easy (and usually correct) reason for things like that is "dpkg's > source is scary". >

Re: md5sums files

Michael Banck writes: > On Fri, Mar 05, 2010 at 07:54:29PM +0100, Goswin von Brederlow wrote: >> Bernd Zeimetz writes: >> > I think its about time to require to generate checksums for packages and >> > make >> > all packages which do not do so RC buggy. >> >> If a checksum file becomes require

Re: md5sums files

Peter Samuelson writes: >> > On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: >> >> fundamentally, shipping a md5sums file is really just a tradeoff in >> >> download size vs. installation speed, not unlike gzip vs. bzip2. One > >> Julien Cristau writes: >> > Only if you assume th

Re: md5sums files

On Sat, 06 Mar 2010, Andreas Metzler wrote: > Russ Allbery wrote: > > Figuring out a better solution for why the files in > > /var/lib/ispell and /var/lib/aspell are excluded from the md5sums > > generation because they change after installation is probably > > needed > > I think these hash files

Re: md5sums files

ising part, perhaps, is that dpkg itself didn't just generate > the other 143 md5sums files at installation time. The easy (and usually correct) reason for things like that is "dpkg's source is scary". > I suggested this a long time ago and of course was met with "so

Re: md5sums files

On Fri, Mar 05, 2010 at 07:54:29PM +0100, Goswin von Brederlow wrote: > Bernd Zeimetz writes: > > I think its about time to require to generate checksums for packages and > > make > > all packages which do not do so RC buggy. > > If a checksum file becomes required then it really is not the job

Re: md5sums files

On 06/03/2010 09:27, Andreas Metzler wrote: > Russ Allbery wrote: >> Don Armstrong writes: > [...] >>> Is there any reason why we can't just modify dpkg-deb to create >>> DEBIAN/md5sums and DEBIAN/sha512sums and get archive coverage relatively >>> quickly, automatically, as things get rebuilt? >

Re: md5sums files

Russ Allbery wrote: > Don Armstrong writes: [...] >> Is there any reason why we can't just modify dpkg-deb to create >> DEBIAN/md5sums and DEBIAN/sha512sums and get archive coverage relatively >> quickly, automatically, as things get rebuilt? > Figuring out a better solution for why the files in

Re: md5sums files

> > On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: > >> fundamentally, shipping a md5sums file is really just a tradeoff in > >> download size vs. installation speed, not unlike gzip vs. bzip2. One > Julien Cristau writes: > > Only if you assume that disks never fail and thus fi

Re: md5sums files

[Russ Allbery] > Figuring out a better solution for why the files in /var/lib/ispell > and /var/lib/aspell are excluded from the md5sums generation because > they change after installation is probably needed if we're going to > remove creation of those files from control of the packager. It seems

Re: md5sums files

Don Armstrong writes: > On Wed, 03 Mar 2010, Wouter Verhelst wrote: >> In this day and age of completely and utterly broken MD5[0], I think we >> should stop providing these files, and maybe provide something else >> instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop >> providing md5s

Re: md5sums files

On Wed, 03 Mar 2010, Wouter Verhelst wrote: > In this day and age of completely and utterly broken MD5[0], I think we > should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing > md5sums. Is there any reason why

Re: md5sums files

Julien Cristau writes: > On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: > >> fundamentally, shipping a md5sums file is really just a tradeoff in >> download size vs. installation speed, not unlike gzip vs. bzip2. One > > Only if you assume that disks never fail and thus files nev

Re: md5sums files

Bernd Zeimetz writes: > Philipp Kern wrote: >> On 2010-03-03, Wouter Verhelst wrote: >>> This is where I disagree. When a checksum algorithm is compromised (and >>> MD5 *is* compromised), things only ever get worse, not better. Indeed, >>> MD5 preimage attacks are pretty hard *today*. But switch

Re: md5sums files

On jeu., 2010-03-04 at 22:43 +0100, Joerg Jaspert wrote: > >> This script signs each file in the package individually, but it could > >> also concatenate them all alphabetically and create just one signature. > > > There have been previous discussions on debian-devel about this. I > > believe DAK

Re: md5sums files

>> This script signs each file in the package individually, but it could >> also concatenate them all alphabetically and create just one signature. > There have been previous discussions on debian-devel about this. I > believe DAK does not allow packages signed using debsigs to be uploaded. > I'm

Re: md5sums files

Stefano Zacchiroli writes: > Russ, while we are at it, would you mind a bug report on the policy to > suggest (starting at SHOULD?) to store md5sums in packages? Not that I've had any time to work on Policy (or Lintian) in the last month, but that does seem reasonable to me. It seems to be a wi

Re: md5sums files

]] Frank Lin PIAT | What about a transitional dh_md5sums that would produce md5sum AND | invoke dh_sha ? Or call it dh_checksums or something so we don't have to change the tool name each time we decide to change the algorithm. (And I want the shed blue with pink spots.) -- Tollef Fog Heen UN

Re: md5sums files

]] James Vega | On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote: | > I think I was finally able to decipher your message. But my other | > points still hold. And while it is just a matter of programming, | > simple or not, it already exists in debhelper. So doing it at build | > t

Re: md5sums files

= 2.0.7) > > * debsums_init(8) (debsums >= 2.0.34 @ 2007) > > It's not uncommon to be given an existing system and want to verify > that no files were modified by its creator, and the current lack of > md5sums files for a few packages prevents using debsums to do th

Re: md5sums files

On Wed, Mar 03, 2010 at 10:19:21PM +0100, Stefano Zacchiroli wrote: > On Wed, Mar 03, 2010 at 08:08:38PM +0100, Bernd Zeimetz wrote: > > I think its about time to require to generate checksums for packages > > and make all packages which do not do so RC buggy. > > Well, RC buggy is probably a tad

Re: md5sums files

On Thu, Mar 04, 2010 at 09:27:06AM +0100, Patrick Schoenfeld wrote: > Which is not the case. There are still people who like to package > without helpers. Agreed, that's exactly why I've proposed also the bug report on policy. As per our customs, the policy will then state the desired result, the

Re: md5sums files

On Thu, Mar 04, 2010 at 09:11:21AM +0100, Stefano Zacchiroli wrote: > FWIW, about the people proposing to change from md5 to something else, > it should be pretty easy to achieve too: if all of us is using > dh_md5sums, Which is not the case. There are still people who like to package without hel

Re: md5sums files

On Wed, Mar 03, 2010 at 01:51:20PM -0800, Russ Allbery wrote: > We added a Lintian tag warning about not having md5sums in that time > frame, I think. Gotcha, that must be it. Very impressive result. FWIW, about the people proposing to change from md5 to something else, it should be pretty easy t

Re: md5sums files

James Vega writes: > On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote: >> I think I was finally able to decipher your message. But my other >> points still hold. And while it is just a matter of programming, simple >> or not, it already exists in debhelper. So doing it at build tim

Re: md5sums files

On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote: > I think I was finally able to decipher your message. But my other points > still > hold. And while it is just a matter of programming, simple or not, it already > exists in debhelper. So doing it at build time is SMOAOLTDR, by wh

Re: md5sums files

On Wed, Mar 03, 2010 at 06:50:28PM -0600, Peter Samuelson wrote: > > [Harald Braumann] > > On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote: > > > > > > [Harald Braumann] > > > > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. > > > > > This could be before, dur

Re: md5sums files

[Harald Braumann] > On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote: > > > > [Harald Braumann] > > > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. > > > > This could be before, during, or after the deb is unpacked. > > > > > If you create the hashes at unpac

Re: md5sums files

On Wed, Mar 03, 2010 at 05:41:26PM -0600, Peter Samuelson wrote: > > [Harald Braumann] > > > Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP. > > > This could be before, during, or after the deb is unpacked. > > > If you create the hashes at unpack time, you don't catch errors th

Re: md5sums files

On Wed, Mar 03, 2010 at 03:14:04PM -0800, Russ Allbery wrote: > Harald Braumann writes: > > > Completely agreed. Also, because playing around is always more fun than > > just talking, I've attached a script that signs/verifies binary > > packages. Dpkg doesn't seem to mind the extra files. > > >

Re: md5sums files

;m talking about whether there are any disadvantages to generating foo.md5sums at unpack time, other than the obvious one (CPU usage). Signed debs and signed repositories are an entirely separate discussion. md5sums files don't even pretend to solve the same problems. They solve other problem

Re: md5sums files

Harald Braumann writes: > Completely agreed. Also, because playing around is always more fun than > just talking, I've attached a script that signs/verifies binary > packages. Dpkg doesn't seem to mind the extra files. > This script signs each file in the package individually, but it could > als

Re: md5sums files

On Wed, Mar 03, 2010 at 04:20:36PM -0500, Michael Gilbert wrote: > On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote: > > Signed debs may introduce a fake sense of security (Only apt repository > > provide security updates). By signing packages, user may assume that a > > package is safe whe

Re: md5sums files

Stefano Zacchiroli writes: > I'm curious about what contributed to this positive change (dh7 and/or > CDBS invoking dh_md5sums by default?), any idea? We added a Lintian tag warning about not having md5sums in that time frame, I think. -- Russ Allbery (r...@debian.org)

Re: md5sums files

On Wed, Mar 03, 2010 at 08:34:27AM +, Philipp Kern wrote: > On 2010-03-03, Neil Williams wrote: > > Changing to SHA won't help. I'm for ditching all md5sums from packages. > > It's not a lot of disc space gained but it does give a false sense of > > security or 'insurance' if you want to avoid

Re: md5sums files

On Wed, Mar 03, 2010 at 08:08:38PM +0100, Bernd Zeimetz wrote: > I think its about time to require to generate checksums for packages > and make all packages which do not do so RC buggy. Well, RC buggy is probably a tad excessive for this release, considering that we are (I hope :)) close to a fre

Re: md5sums files

On Wed, 03 Mar 2010 21:58:11 +0100, Frank Lin PIAT wrote: > On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote: > > Wouter Verhelst writes: > > > > > Or is it useful to be able to say "if it doesn't check out, it's > > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't >

Re: md5sums files

On Wed, 2010-03-03 at 11:37 +, Philipp Kern wrote: > On 2010-03-03, Wouter Verhelst wrote: > > This is where I disagree. When a checksum algorithm is compromised (and > > MD5 *is* compromised), things only ever get worse, not better. Indeed, > > MD5 preimage attacks are pretty hard *today*. Bu

Re: md5sums files

On Tue, 2010-03-02 at 18:21 -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > > Or is it useful to be able to say "if it doesn't check out, it's > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > > think so. > > I don't understand why you say this. Cryptographi

Re: md5sums files

On Wed, Mar 03, 2010 at 02:02:01PM -0600, Peter Samuelson wrote: > > [Julien Cristau] > > > fundamentally, shipping a md5sums file is really just a tradeoff in > > > download size vs. installation speed, not unlike gzip vs. bzip2. One > > > > Only if you assume that disks never fail and thus fil

Re: md5sums files

[Julien Cristau] > > fundamentally, shipping a md5sums file is really just a tradeoff in > > download size vs. installation speed, not unlike gzip vs. bzip2. One > > Only if you assume that disks never fail and thus files never get > corrupted when the package gets unpacked. Given a .deb, turni

Re: md5sums files

e given an existing system and want to verify that no files were modified by its creator, and the current lack of md5sums files for a few packages prevents using debsums to do that. (The most common case is probably buying a Debian VM from a hosting company.) -- see shy jo signature.asc Description: Digital signature

Re: md5sums files

On Wed, Mar 3, 2010 at 10:05:11 -0600, Peter Samuelson wrote: > fundamentally, shipping a md5sums file is really just a tradeoff in > download size vs. installation speed, not unlike gzip vs. bzip2. One Only if you assume that disks never fail and thus files never get corrupted when the package

Re: md5sums files

Philipp Kern wrote: > On 2010-03-03, Wouter Verhelst wrote: >> This is where I disagree. When a checksum algorithm is compromised (and >> MD5 *is* compromised), things only ever get worse, not better. Indeed, >> MD5 preimage attacks are pretty hard *today*. But switching to something >> more secur

Re: md5sums files

On Thu, Mar 04, 2010 at 01:12:26AM +0900, Osamu Aoki wrote: > > > In this day and age of completely and utterly broken MD5[0], I think we > > should stop providing these files, and maybe provide something else > > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing > > md5sum

Re: md5sums files

Hi, On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote: > Hello world, > > wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l > 2340 > wou...@celtic:/var/lib/dpkg/info$ ls *sums|wc -l > 2340 > wou...@celtic:/var/lib/dpkg/info$ dpkg -l|sed -e'1,/=/d'|wc -l > 2483 Here on my syst

Re: md5sums files

On Wed, Mar 03, 2010 at 11:37:17AM +, Philipp Kern wrote: > On 2010-03-03, Wouter Verhelst wrote: > > This is where I disagree. When a checksum algorithm is compromised (and > > MD5 *is* compromised), things only ever get worse, not better. Indeed, > > MD5 preimage attacks are pretty hard *tod

Re: md5sums files

[Wouter Verhelst] > I must say I was somewhat surprised by these numbers. Out of 2483 > packages installed on my laptop, 2340 install md5sums. The surprising part, perhaps, is that dpkg itself didn't just generate the other 143 md5sums files at installation time. I suggested this

Re: md5sums files

On Wed, Mar 03, 2010 at 03:16:08PM +0100, Bernhard R. Link wrote: > * Harald Braumann [100303 14:49]: > > But it would be great if the whole chain, from beginning to end, was > > secured, even against a malicious and presumably very powerful attackers. > > Checksums for files coming from packages

Re: md5sums files

On Wed, Mar 03, 2010, Wouter Verhelst wrote: > In this day and age of completely and utterly broken MD5[0], I think we > should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing > md5sums. > > Or is it useful to

Re: md5sums files

* Harald Braumann [100303 14:49]: > As a means to check for filesystem corruptions or non-malicious changes, > MD5 is good enough. So until we have something better, I guess they can > stay. I'd even say they should stay. The shorter the hash the more useable. And md5 is the shortest well-defined

Re: md5sums files

On Wed, Mar 03, 2010 at 02:39:05PM +0100, Harald Braumann wrote: > On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote: > > In this day and age of completely and utterly broken MD5[0], I think we > > should stop providing these files, and maybe provide something else > > instead. Like,

Re: md5sums files

On Wed, Mar 03, 2010 at 03:06:20AM +0100, Wouter Verhelst wrote: > In this day and age of completely and utterly broken MD5[0], I think we > should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop providing > md5sums. > >

Re: md5sums files

On 2010-03-03, Wouter Verhelst wrote: > This is where I disagree. When a checksum algorithm is compromised (and > MD5 *is* compromised), things only ever get worse, not better. Indeed, > MD5 preimage attacks are pretty hard *today*. But switching to something > more secure in preparation for the d

Re: md5sums files

On Wed, Mar 03, 2010 at 03:17:52PM +1100, Erik de Castro Lopo wrote: > Russ Allbery wrote: > > > Wouter Verhelst writes: > > > > > Or is it useful to be able to say "if it doesn't check out, it's > > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > > > think so. > > >

Re: md5sums files

Mike Hommey writes: > On Wed, Mar 03, 2010 at 08:29:09AM +, Neil Williams wrote: >> On Wed, 3 Mar 2010 08:35:18 +0100 >> Mike Hommey wrote: >> >> > On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote: >> > > >> > > The md5 sums isn't to be used in case of a break in, as you can't

Re: md5sums files

Erik de Castro Lopo writes: > Russ Allbery wrote: > >> Wouter Verhelst writes: >> >> > Or is it useful to be able to say "if it doesn't check out, it's >> > certainly corrupt, and if it does check out, it may be corrupt"? Didn't >> > think so. >> >> I don't understand why you say this. Crypto

Re: md5sums files

Wouter Verhelst, 2010-03-03 03:06:20 +0100 : [...] > In this day and age of completely and utterly broken MD5[0], I think > we should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs? But stop > providing md5sums. > > Or is it use

Re: md5sums files

On Wed, Mar 03, 2010 at 08:29:09AM +, Neil Williams wrote: > On Wed, 3 Mar 2010 08:35:18 +0100 > Mike Hommey wrote: > > > On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote: > > > > > > The md5 sums isn't to be used in case of a break in, as you can't trust > > > anything on the sy

Re: md5sums files

On 2010-03-03, Neil Williams wrote: > Changing to SHA won't help. I'm for ditching all md5sums from packages. > It's not a lot of disc space gained but it does give a false sense of > security or 'insurance' if you want to avoid the more formal meaning of > 'security'. Please don't. It's not abo

Re: md5sums files

On Wed, 3 Mar 2010 08:35:18 +0100 Mike Hommey wrote: > On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote: > > > > The md5 sums isn't to be used in case of a break in, as you can't trust > > anything on the system anyways, but more things like: > > - did I make; sudo make install some

Re: md5sums files

On Wed, Mar 03, 2010 at 06:30:34AM +, Sune Vuorela wrote: > On 2010-03-03, Wouter Verhelst wrote: > > wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l > > 2340 > > > In this day and age of completely and utterly broken MD5[0], I think we > > should stop providing these files, and maybe pro

Re: md5sums files

On 2010-03-03, Wouter Verhelst wrote: > wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l > 2340 > In this day and age of completely and utterly broken MD5[0], I think we > should stop providing these files, and maybe provide something else > instead. Like, I dunno, shasums? Or perhaps gpgsigs

Re: md5sums files

Erik de Castro Lopo writes: > Russ Allbery wrote: >> I don't understand why you say this. Cryptographic attacks on MD5 >> aren't going to happen as a result of random file corruption. The MD5 >> checksums are still very effective at finding file corruption or >> modification from what's in the

Re: md5sums files

Russ Allbery wrote: > Wouter Verhelst writes: > > > Or is it useful to be able to say "if it doesn't check out, it's > > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > > think so. > > I don't understand why you say this. Cryptographic attacks on MD5 aren't > going to

Re: md5sums files

Wouter Verhelst writes: > Or is it useful to be able to say "if it doesn't check out, it's > certainly corrupt, and if it does check out, it may be corrupt"? Didn't > think so. I don't understand why you say this. Cryptographic attacks on MD5 aren't going to happen as a result of random file co

md5sums files

Hello world, wou...@celtic:/var/lib/dpkg/info$ ls *md5sums|wc -l 2340 wou...@celtic:/var/lib/dpkg/info$ ls *sums|wc -l 2340 wou...@celtic:/var/lib/dpkg/info$ dpkg -l|sed -e'1,/=/d'|wc -l 2483 I must say I was somewhat surprised by these numbers. Out of 2483 packages installed on my laptop, 23