Stop Guessing Whether Debian Package Files Changed: Practical debsums for Integrity Checks

Anti-duplication note

What debsums actually checks

Install debsums

Fastest useful checks

Check one package

Only show problems

Check the whole system and list changed files

Understand the config-file default before you panic

Packages without checksum lists

A practical triage workflow

1) Check for changed package files

2) If needed, include config files

3) See which packages lack checksum metadata

4) Populate cache for missing packages

5) Re-run with generated checksums where possible

How to map a changed file back to a package

Safe repair: reinstall the affected package

Get changed files

Map them to package names

Reinstall those packages

debsums versus dpkg --verify

Use debsums when you want:

Use dpkg --verify when you want:

Important caveats you should not skip

1) This is not a full compromise detector

2) Changed config files are often normal

3) Some files may be unreadable to non-root users

4) Replaced files can be reported oddly

A small reusable audit script

When this is genuinely useful

References A package can be fully installed and still not be in the state you think it is. Maybe a file was edited by hand. Maybe a cleanup script went too far. Maybe you are checking a host after a rough shutdown, disk issue, or suspicious change and you want one simple answer: Did files shipped by Debian packages change on disk? On Debian and Debian-derived systems, debsums is one practical way to answer that. This guide shows how to: I rejected another vulnerability-management angle because the most recent live post already covered debsecan for CVE triage. This article is intentionally different. That makes this a package-integrity workflow, not a vulnerability workflow. According to the Debian man page, debsums verifies installed package files against MD5 checksum lists stored under: In other words, it compares files on disk with the checksums recorded for package contents. That is useful for spotting: It is not a full security guarantee. The man page is explicit that debsums is of limited use as a security tool and is mainly intended to find files modified locally or damaged by media errors. That distinction matters. Check that it is available: If one package is behaving strangely, start small. If everything is fine, you will usually get no alarming output. For triage, --silent is more practical because it suppresses healthy files and reports only errors. This is the command I would reach for during a quick host review: If nothing prints, that is usually a good sign. By default, debsums does not check configuration files. That is deliberate. Package-managed config files under /etc are often expected to differ from the package default. If you want to include config files too: If you want to check only configuration files: Use these intentionally. On a well-administered server, changed config files are often normal, not evidence of a problem. Some packages do not include an MD5 sums file. The man page provides a direct way to find them: That output does not automatically mean those packages are broken. It means debsums does not have checksum data available locally for them. The Debian man page also documents a practical recovery path if you want to generate checksums from cached .deb files: That downloads package archives into the APT cache so debsums can use them when needed. Then you can run a broader check using cached package archives where available: This is one of the most useful full-system integrity sweeps on a Debian host. If I were checking a Debian host after unexplained behavior, I would usually do it in this order. This gives you a much better signal than randomly diffing files under /usr and hoping you noticed the right thing. Suppose debsums -c prints something like this: Find the owning package with dpkg -S: Now you know which package to inspect or reinstall. The debsums man page includes a practical reinstall pipeline for changed files. A more readable step-by-step version is: Be careful with that last command: I would review the output first on anything important. Since dpkg 1.17.2, Debian also provides: The dpkg man page says --verify checks package integrity by comparing installed-file metadata against what is stored in the dpkg database. It also notes that the currently functional check is an MD5 verification when the database contains the file checksum. So when should you use which? In practice, I think debsums is the better teaching and triage tool because its workflow is clearer and its missing-checksum handling is more explicit. If you suspect a real intrusion, do not treat a clean debsums run as proof the system is safe. The Debian man page explicitly warns that debsums is of limited use as a security tool. Do not run debsums -ca on a server you actively manage and assume every hit is bad. Files under /etc are often meant to differ. The man page notes that some package files are not globally readable, so non-root runs can miss checks. If you want a meaningful whole-system audit, use sudo. The man page also notes that files replaced by another package may be reported as changed. So treat output as a triage signal, not a courtroom verdict. If you want a simple report you can keep around: Save it as debsums-audit.sh, make it executable, and run it when a host feels off: debsums earns its keep when: It is simple, old-school, and still handy. That combination tends to age well on Linux. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse