When emerge is computing the MD5 checksum of a file, if the file is a prelinked binary (using the "prelink" command), emerge first undoes the prelinking and computes the checksum of the resulting file. That is appropriate for working out whether a file has been changed by the user or by another package -- as opposed to merely having its relocations changed by "prelink" for faster loading. Unfortunately, the equery and qpkg programs in Gentoolkit don't undo these relocation changes when checking a package's installed integrity. This means that after a whole system is prelinked, equery and qpkg show that every binary in the system no longer matches its checksum. While this is true, it is unhelpful for checking whether installed packages are basically fine. There are functions called perform_checksum and perform_md5 in /usr/lib/portage/pym/portage_checksum.py. These compute an MD5 checksum of a file, *undoing* any prelink that is done by the "prelink" command. Perhaps it's possible to use those functions in equery and qpkg? For checking the integrity of packages, it might be argued that changes due to prelink are relevant for some security-related queries. However, for queries of the form "do the currently installed files correspond to this package", changes due to prelink are not relevant. Therefore it might be appropriate for equery and qpkg to indicate that the binaries have been modified by prelinking, but they do still match the queried package. Finally, perform_checksum / perform_md5 simply undo the prelink and then compute the MD5. There is a slower operation written "prelink --verify --md5 BINARY_NAME" which undoes the prelink and then _redoes_ it, comparing the re-done prelink with the original file. This is slower, but is apparently relevant for security checking. Therefore, it might be worth thinking about whether to make that an option to equery / qpkg when doing a thorough security check. Note that verifying is quite a lot slower than just undoing, so it ought to be an option, not mandatory. Note that prelink preserves mtimes. Only the md5sums fail to match. Reproducible: Always Steps to Reproduce: 1. equery check pkgspec 2. qpkg -c pkgspec Actual Results: kushida ~ # qpkg -c coreutils sys-apps/coreutils-5.2.1-r2 * 85/229 kushida ~ # equery check coreutils [ Checking sys-apps/coreutils-5.2.1-r2 ] !!! /usr/bin/pr has incorrect md5sum !!! /bin/nice has incorrect md5sum !!! /bin/sleep has incorrect md5sum !!! /bin/basename has incorrect md5sum !!! /usr/bin/tail has incorrect md5sum !!! /bin/env has incorrect md5sum !!! /usr/bin/tsort has incorrect md5sum !!! /bin/comm has incorrect md5sum !!! /bin/du has incorrect md5sum !!! /bin/ls has incorrect md5sum !!! /usr/bin/paste has incorrect md5sum !!! /bin/df has incorrect md5sum !!! /bin/dd has incorrect md5sum !!! /usr/bin/od has incorrect md5sum !!! /bin/who has incorrect md5sum !!! /bin/cut has incorrect md5sum !!! /bin/install has incorrect md5sum !!! /bin/chroot has incorrect md5sum !!! /bin/tr has incorrect md5sum !!! /bin/link has incorrect md5sum !!! /bin/mknod has incorrect md5sum !!! /usr/bin/unexpand has incorrect md5sum !!! /bin/echo has incorrect md5sum !!! /bin/mv has incorrect md5sum !!! /bin/sort has incorrect md5sum !!! /usr/bin/fmt has incorrect md5sum !!! /bin/cat has incorrect md5sum !!! /bin/nohup has incorrect md5sum !!! /bin/chgrp has incorrect md5sum !!! /bin/stat has incorrect md5sum !!! /usr/bin/md5sum has incorrect md5sum !!! /bin/id has incorrect md5sum !!! /bin/uniq has incorrect md5sum !!! /bin/whoami has incorrect md5sum !!! /usr/bin/users has incorrect md5sum !!! /bin/tee has incorrect md5sum !!! /bin/hostid has incorrect md5sum !!! /bin/rmdir has incorrect md5sum !!! /bin/uname has incorrect md5sum !!! /bin/yes has incorrect md5sum !!! /usr/bin/csplit has incorrect md5sum !!! /bin/[ has incorrect md5sum !!! /usr/bin/tac has incorrect md5sum !!! /usr/bin/printf has incorrect md5sum !!! /bin/cp has incorrect md5sum !!! /bin/wc has incorrect md5sum !!! /bin/ln has incorrect md5sum !!! /usr/bin/fold has incorrect md5sum !!! /bin/printenv has incorrect md5sum !!! /usr/bin/factor has incorrect md5sum !!! /usr/bin/sum has incorrect md5sum !!! /bin/mkdir has incorrect md5sum !!! /bin/date has incorrect md5sum !!! /bin/mkfifo has incorrect md5sum !!! /bin/chmod has incorrect md5sum !!! /bin/tty has incorrect md5sum !!! /bin/split has incorrect md5sum !!! /usr/bin/expand has incorrect md5sum !!! /bin/touch has incorrect md5sum !!! /usr/bin/join has incorrect md5sum !!! /bin/ptx has incorrect md5sum !!! /bin/vdir has incorrect md5sum !!! /bin/false has incorrect md5sum !!! /usr/bin/pathchk has incorrect md5sum !!! /bin/expr has incorrect md5sum !!! /bin/logname has incorrect md5sum !!! /bin/unlink has incorrect md5sum !!! /usr/bin/nl has incorrect md5sum !!! /bin/seq has incorrect md5sum !!! /usr/bin/test has incorrect md5sum !!! /bin/true has incorrect md5sum !!! /bin/cksum has incorrect md5sum !!! /bin/stty has incorrect md5sum !!! /bin/rm has incorrect md5sum !!! /bin/dircolors has incorrect md5sum !!! /bin/sync has incorrect md5sum !!! /usr/bin/shred has incorrect md5sum !!! /bin/readlink has incorrect md5sum !!! /bin/dir has incorrect md5sum !!! /usr/bin/sha1sum has incorrect md5sum !!! /bin/chown has incorrect md5sum !!! /bin/pwd has incorrect md5sum !!! /bin/head has incorrect md5sum !!! /bin/dirname has incorrect md5sum !!! /usr/bin/pinky has incorrect md5sum * 144 out of 229 files good Expected Results: kushida ~ # qpkg -c coreutils sys-apps/coreutils-5.2.1-r2 * 0/229 (or something similar) kushida ~ # equery check coreutils [ Checking sys-apps/coreutils-5.2.1-r2 ] * 229 out of 229 files good
"prelink --verify --md5 BINARY_NAME" creates temporary files in the same directory as BINARY_NAME, so be cautious about using this option for security queries: those directories might be intentionally mounted read-only.
equery now uses perform_md5
Seems like this should be closed. I'll investigate.
I fixed a few more issues on this in equery, so that it now actually works. It will be part of the next Gentoolkit release. There may still be a few corner cases that we have not considered. I find it unlikely that we will spend time fixing qpkg to work with this, so I am closing this bug as fixed. If you disagree, repoen and explain me the error of my ways.
Why won't qpkg be fixed? Is it deprecated in favour of equery? I disagree only if qpkg is something users are expected to use. If it is deprecated and there a plans to get rid of it eventually, then I don't mind.
Yes, qpkg is deprecated and to be replaced with equery. We may want to provide a wrapper to equery that gives it more or less the same feel as qpkg, but it will be removed, hopefully in not that many weeks. Hence, I consider the matter closed for now.
