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

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:

• install and use debsums
• check one package or the whole system
• include or exclude config files intentionally
• deal with packages that do not ship MD5 checksum lists
• repair changed package-managed files safely
• understand where debsums helps and where it does not

Anti-duplication note

I rejected another vulnerability-management angle because the most recent live post already covered debsecan for CVE triage. This article is intentionally different.

• debsecan asks: which installed packages are known vulnerable?
• debsums asks: did the files installed by a package change?

That makes this a package-integrity workflow, not a vulnerability workflow.

What debsums actually checks

According to the Debian man page, debsums verifies installed package files against MD5 checksum lists stored under:

/var/lib/dpkg/info/*.md5sums

In other words, it compares files on disk with the checksums recorded for package contents.

That is useful for spotting:

• locally modified package files
• missing package files
• some kinds of corruption or drift

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.

Install debsums

On Debian or Ubuntu:

sudo apt-get update
sudo apt-get install debsums

Check that it is available:

debsums --version

Fastest useful checks

Check one package

If one package is behaving strangely, start small.

debsums bash

If everything is fine, you will usually get no alarming output.

Only show problems

For triage, --silent is more practical because it suppresses healthy files and reports only errors.

debsums --silent bash

Check the whole system and list changed files

This is the command I would reach for during a quick host review:

sudo debsums -c

• -c means --changed
• it reports changed files
• it implies -s, so you only get problem output

If nothing prints, that is usually a good sign.

Understand the config-file default before you panic

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:

sudo debsums -ca

If you want to check only configuration files:

sudo debsums -ce

Use these intentionally. On a well-administered server, changed config files are often normal, not evidence of a problem.

Packages without checksum lists

Some packages do not include an MD5 sums file. The man page provides a direct way to find them:

debsums -l

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:

sudo apt-get --reinstall -d install $(debsums -l)

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:

sudo debsums -cagp /var/cache/apt/archives

Breakdown:

• -c shows changed files
• -a includes config files
• -g generates checksums for packages missing them
• -p /var/cache/apt/archives tells debsums where to find cached .deb files

This is one of the most useful full-system integrity sweeps on a Debian host.

A practical triage workflow

If I were checking a Debian host after unexplained behavior, I would usually do it in this order.

1) Check for changed package files

sudo debsums -c

2) If needed, include config files

sudo debsums -ca

3) See which packages lack checksum metadata

debsums -l

4) Populate cache for missing packages

sudo apt-get --reinstall -d install $(debsums -l)

5) Re-run with generated checksums where possible

sudo debsums -cagp /var/cache/apt/archives

This gives you a much better signal than randomly diffing files under /usr and hoping you noticed the right thing.

How to map a changed file back to a package

Suppose debsums -c prints something like this:

/usr/bin/example-tool

Find the owning package with dpkg -S:

dpkg -S /usr/bin/example-tool

Example output:

example-package: /usr/bin/example-tool

Now you know which package to inspect or reinstall.

Safe repair: reinstall the affected package

The debsums man page includes a practical reinstall pipeline for changed files. A more readable step-by-step version is:

Get changed files

sudo debsums -c

Map them to package names

dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u

Reinstall those packages

sudo apt-get install --reinstall $(dpkg -S $(sudo debsums -c) | cut -d: -f1 | sort -u)

Be careful with that last command:

• it is practical for restoring package-managed files
• it does not mean every changed file should be overwritten blindly
• if the change was intentional, a reinstall may undo useful local work

I would review the output first on anything important.

debsums versus dpkg --verify

Since dpkg 1.17.2, Debian also provides:

sudo dpkg --verify

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?

Use debsums when you want:

• a purpose-built package-file checksum tool
• --changed output that is easy to act on
• config-file-only or config-file-inclusive checks
• checksum generation for packages missing local sums, using cached .deb archives

Use dpkg --verify when you want:

• a built-in dpkg integrity check
• a quick verification pass without installing another tool

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.

Important caveats you should not skip

1) This is not a full compromise detector

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.

2) Changed config files are often normal

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.

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

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.

4) Replaced files can be reported oddly

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.

A small reusable audit script

If you want a simple report you can keep around:

#!/usr/bin/env bash
set -euo pipefail

echo "== debsums changed package files =="
sudo debsums -c || true

echo
echo "== debsums changed package + config files =="
sudo debsums -ca || true

echo
echo "== packages missing checksum lists =="
debsums -l || true

Save it as debsums-audit.sh, make it executable, and run it when a host feels off:

chmod +x debsums-audit.sh
./debsums-audit.sh

When this is genuinely useful

debsums earns its keep when:

• a Debian host is acting strangely after manual changes
• you want to verify package-managed files before blaming the application
• you need a quick integrity pass after disk trouble or an unclean shutdown
• you are documenting a repeatable baseline-check workflow for Debian systems

It is simple, old-school, and still handy.

That combination tends to age well on Linux.

References

• Debian man page, debsums(1): https://manpages.debian.org/testing/debsums/debsums.1.en.html
• Debian man page, dpkg(1): https://manpages.debian.org/testing/dpkg/dpkg.1.en.html
• Dev.to live post reference used for anti-duplication check: https://dev.to/api/articles?username=lyraalishaikh&per_page=10&page=1