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

Re: md5sums files

On Wed, Mar 03, 2010 at 08:29:09AM +0000, Neil Williams wrote:
> On Wed, 3 Mar 2010 08:35:18 +0100
> Mike Hommey <mh@glandium.org> wrote:
> > On Wed, Mar 03, 2010 at 06:30:34AM +0000, 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 something on top of packages
> > >  - did I just quickly hack a p{erl,ython}-script on the system to do
> > >    something different and forgot
> > 
> > Which makes me think... wouldn't it be nice from dpkg to check the
> > package files haven't been modified before upgrading ?
> No - if you're upgrading, you're doing it because you want to be sure
> that the Debian version replaces the old version. However, if you do
> use 'make; sudo make install; with a prefix of /usr instead
> of /usr/local then a) you're taking a risk and b) md5sums are only a
> partial protection. md5sums will NOT catch instances where the upstream
> 'make install' provides files that are not part of the Debian package
> nor will it catch files that have been moved as part of Debian
> packaging. As these files are not put into place by dpkg anyway, then
> they won't get cleaned up by dpkg and cannot be detected either by
> using md5sums or by using dpkg. (dpkg will complain that certain
> directories are not empty if the packaged files being upgraded are in
> special places but not otherwise.) There's every chance that having
> extraneous and/or duplicate content in the wrong places will break the
> Debian package in ways that are not easily detectable and md5sums won't
> help with that.
> Having md5sums around for simple checks like local admins copying
> modified scripts over packaged versions is one thing but IMHO it does
> not justify having md5sums in the wider case because a) local admin
> changes are the responsibility of the local admin and b) md5sums only
> help detect those changes where the admin changes a filename that
> exactly matches the packaged name rather than adding more content /
> cruft.
> 'sudo make install' into /usr is not something that md5sums can help us
> fix and if that is the sole justification for retaining them then I
> think that is a false argument.

My point is that these people doing that, or even better, people doing
an upgrade on a system where other people have been doing that would
probably *want* to have a warning about the fact that the files dpkg is
going to replace did *not* match what was supposed to be there in the
first place.

That would also possibly help spot filesystem errors, because when
upgrading, dpkg is not going to write to the same places where the
previous versions of the files were, and when it finishes upgrading, it
will just remove the previous files and the corruptions, especially if
they are due to hardware problems, will still be unnoticed and may
affect more important data much later, when the freed space is used


Reply to: