[community] Archcanary - AUR supply-chain scanner

muzqs · August 25, 2026, 9:03am

Hi all,

archcanary

Arch Linux security canary — layered AUR supply-chain scanner with systemd, eBPF, and kmod auditing.

From now on archcanary can be installed from aur repo.

If you have archcanary installed with ./install.sh --system
First do …

./install.sh uninstall --system

Then archcanary can be installed with

yay -S archcanary
archcanary --doctor

muzqs · August 26, 2026, 3:12pm

Latest update…

I removed the GUI for a bash menu. Nothing realy changes apart from skipping yad.

In short → The reason is piping output to a yad window is buggy.

🐤 archcanary
----------------------------------------------
 1) Full scan                        ✅
 2) Refresh + Full scan
 3) Individual checks
 4) Root checks                       [root]
 5) Lynis hardening report            [root]
 6) Run Lynis audit                   [root]
 7) Setup health check (--doctor)
 8) Search packages
 9) Manage allowlists
10) Edit config
11) Settings
12) About
 0) Quit

Choice:

The latest commits are not in the latest release. Those are false positives. Archcanaries own test on TOR.

Fix shipped in the next release… Or use ./install.sh --system again.

muzqs · September 2, 2026, 7:14am

Update:

Archcanary v0.1.33 released — full-AUR false-positive pass

archcanary v0.1.33 is now on the AUR (archcanary) and tagged in the repo.

Most of this release came out of running archcanary’s PKGBUILD checks (–check-pkgbuild, and the yay/paru pre-build hooks) against every live package on the AUR — roughly 111,000 PKGBUILDs. Thanks to Andreas Reichel, who ran the scan and sent back the full hit list on 25 Aug. That turned up two things: a couple of genuine detection gaps, and several patterns firing on entirely legitimate packages. The false positives were the priority — a few of them weren’t just noise, the yay hook was hard-blocking the install.

False positives fixed

ANSI colour output in printf. The hex/octal-escape check flagged any printf containing a \x or \0 escape, so a normal printf ‘\033[1m…’ bold/colour line tripped a WARNING on 246 AUR packages — and the yay hook aborted the build outright. It now only fires when an escape decodes to an actual command byte (a letter or digit), or when the printf output is piped into a shell.
The Chrome extension-ID line. echo $key | base64 -d | sha256sum | head -c32 | tr 0-9a-f a-p — the standard snippet in dozens of browser-extension -bin packages — was read as … | sh and flagged, again with a hard abort in the yay hook. Pipe-to-shell detection is now properly word-anchored: | sha256sum, | grep bash, | pacman -S bash no longer count; | sh, | bash, | sudo bash still do.
Commented-out lines. A trailing # sudo pacman -U --noconfirm ./pkg.tar.zst build note — common in hand-written PKGBUILDs — was matched as a real non-interactive pacman call (this was the EndeavourOS-forum timeshift report, against a years-old cached copy). Whole-line comments are now skipped by that check and several others (the aur@ self-propagation check, sudo/doas/pkexec, the MR/PR-patch check, base64-to-shell). 21 packages carrying a # push this + .SRCINFO to ssh://aur@… boilerplate comment are no longer flagged. Checks where a payload hidden in a comment is never legitimate — Tor/onion fetches, downloads into system paths, byte-assembled commands — still read comment text.
Overly broad new rules, calibrated down. The sudo-in-build()/package() check went from ~500 hits to 121 once it stopped counting .install scriptlets (already root) and sudo -u someuser steps. The mutable-patch-URL check went from ~320 to 46 once patch URLs carrying a real checksum — already pinned by makepkg’s own verification — were excluded.
One rule pulled. A pkgver-vs-source-URL version-mismatch check flagged 800+ packages at low precision (rolling heads/master tarballs, _pkgver/_commit URL variables, and versionless CDN links are all normal). Removed for now, parked for a rework in v0.1.34.

New detections

sudo / doas / pkexec inside a PKGBUILD’s build() or package(). makepkg runs those functions as your user, so shelling out through sudo writes onto the live system instead of into the package directory — e.g. tarah runs sudo cp … /usr/bin. .install scriptlets (meant to run as root) and sudo -u are not flagged.
An unchecksummed source= entry pointing at a forge merge-request or pull-request diff URL. That content can be force-pushed after you’ve reviewed it. A pinned hash, or a /commit/.patch URL, is fine and isn’t flagged. Example: freetype2-wps.

Both are in the yay hook too, as warnings rather than blocks.

Also

Some of the yay hook’s Lua pattern anchors were dead code — yay 13 runs the hook under gopher-lua, which doesn’t support the %f frontier pattern they used. Rewritten so they actually match, with a lint test to

yay -Syu archcanary
archcanary --doctor

rdtsc · September 2, 2026, 12:53pm

Weird… after uninstall and install via yay, archcanary --doctor runs fine, but archcanary with no args returns this:

me@mine ~ $ archcanary
/usr/bin/archcanary: line 1456: /home/me/.cache/archcanary/aur-check-20260902-084819.log: Permission denied
ERROR: Cannot write log file: /home/me/.cache/archcanary/aur-check-20260902-084819.log
me@mine ~ $

Seems like /home/me/.cache/archcanary is created with root ownership. It does have previous logs in it though, non-root.

sudo chown me:me /home/me/.cache/archcanary/ allows it to work.

Say, question… just noticed that pamac does not seem to use traur. Are we supposed to always be using yay instead? Too many package managers.

M0nst3r · September 3, 2026, 2:37am

Interesting. Could you please elaborate?

muzqs · September 3, 2026, 7:13am

The GUI was a yad window reading the scan output off a pipe. Piped output gets buffered, so the window looked frozen mid-scan and dumped everything at the end.

Add the colour codes, exit-code clashes and resize glitches to work around,
and it wasn’t worth it for a tool that’s CLI-first.

The bash menu just launches
the same commands straight in the terminal — nothing about the scans changed.

muzqs · September 3, 2026, 7:14am

Update:

Archcanary v0.1.33 released — full-AUR false-positive pass

archcanary v0.1.33 is now on the AUR (archcanary) and tagged in the repo.

Most of this release came out of running archcanary’s PKGBUILD checks (–check-pkgbuild, and the yay/paru pre-build hooks) against every live package on the AUR — roughly 111,000 PKGBUILDs. Thanks to Andreas Reichel, who ran the scan and sent back the full hit list on 25 Aug. That turned up two things: a couple of genuine detection gaps, and several patterns firing on entirely legitimate packages. The false positives were the priority — a few of them weren’t just noise, the yay hook was hard-blocking the install.

False positives fixed

ANSI colour output in printf. The hex/octal-escape check flagged any printf containing a \x or \0 escape, so a normal printf ‘\033[1m…’ bold/colour line tripped a WARNING on 246 AUR packages — and the yay hook aborted the build outright. It now only fires when an escape decodes to an actual command byte (a letter or digit), or when the printf output is piped into a shell.
The Chrome extension-ID line. echo $key | base64 -d | sha256sum | head -c32 | tr 0-9a-f a-p — the standard snippet in dozens of browser-extension -bin packages — was read as … | sh and flagged, again with a hard abort in the yay hook. Pipe-to-shell detection is now properly word-anchored: | sha256sum, | grep bash, | pacman -S bash no longer count; | sh, | bash, | sudo bash still do.
Commented-out lines. A trailing # sudo pacman -U --noconfirm ./pkg.tar.zst build note — common in hand-written PKGBUILDs — was matched as a real non-interactive pacman call (this was the EndeavourOS-forum timeshift report, against a years-old cached copy). Whole-line comments are now skipped by that check and several others (the aur@ self-propagation check, sudo/doas/pkexec, the MR/PR-patch check, base64-to-shell). 21 packages carrying a # push this + .SRCINFO to ssh://aur@… boilerplate comment are no longer flagged. Checks where a payload hidden in a comment is never legitimate — Tor/onion fetches, downloads into system paths, byte-assembled commands — still read comment text.
Overly broad new rules, calibrated down. The sudo-in-build()/package() check went from ~500 hits to 121 once it stopped counting .install scriptlets (already root) and sudo -u someuser steps. The mutable-patch-URL check went from ~320 to 46 once patch URLs carrying a real checksum — already pinned by makepkg’s own verification — were excluded.
One rule pulled. A pkgver-vs-source-URL version-mismatch check flagged 800+ packages at low precision (rolling heads/master tarballs, _pkgver/_commit URL variables, and versionless CDN links are all normal). Removed for now, parked for a rework in v0.1.34.

New detections

sudo / doas / pkexec inside a PKGBUILD’s build() or package(). makepkg runs those functions as your user, so shelling out through sudo writes onto the live system instead of into the package directory — e.g. tarah runs sudo cp … /usr/bin. .install scriptlets (meant to run as root) and sudo -u are not flagged.
An unchecksummed source= entry pointing at a forge merge-request or pull-request diff URL. That content can be force-pushed after you’ve reviewed it. A pinned hash, or a /commit/.patch URL, is fine and isn’t flagged. Example: freetype2-wps.

Both are in the yay hook too, as warnings rather than blocks.

Also

Some of the yay hook’s Lua pattern anchors were dead code — yay 13 runs the hook under gopher-lua, which doesn’t support the %f frontier pattern they used. Rewritten so they actually match, with a lint test to

yay -Syu archcanary
archcanary --doctor

rdtsc · September 10, 2026, 11:45am

Hi, currently archcanary always pauses, even when pkgbuild is clean:

==> ARCHCANARY: visual-studio-code-bin # ---------- PKGBUILD CHECKS CLEAN ---------- #
ARCHCANARY: verdict above -- press Enter to continue...

Would it be helpful if it only paused when something other than ‘clean’ was found?

muzqs · September 10, 2026, 3:01pm

v0.1.34 released

github.com/musqz/archcanary

CHANGELOG.md

master

# Changelog

## v0.1.34 (2026-09-10)

- Added: `check_pkgbuild_caches` Pattern 16 — a deceptive character in the **host** of a top-level `url=` or `source=` URL: a confusable Cyrillic/Greek/Armenian/fullwidth letter that renders like ASCII (`а` for `a`) but resolves to a host the attacker registered, or an invisible / reordering character (zero-width, bidi override, U+00AD, Tags block) hiding part of the host. Only the authority is checked — a non-ASCII byte in a URL path (`.../wiki/Программа`), in `pkgdesc`/`optdepends`/comments, or in an indented in-function `url=` is left alone, since non-Latin text there is legitimate. Byte-matched under `LC_ALL=C` with `grep -E`. Ported to the yay hook as a warning (`configs/yay-init.lua`, marker `(v15)`). Modeled on NeoArch's `security_scan.py`.
- Changed: `configs/yay-init.lua`'s `AURPostDownload` hook no longer pauses on a "press Enter to continue" prompt after a **clean** PKGBUILD scan — the `PKGBUILD CHECKS CLEAN` banner still prints and the build proceeds. The checkpoint now only fires on a warn verdict (privilege escalation, mutable patch source, aur-audit RED), where you actually have a decision to make; a block still aborts outright. Reported by a Mabox user for whom every clean install stopped for a keypress. Set `ARCHCANARY_PAUSE_ON_CLEAN = true` near the top of `init.lua` to pause on every scan instead — useful for large builds where even the clean banner scrolls off under compile spam before you can read it (the concern that first added the pause in v0.1.28). Marker bumped to `(v15)` (together with the Pattern 16 port above).
- Docs: dropped the held version/URL-mismatch rule from the `--check-pkgbuild` description (`README.md`, `man/archcanary.1`); it was removed from the code in v0.1.33. The reserved Pattern 16 slot is reused above.

## v0.1.33 (2026-09-02)

- Added: `check_pkgbuild_caches` gained two rules from Andreas Reichel's static-rules scan of all ~111,000 live AUR packages (2026-08-25). (1) `sudo`/`doas`/`pkexec` in a PKGBUILD's `build()`/`package()` — makepkg runs those as the calling user, so shelling through `sudo` writes outside `$pkgdir` onto the live system (`tarah` runs `sudo cp … /usr/bin`). PKGBUILD only (a `.install` scriptlet already runs as root); `sudo -u <user>` (run a step as another user) is not matched. (2) An **unchecksummed** `source=` entry on a forge merge-request/pull-request diff endpoint, whose content can be force-pushed after review (`freetype2-wps`). Sources and checksums are paired by array index the way aurscan's CHK-005 does it, so a real hash on that entry — or a `/commit/<sha>.patch` — means it's pinned and not flagged. Both are also ported to the yay hook (`configs/yay-init.lua`, marker `(v13)`), as warnings.
- Fix: `check_pkgbuild_caches`' non-interactive-`pacman` check (`--noconfirm` from a scriptlet) matched commented-out lines, so a trailing `# sudo pacman -U --noconfirm ./...` build reminder — common in hand-written PKGBUILDs — tripped a WARNING. Reported on the EndeavourOS forum against a stale `~/.cache/yay/timeshift/` tree (timeshift is in `extra`; the cached AUR copy was years old). That pattern now skips whole-line comments, as do the `aur@`, `sudo`/`doas`/`pkexec`, MR/PR-diff and base64-decode-to-shell (Pattern 2 + its yay-hook port) checks — `# install: … | base64 -d | sh` is a real maintainer note. Tor/onion-fetch, system-path-download and printf/rev-tr byte-assembly still scan comment text, since a payload URL or byte-spelled command staged there is never legitimate.
- Fix: two `check_pkgbuild_caches` false positives found in a full scan of all ~111,000 live AUR packages. (1) The printf hex/octal check flagged any `printf` carrying a `\x`/`\0` escape, so `printf '\033[1m…'` ANSI colour output tripped a WARNING (246 packages) — and the yay hook (`configs/yay-init.lua`) hard-*blocked* the install. It now needs an escape that decodes to a letter or digit (a command byte, not an ESC/CSI colour code), or a `printf` whose output is piped to a shell. (2) The `aur@aur.archlinux.org` self-propagation check now skips fully-commented lines — 21 packages carry a `# push this + .SRCINFO to ssh://aur@…` boilerplate note; a real `ssh aur@…` in code still flags.
- Fix: calibrated Patterns 14 and 15 against the same full-AUR scan. Pattern 14 (`sudo`) went from ~500 hits to 121: it was also flagging `.install` scriptlets (already root — a packaging smell, not a fakeroot escape) and counting `sudo -u` (run a step as another user). Pattern 15 (mutable patch URL) went from ~320 to 46: a PR-patch URL with a real checksum is pinned by makepkg's own verification, so it's no longer flagged. The version/URL-mismatch rule from the earlier `(v11)` work is held back for a rework — on the full scan it flagged 800+ packages (rolling `heads/master` tarballs, `$_pkgver`/`$_commit` URL variables, versionless CDN sources) at low precision.
- Fix: the base64/rev-tr/printf pipe-to-shell patterns (2, 4, 7) and their yay-hook ports read `|

This file has been truncated. show original

yay -Syu archcanary
archcanary --doctor

The yay init.lua press to proceed for canary had a function for me in the beginning.
But I agree for clean it does not need to stop. The log still shows the output though.

Thanks

muzqs · September 13, 2026, 7:25am

Update: v0.1.35

github.com/musqz/archcanary

CHANGELOG.md

master

# Changelog

## v0.1.35 (2026-09-13)

- Added: `glanced`, `tokentracker-cli`, `tokentracker-bin`, and `claude-config-bin` to `lists/community_reports.txt` — all four published by the same AUR account, deleted by an AUR admin on 2026-09-12 for confirmed malicious upstream code. `glanced`'s upstream (`ayan-de/glance-linux`) shipped obfuscated JS disguised as a `.woff2` font file, auto-executed via a `.vscode/tasks.json` `runOn:folderOpen` task, resolving a 2nd-stage RAT through an Ethereum blockchain transaction lookup used as a C2 channel. Reported on `aur-general` by Saren and Nicolas Boichat.
- Added: `--allowlist-{list,add,remove}=package:NAME` — a 5th system-wide allowlist (`/etc/archcanary/package_allowlist.conf`, seeded by both `install.sh --system` and the AUR `PKGBUILD`), applied in checks [1]/[2] (currently-installed packages and pacman.log history). `package_list.txt` and the other threat lists are pure name-match lists with no way to tell a genuine hit apart from a name collision the user has manually verified clean (AUR git history + locally cached PKGBUILD both show no trace of the campaign's malicious commit) — until now the only fix was editing the fetched list file directly, which the next `--refresh` silently reverted. Prompted by a live false-positive: `chipmunk` (the Chipmunk2D physics library) matched `package_list.txt`'s June 2026 AUR-incident list by name only; its actual cached PKGBUILD was the clean, unrelated upstream build. Both checks' WARNING output now hints at `--allowlist-add=package:NAME` inline, matching the existing DKMS/systemd/bpftool/autostart allowlists. Also added to `archcanary-tui`'s "Manage allowlists" menu alongside the other four.
- Fix: the new package allowlist above shipped in the initial PR without two of its three install paths — the AUR `PKGBUILD`'s `package()` never seeded `/etc/archcanary/package_allowlist.conf` (nor listed it in `backup=()`), and `archcanary-tui`'s allowlist menu still only offered the original four. Caught before release, not after — the exact same class of gap as v0.1.31's `archcanary-tui` packaging miss.

## v0.1.34 (2026-09-10)

- Added: `check_pkgbuild_caches` Pattern 16 — a deceptive character in the **host** of a top-level `url=` or `source=` URL: a confusable Cyrillic/Greek/Armenian/fullwidth letter that renders like ASCII (`а` for `a`) but resolves to a host the attacker registered, or an invisible / reordering character (zero-width, bidi override, U+00AD, Tags block) hiding part of the host. Only the authority is checked — a non-ASCII byte in a URL path (`.../wiki/Программа`), in `pkgdesc`/`optdepends`/comments, or in an indented in-function `url=` is left alone, since non-Latin text there is legitimate. Byte-matched under `LC_ALL=C` with `grep -E`. Ported to the yay hook as a warning (`configs/yay-init.lua`, marker `(v15)`). Modeled on NeoArch's `security_scan.py`.
- Changed: `configs/yay-init.lua`'s `AURPostDownload` hook no longer pauses on a "press Enter to continue" prompt after a **clean** PKGBUILD scan — the `PKGBUILD CHECKS CLEAN` banner still prints and the build proceeds. The checkpoint now only fires on a warn verdict (privilege escalation, mutable patch source, aur-audit RED), where you actually have a decision to make; a block still aborts outright. Reported by a Mabox user for whom every clean install stopped for a keypress. Set `ARCHCANARY_PAUSE_ON_CLEAN = true` near the top of `init.lua` to pause on every scan instead — useful for large builds where even the clean banner scrolls off under compile spam before you can read it (the concern that first added the pause in v0.1.28). Marker bumped to `(v15)` (together with the Pattern 16 port above).
- Docs: dropped the held version/URL-mismatch rule from the `--check-pkgbuild` description (`README.md`, `man/archcanary.1`); it was removed from the code in v0.1.33. The reserved Pattern 16 slot is reused above.

## v0.1.33 (2026-09-02)

- Added: `check_pkgbuild_caches` gained two rules from Andreas Reichel's static-rules scan of all ~111,000 live AUR packages (2026-08-25). (1) `sudo`/`doas`/`pkexec` in a PKGBUILD's `build()`/`package()` — makepkg runs those as the calling user, so shelling through `sudo` writes outside `$pkgdir` onto the live system (`tarah` runs `sudo cp … /usr/bin`). PKGBUILD only (a `.install` scriptlet already runs as root); `sudo -u <user>` (run a step as another user) is not matched. (2) An **unchecksummed** `source=` entry on a forge merge-request/pull-request diff endpoint, whose content can be force-pushed after review (`freetype2-wps`). Sources and checksums are paired by array index the way aurscan's CHK-005 does it, so a real hash on that entry — or a `/commit/<sha>.patch` — means it's pinned and not flagged. Both are also ported to the yay hook (`configs/yay-init.lua`, marker `(v13)`), as warnings.
- Fix: `check_pkgbuild_caches`' non-interactive-`pacman` check (`--noconfirm` from a scriptlet) matched commented-out lines, so a trailing `# sudo pa

This file has been truncated. show original

muzqs · September 16, 2026, 6:39am

Update release v0.1.37

github.com/musqz/archcanary

CHANGELOG.md

master

# Changelog

## v0.1.37 (2026-09-16)

- Changed: relicensed as GPL-3.0. The README's "no warranty" line was never a license grant, so the project legally defaulted to all-rights-reserved — worse than source-available. Adds the canonical GPLv3 text as `LICENSE` (installed by the package), fixes `packaging/PKGBUILD`'s `license=` field (was incorrectly `'MIT'`, using the SPDX `GPL-3.0-only` form to match current Arch convention), and adds `SPDX-License-Identifier: GPL-3.0-only` headers to archcanary's own scripts (`sources/*.sh`, reference copies of other people's mailing-list scripts, are deliberately left unmarked). Reported on the EndeavourOS forum. The AUR `PKGBUILD` already got a metadata-only `license=` sync (`0.1.36-2`); the actual `LICENSE` file ships with this release.
- Fix: `--doctor`'s bash-completion-drift warning suggested `bash install.sh # (cd to the archcanary repo first)` as the fix — a dead end for AUR installs, which never leave a repo clone behind. The correct bytes are already sitting at the system completion path, so the fix now copies them directly (`install -Dm644`) instead.
- Added: `check_pkgbuild_caches` Pattern 17 — a `.install` scriptlet that plants or escalates a login path: `usermod`/`gpasswd` adding a user to `wheel`, a `NOPASSWD` sudoers edit, or a hardcoded password piped into `chpasswd`/`passwd`. `.install`-only — `package()` runs under fakeroot, so a real PKGBUILD escape needs `sudo`, already caught by Pattern 14. Modeled on a real 2026-09-14 `aur-general` incident (`x11-qemu-validation`): a compromised maintainer's scriptlet created a user with a hardcoded password, added it to `wheel`, and enabled `sshd` with password auth for instant root-equivalent remote access. Reported by Saren; the AUR admin suspended the account and removed the package the same day.
- Added: ported Pattern 17 (above) to the yay hook (`configs/yay-init.lua`, marker `(v16)`), as a warning. Unlike every other port in that file, yay's Lua API hands the hook only the PKGBUILD's own text — no `.install` field — so this one reads the `.install` file straight off disk via `event.data.dir` and the PKGBUILD's own `install=` line, the same file `--check-pkgbuild` itself would read.
- Fix: check [2] (`check_logs`) tagged a still-installed package as `LOG_HIST` — "no longer installed... potential past exposure" — whenever it dropped out of check [1]'s `pacman -Qmq` (foreign-only) lookup, which also happens when a formerly-AUR package graduates into a repo, not just when it's actually removed. `check_current` now also runs one extra batched `pacman -Qq` lookup (`CURRENTLY_INSTALLED_ANY_MAP`, no per-package subprocess) so `check_logs` can tell the two apart: a package that's still installed but no longer foreign gets a new `LOG_MIGRATED` tag with corrected wording instead of the "removed" framing. Deliberately keeps `LOG_HIST`'s exact severity (still bumps `EXIT_CODE`/`_log_ret` to 1) rather than clearing it — "no longer foreign" only means *some* configured repo now owns the name, official or third-party, which is not proof the match is safe; a caught-in-review draft of this fix downgraded it to a zero-severity "not an active risk" INFO note instead, which would have silently cleared a genuine CHAOS-RAT/aur-audit-black match the moment it stopped looking foreign. Unlike `LOG_HIST`, `LOG_MIGRATED` isn't deduped via the `log_hist_seen.txt`/`LOG_HIST_SEEN` mechanism — it's an ongoing current-install fact each scan (like `LOG_HIT`), not a one-time historical event, and sharing that dedup keyspace risked cross-contaminating the two tags on reinstall/removal. Reported on the EndeavourOS forum: `asusctl`/`rog-control-center` moved from the AUR into `extra`, and archcanary kept citing their old AUR install history as a past exposure.

## v0.1.36 (2026-09-14)

- Fix: `--doctor`'s system-install check never got a `package allowlist` entry alongside the DKMS/systemd/bpftool/autostart ones, so a missing `/etc/archcanary/package_allowlist.conf` went unreported. Another instance of the same packaging-surfaces-drift class as the PKGBUILD/`archcanary-tui` gaps fixed in v0.1.35. (Like its 4 siblings, this check only tests existence, not readability — an unreadable-but-present file still shows `[ OK ]` even though checks [1]/[2] silently skip it; a pre-existing gap, not addressed here.)
- Added: `--start-date`/`--end-date` now also narrow check [7] (`check_pkgbuild_caches`) to cached PKGBUILD/.install files whose mtime falls in the window — roughly when the AUR helper actually built/cached that package. Previously the window only applied to checks [1]/[2] (currently-installed packages and pacman.log history); this lets the same "what did I touch during this campaign's active window" question be asked of cached PKGBUILDs too. No window set (the default) scans exactly as before.
- Fix: `--start-date`/`--end-date` are now validated to strict `YYYY-MM-DD` at parse time. Previously a malformed or unpadded value reached checks [1]/[2]/[

This file has been truncated. show original