Hi.
On Wed, 26 Feb 2014 09:32:37 +1100
Scott Ferguson <scott.ferguson.debian.u...@gmail.com> wrote:
> > No, of course not. debsums only checks files which belong to an
> > installed package. Such 'orphan' files are invisible to debsums,
> > regardless of the way they landed into filesystem.
>
> Which, um, might make confirming the authenticity, "tricky" - don't you
> think? :)
The authenticity of a Debian install - yep, using debsums proves
nothing in this case.
The authenticity of stock shell (/bin/bash), remote control
(/usr/sbin/sshd) - this is where debsums works wonders.
The whole point of running debsums was to ensure that nobody replaced
any binaries managed by package manager.
> If you don't understand what "tricky" means you've never seen a rabbit
> pulled from a hat, or a girl sawn in half (magic/illusion).
>
> The OP didn't post the results of mounting the filesystem and checking
> against the md5sums (or where they are) for the files (installed
> packages or everything in /bin /sbin ??). Until it's confirmed what
> files *were checked* it's assumptions all the way down.
Indeed, you're correct. Still, given this debsums behavior:
# ls -al /mnt
total 8
drwxr-xr-x 2 root root 4096 Jan 18 21:13 .
drwxr-xr-x 25 root root 4096 Jan 2 19:39 ..
# debsums -ac -r /mnt
dpkg-query: error: failed to open package info file
`/mnt/var/lib/dpkg/status' for reading: No such file or directory
debsums: dpkg-query --admindir=/mnt/var/lib/dpkg --showformat=${Package}
…
And assuming OP invoked debsums exactly as shown (see [1]) - I suspect
that at least / and /var was mounted into /mnt during the check.
[1] http://lists.debian.org/lefrlt$7f4$1...@ger.gmane.org
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140226094630.1428e611a245b3f209628...@gmail.com
