Verify Installed Debian Package Files with md5sums and dpkg

You will check whether files installed by a Debian package still match the MD5 digests recorded for that package. The workflow uses the installed dpkg package tools on this machine, version 1.22.6ubuntu6.6. Allow about ten minutes for one package, or longer if you need to investigate several failures. These checks read package metadata and file contents; they do not reinstall anything or change service state.

1. Understand what md5sums records

A binary Debian package can contain a control file named DEBIAN/md5sums. It has one line per ordinary package file: a 32-character hexadecimal MD5 digest, two spaces, then the file path. The path is written in the package's conventional root-relative form, such as usr/bin/dpkg, so the check must interpret it from the filesystem root.

This is an integrity and deduplication aid, not a security boundary. MD5 is unsuitable for proving authenticity or detecting a maliciously chosen replacement. Package signatures, trusted repository metadata and stronger hashes serve different purposes. A matching md5sum means only that the bytes match the recorded digest.

Since dpkg 1.16.3, if a binary package does not include this control file, dpkg can generate matching information when the package is unpacked. A missing list is therefore a package or metadata condition to investigate, not a reason to invent a new digest list by hand.

2. Locate the installed list

Replace PACKAGE_NAME with an installed package name. This lookup is unprivileged and changes nothing:

$ PACKAGE_NAME=dpkg
$ dpkg-query -W -f='${Status} ${Version}\n' "$PACKAGE_NAME"
install ok installed 1.22.6ubuntu6.6
$ list="/var/lib/dpkg/info/${PACKAGE_NAME}.md5sums"
$ test -r "$list" && printf 'readable: %s\n' "$list"
readable: /var/lib/dpkg/info/dpkg.md5sums

The exact version depends on your host. If the first command says that the package is not installed, stop there. If the list is absent, do not treat an empty result as a clean verification; use the package manager's own verification command in the next step and record that the local metadata is incomplete.

Checkpoint: inspect a few records before checking them. Do not edit the file.

$ sed -n '1,5p' "$list"
1c9124caa101c66a71237b0285acd7ac  usr/bin/dpkg
aed1ccb3ffb685897892e5e1b271da30  usr/bin/dpkg-deb
0668d2bbdce0e8a1fa9c74a77c5b0e6d  usr/bin/dpkg-divert
95f8fc9fde6969241b103937676d9ac1  usr/bin/dpkg-maintscript-helper
1700704852357c42016f0b3d3721c12d  usr/bin/dpkg-query

Those digest values are specific to the installed package version. Do not copy them into a different machine and call that a baseline.

3. Run the direct md5sum check

Run md5sum from /, because the records name paths relative to the installed filesystem tree:

$ cd /
$ md5sum -c --status /var/lib/dpkg/info/dpkg.md5sums
$ printf 'exit status: %s\n' "$?"
exit status: 0

With --status, a successful check is silent and returns status 0. A non-zero status means that at least one record could not be verified. To see the individual results, repeat without --status:

$ cd /
$ md5sum -c /var/lib/dpkg/info/dpkg.md5sums
/usr/bin/dpkg: OK
/usr/bin/dpkg-deb: OK
... 

The displayed list can be long, and the exact order follows the file. The useful signals are OK, FAILED, and messages for files that are missing or unreadable. Keep the command's exit status: a scroll of mostly successful lines does not make a failed check successful.

Do not run this from your home directory. A record such as usr/bin/dpkg would then be interpreted as ./usr/bin/dpkg, which produces misleading missing-file errors rather than checking /usr/bin/dpkg.

4. Use dpkg for the package-level result

dpkg --verify reads the file metadata stored in dpkg's database and checks the named package. It is usually the clearest first check because it handles the package selection for you:

$ dpkg --verify dpkg
$ printf 'exit status: %s\n' "$?"
exit status: 0

A clean run normally prints nothing. The command's documented output format is intended for paths that fail a check, so a line such as missing or a changed-file result deserves investigation. The database only checks files for which it has an MD5 record. A clean result does not prove that every package file, configuration file or runtime-generated file is covered.

To check every installed package, omit the package name. That can take longer and may report unrelated existing problems:

$ dpkg --verify
$ printf 'exit status: %s\n' "$?"
exit status: 0

Use the package-specific form first when you are troubleshooting one application. Elevated privileges are not normally needed for these reads. If your account cannot read a package's files or dpkg database, fix the access issue according to local policy rather than adding sudo automatically.

5. Classify a failure before changing anything

A failed digest has several possible causes: a legitimate administrator change, a package upgrade interrupted between files and metadata, filesystem corruption, a missing file, or unauthorised modification. First capture the affected path and package version. Then compare it with the package's intended contents from a trusted repository or the exact matching .deb. Do not overwrite the file merely because its MD5 differs.

For a missing or changed executable, record evidence before repair:

$ dpkg-query -W -f='${Package} ${Version}\n' dpkg
dpkg 1.22.6ubuntu6.6
$ stat /usr/bin/dpkg
$ dpkg --verify dpkg
$ printf 'verify status: %s\n' "$?"

If the file is security-sensitive, preserve the output and follow your incident or change process. These MD5 checks do not identify who changed a file, when it changed, or whether the recorded digest itself came from a trustworthy source.

6. Avoid destructive repair shortcuts

Do not delete a failing file, edit /var/lib/dpkg/info/*.md5sums, or regenerate a list just to make the next check pass. Those actions can destroy evidence or conceal the problem. There is no undo for deleting a file or replacing its baseline; restore from a known-good package or backup only after the cause and change approval are clear.

If the package is known to be damaged and a repair is authorised, use your normal package-management procedure and then rerun dpkg --verify PACKAGE_NAME. Reinstallation is a state-changing operation and may run package maintainer scripts, so schedule it appropriately and keep a rollback or recovery plan for the service involved.