DEV Community: EL E

Your check says PASS. It looked at zero files.

EL E — Sun, 27 Sep 2026 02:02:23 +0000

A verification step that finds nothing looks exactly like a verification step that
finds nothing wrong. Both print PASS. Both exit 0. Only one of them actually did
anything.

I shipped this bug three times in the same codebase before I understood the shape of it.

The bug

A scanner walked a directory and reported leaked secrets:

def main(paths):
    findings = []
    for root in paths:
        for f in glob.glob(root + "/**/*", recursive=True):
            findings += scan(f)
    print(f"files scanned: {len(seen)} | leaks: {len(findings)}")
    if findings:
        sys.exit(1)
    print("PASS")

It worked. For two months it printed PASS before every release.

Then I passed it a list of files instead of a directory. glob("some/file.mp4/**/*")
expands to nothing. Zero files scanned. Zero findings. PASS. Exit 0.

The caller was the release script. Every release for those two months had been
"verified" by a scanner that had looked at nothing at all.

Nothing errored. Nothing warned. The log line even told me the truth —
files scanned: 0 — and I had read past it every single time, because the word next
to it was PASS.

Why this class of bug survives

Most failures announce themselves. This one impersonates success.

Three properties make it durable:

The output is indistinguishable from the good case. A clean scan and a scan-of-nothing produce the same word.
It fails open. The guard is supposed to block. When it breaks, it stops blocking — which is silent by definition.
It gets more trusted over time. Every green run is evidence the check works. Two months of green is two months of accumulating false confidence.

That third one is the dangerous part. The longer it runs, the less anyone looks.

The fix is one line of policy, not one line of code

if scanned == 0:
    print("BLOCK: scanner matched zero files — refusing to report PASS")
    sys.exit(3)

A check that examined nothing must not be allowed to report success.

Note the distinct exit code. 1 means "found a problem". 3 means "could not do my
job". Those are different states and the caller should be able to tell them apart.
Collapsing them into "non-zero" throws away the one signal that would have caught this.

While I was there I added two more:

if missing_paths:
    print("BLOCK: path does not exist:", missing_paths)
    sys.exit(2)

print(f"[verify] files scanned: {scanned} | findings: {len(findings)}")

That last line runs on the success path. The happy path now has to state what it
looked at. If the number is zero, you see it at the moment you would otherwise be
reassured.

Where else this hides

Once you have the shape, you find it everywhere:

Check	Silent-zero failure
Test runner	Pattern matches no tests. "0 passed" is green in several runners.
Linter	Ignore file swallows the whole tree.
Backup verify	Compares a manifest that is itself empty.
Grep-based guard in CI	Typo in the pattern. Nothing matches. Gate opens.
Schema check	Config fails to parse, exception swallowed, empty dict validates fine.

That last one bit me too, separately: a JSON file written by PowerShell carried a
UTF-8 BOM. json.load(open(path, encoding="utf-8")) raised, the exception was
caught and turned into None, and a dashboard rendered an empty table instead of
an error. The table looked fine. It was just empty.

The fix there was encoding="utf-8-sig". The lesson was the same one: the failure
had a display mode that looked like a working system.

The rule I use now

When a check reports success, ask what it examined. If it cannot tell you a number,
it is not evidence.

Concretely, for anything that gates a release, a deploy, or a payment:

Print the denominator, not just the verdict.
Make "examined nothing" a distinct, failing state.
Use separate exit codes for "found a problem" and "could not run".
Write one regression test that feeds the checker an input matching nothing, and assert that it fails.

That last test is the one nobody writes. It is also the only one that would have
caught all three of my versions of this bug.

I packaged this as a tool

The guard above is four lines, but the rules around it (distinct exit codes, literal
paths that do not exist, counting from the check's own output) turned out to be worth
writing down once. It is one file, standard library only:

https://github.com/elwakeupman-shhh/zero-match-guard

# blocks instead of passing when the glob matched nothing
python zero_match_guard.py --paths "dist/**/*.js" -- npm run lint

It ships with the test nobody writes: feed the checker an input matching nothing, and
assert that it fails.

Why I care about this more than most

Almost everything I build is this kind of tool: a small script that watches something
and tells you whether it is fine. Health checks, integrity verification, log analysis,
scheduled monitors. The entire value of that category is that you stop looking, because
the script is looking for you.

Which means a monitor that lies is worse than no monitor. No monitor leaves you
uncertain, and uncertainty makes you check. A green dashboard makes you stop checking —
and then you find out two months later.

So now every one of my checks answers two questions instead of one:

Did you find a problem?
How many things did you look at?

I build single-file Python tools of exactly this kind: service and disk watchdogs,
integrity verification, log analysis, scheduled monitors. Zero third-party dependencies,
one file, meaningful exit codes — small enough that you can read the whole thing before
you trust it with anything. Available for hire on Fiverr.

Five single-file Python tools I actually run in production ops

EL E — Sat, 26 Sep 2026 09:47:24 +0000

Over years of doing infrastructure and security work, I kept writing the same
kind of thing: a single-file Python tool, no third-party dependencies, that does one
job well enough to drop into a cron job and forget about. No framework, no install
step, no virtualenv to maintain on a box you only SSH into twice a year.

Here are five of them, and — more importantly — the specific failure each one exists
to catch.

1. Disk and service health probe

The failure it catches: the two boring outages that actually take services down.
A data directory silently fills up until writes and database transactions start
failing, or a background process exits and nobody notices until a customer emails.

How it works: it takes a list of paths and a list of service/process names,
checks free-space percentage against a threshold and whether each process is alive,
prints a Markdown summary, and returns a non-zero exit code if anything breaches.
That exit code is the whole point — it makes the tool composable with any CI or cron
hook without writing glue.

python disk_service_probe.py \
  --paths C:/ D:/ E:/data \
  --services nginx postgres my-worker \
  --disk-threshold-percent 85 \
  --service-down-threshold 1

2. Directory SHA-256 integrity snapshot

The failure it catches: a config directory that drifts. Someone hotfixes a file
on the box during an incident, or a deploy half-applies, and three weeks later nobody
can say which files changed or when.

How it works: walk the tree, hash every file with SHA-256, serialise to a JSON
baseline. Later runs diff current state against that baseline and report added,
removed and modified files. No agent, no database, no daemon — the baseline is just
a file you can commit or archive.

# create the baseline
python dir_snapshot.py snapshot --dir ./configs --output baseline.json

# compare current state against it
python dir_snapshot.py verify --dir ./configs --snapshot baseline.json

The same idea, packaged properly with a hash chain so the record itself is
tamper-evident, is here:
offchain-integrity-verifier

3. USDT receipt verification gate

The failure it catches: trusting a webhook payload, or a screenshot, as proof
that a crypto payment arrived. Both are trivially forged, and by the time you find
out, you have already shipped.

How it works: it is a gate, not a notifier. It checks the claimed transfer
against public on-chain data — recipient address, confirmation depth, amount — and
emits a pass/fail verdict plus a tamper-evident receipt. Read-only: it never holds
a key and never sends a transaction.

python verify_cli.py --selftest

Source: usdt-receipt-verifier

4. Offline log analyser

The failure it catches: gigabytes of raw application log sitting on disk doing
nothing, because building a structured summary by hand with grep — error rates,
traffic troughs, repeated anomaly signatures — is tedious enough that nobody does it
until there is already an incident.

How it works: dependency-free parsing of common structured log formats,
frequency histograms bucketed by time, extraction of repeated anomaly signatures,
Markdown report out. Fully offline, so it is safe to point at logs you are not
allowed to ship to a third-party service.

python log_analyser.py /var/log/app/production.log --output report.md

5. Endpoint availability and latency check

The failure it catches: paying for an external monitoring SaaS to watch a handful
of internal endpoints — which means an account, an agent, an egress path, and alert
noise, for something you could answer in one command from inside the network.

How it works: feed it endpoints as plain text, CSV or JSON. It checks HTTP status
and round-trip time (optionally including transfer time), skips private IP ranges by
default as a safety guard, and writes a Markdown report. Any target failing gives you
a non-zero exit code.

python netcheck.py https://github.com https://cloudflare.com --timeout 5.0 --output netcheck.md

The pattern

Zero dependencies, single file, meaningful exit codes. That combination is what makes
these things survive: they run identically on staging and production, they need no
maintenance window to upgrade, and any of them can be read end to end in one sitting
before you trust it with anything.

Two of the five are published as proper open-source projects
(usdt-receipt-verifier,
offchain-integrity-verifier).
The other three are internal utilities — happy to share the approach if any of these
failure modes sound familiar; open an issue on either repo and I will answer there.

The tools themselves

All three are one file, standard library only, with a test you can run before you
trust them:

zero-match-guard — fail checks that examined nothing
usdt-receipt-verifier — verify USDT receipts offline
offchain-integrity-verifier — prove a report was not altered

Available for hire. I build this kind of tooling to order: ops automation, integrity
and verification tools, and content pipelines. Single file, zero third-party dependencies,
meaningful exit codes, and a test you can run yourself.
zerodeptools on Fiverr

Stop Trusting Screenshots: Verify Crypto Payments and Prove Your Reports Are Untouched

EL E — Fri, 04 Sep 2026 02:36:00 +0000

If you accept crypto (USDT-TRC20) for freelance or digital goods, you've probably been handed a "proof of payment" that was just a screenshot — editable, unverifiable, sometimes a fake TRC20 token.

Here are two open-source (MIT) tools I use to close that gap:

1. Verify the payment actually landed

usdt-receipt-verifier is read-only: give it your address + expected amount + min confirmations, and it checks the chain through a local Tor proxy (no real-IP leak), then writes a tamper-evident receipt. It issues no transaction and never sees your key.

2. Prove your deliverable report wasn't edited later

integrity-chain turns a report/attestation into a signed hash-chain. An independent verifier re-derives every link and flags tampering or "fake live" claims. Self-test shows honest chains PASS, tampered/fake-live FAIL.

Both are local-first, zero real IP, no keys.

Try it yourself — zero install, offline, no account

usdt-receipt-verifier — https://github.com/elwakeupman-shhh/usdt-receipt-verifier python usdt_receipt_verifier.py --selftest
integrity-chain — https://github.com/elwakeupman-shhh/offchain-integrity-verifier pip install -r requirements.txt then python verify_cli.py --selftest

Both exit 0 on honest data and non-zero on tampered/fake-live data — prove it yourself.

Contact: open a GitHub issue on either repo above.

The tools themselves

All three are one file, standard library only, with a test you can run before you
trust them:

zero-match-guard — fail checks that examined nothing
usdt-receipt-verifier — verify USDT receipts offline
offchain-integrity-verifier — prove a report was not altered