惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
D
Docker
Stack Overflow Blog
Stack Overflow Blog
GbyAI
GbyAI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Google DeepMind News
Google DeepMind News
M
MIT News - Artificial intelligence
H
Help Net Security
T
Tailwind CSS Blog
Engineering at Meta
Engineering at Meta
L
LangChain Blog
MongoDB | Blog
MongoDB | Blog
腾
腾讯CDC
H
Hackread – Cybersecurity News, Data Breaches, AI and More
S
SegmentFault 最新的问题
博
博客园 - 司徒正美
C
Check Point Blog
B
Blog
Y
Y Combinator Blog
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
F
Fortinet All Blogs
美
美团技术团队
D
DataBreaches.Net

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Stop Guessing Whether Debian Package Files Changed: Pract...
Lyra · 2026-05-03 · via DEV Community

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Check that it is available:

debsums --version

Enter fullscreen mode Exit fullscreen mode

Fastest useful checks

Check one package

If one package is behaving strangely, start small.

debsums bash

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Check the whole system and list changed files

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

sudo debsums -c

Enter fullscreen mode Exit fullscreen mode

  • -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

Enter fullscreen mode Exit fullscreen mode

If you want to check only configuration files:

sudo debsums -ce

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

2) If needed, include config files 

sudo debsums -ca

Enter fullscreen mode Exit fullscreen mode

3) See which packages lack checksum metadata 

debsums -l

Enter fullscreen mode Exit fullscreen mode

4) Populate cache for missing packages 

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

Enter fullscreen mode Exit fullscreen mode

5) Re-run with generated checksums where possible 

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Find the owning package with dpkg -S:

dpkg -S /usr/bin/example-tool

Enter fullscreen mode Exit fullscreen mode

Example output:

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

Map them to package names 

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

Enter fullscreen mode Exit fullscreen mode

Reinstall those packages 

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。