Mike Hommey <m...@glandium.org> writes:
> On Wed, Mar 03, 2010 at 08:29:09AM +0000, Neil Williams wrote:
>> On Wed, 3 Mar 2010 08:35:18 +0100
>> Mike Hommey <m...@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
> again.
>
> Mike
Run a nightly/weekly cron job that verifies all files. No point waiting
for a package upgrade to check this.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vdddlm95....@frosties.localdomain
