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

Re: md5sums files

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 /

'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.

Debian does move a lot of files around during packaging (the recent
stipulation against files in /var/www/ is just one instance) - my own
feeling is that the very packages that DO have their files moved around
for FHS reasons are the very ones that (some) local admins may want to
install from upstream tarballs ahead of the Debian package being
updated. Moving files invalidates any protection from having the
md5sum - unless the local admin retains a separate list of which files
have been installed separately, but then I thought the idea was that
such a record would be available by installing into /usr/local instead
of /usr in the first place. ;-)

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


Neil Williams

Attachment: pgp6VzW7xCPDG.pgp
Description: PGP signature

Reply to: