Wardlatch
Does the wrong key still turn?
When a certificate authority's keys leak, browsers update within hours. The rest of your machine doesn't. curl, Node,
Python and every project's own certificate bundle each keep their own list of who to trust, and each has to be fixed
on its own. Wardlatch tells you which ones still trust the compromised keys, and checks this week's other leaks too.
npx wardlatch@latest
Run it from your home folder (cd ~ first), not from inside a project: npx also starts Wardlatch with the current
project's own node_modules/.bin/node if it has one, and applies its .npmrc; Wardlatch can't undo either. Use @latest: a bare npx wardlatch runs any copy already installed globally or in the current project, whatever its version (and npm older than 9.6.5 also reuses a copy npx cached earlier). If you installed Wardlatch, update that copy too (npm install -g wardlatch@latest for a global copy, npm install wardlatch@latest in the project), or remove it. wardlatch --help prints the version without running any check.
Runs on macOS and Linux, tested on both in CI. Windows is not supported yet: some checks don't look in Windows
locations, so a Windows run can miss what it should find. The trust check and the program checks say UNKNOWN there.
SAFE node 26.12.0 /opt/homebrew/bin/node
EXPOSED node 26.12.0 /usr/local/bin/node trusts 6/12
fix: update Node.js to 26.12.1, 24.22.1 or 22.23.4 or later ...
SAFE curl 8.7.1 /usr/bin/curl
SAFE certifi 2026.10.19 ~/Development/app/.venv
11 safe · 1 exposed · 0 could not be tested
How it works
It doesn't compare version numbers. It asks each runtime to open a real, verified TLS connection to public test hosts
whose certificates are signed with the compromised keys, the way your own code would, with your own trust settings
(CA files, proxies; a setting that would load code into the test, such as NODE_OPTIONS --require, is not passed, and
the run says so in an UNKNOWN line).
If a runtime connects, it still trusts them. Two exceptions keep it from running what it checks: Python is started
with -I -S, so a .pth file or sitecustomize.py that changes its trust (pip-system-certs, for example) is not
applied, and, as before, the certifi in the own site-packages of a Python on your PATH is not tested yet (a
virtual environment's is); and every program runs from /, so a version manager picks your default, not the current project's.
Two checks keep the answer honest:
- Is the test host up? Each host is first reached with verification off. If none answers, the result is
could not be tested, never safe.
- Could this check have failed? Each runtime is first run once per compromised root, with only that root forced in,
against a test host chained to it. If it can't connect even then, the probe can't see exposure on that runtime, and
the result is could not be tested, never safe. So is a root none of whose test hosts answered.
What it looks at
- the first
node, curl and python3 on your PATH, the ones your shell runs, and any later copy that is a compiled
program (a later copy that is a script is named, not run; node_modules/.bin folders and relative entries are
dropped first, so a project can't have Wardlatch run its programs), plus the operating system's own trust: macOS's
networking stack (Safari and Apple's apps) and, on Linux, the distribution's CA bundle (tested with curl; with no curl, python3 tests it, and with neither it is UNKNOWN)
- the bundle
REQUESTS_CA_BUNDLE names, which requests and pip use in place of certifi (tested with curl)
- pip's own CA list (
pip/_vendor/certifi/cacert.pem: older pips, or on Python 3.9 or older, use it for every download;
pip 24.2 and later on Python 3.10 or later only with --use-deprecated=legacy-certs) in the machine's
Python folders, and the certifi inside apps' own Pythons (Blender, Unity's Emscripten Python), read as files, by key:
a REVIEW line for each that still holds a withdrawn root
- on a Mac with Apple's update (macOS 27.2.1, 26.7.3, 15.8.3 or later), every copy of
cert.pem left in /etc/ssl:
a REVIEW line for each that still holds a withdrawn root, because Apple says not to restore one
- Python virtual environments (and their
certifi) under ~/Development, ~/code, ~/src, ~/projects, ~/Projects,
~/dev, ~/work, ~/Sites, /var/www, /srv/www and /Library/WebServer/Documents, or the folders you give with --paths.
A bundle is tested with curl only where that curl keeps to the CA file it is given; Apple's doesn't (it falls back to
the system's trust, curl issue #12604, 2023), so on a Mac the bundle is read as a file and judged by key
- every running Docker or Podman container, checked from inside with the image's own curl, python3 or wget. Two
controls come first: a normal site must open, and a self-signed one must be refused, or the result is "couldn't
test".
--no-containers skips them. Nothing is written into a container.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
