chore(deps): bump the minor-and-patch group across 1 directory with 3 updates - #332
Open
dependabot[bot] wants to merge 1 commit into
Open
chore(deps): bump the minor-and-patch group across 1 directory with 3 updates#332dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
remyluslosius
added a commit
that referenced
this pull request
Jul 23, 2026
… bump, sync main Release prep for the staged-remediation branch (one-click merge once the RED gates clear): - VERSION 0.7.6 → 0.8.0 (frozen-api/ addition + behavior change + substantial capture/rollback work = the v0.8 major-position line per CLAUDE.md; founder to confirm the release-line number). - CHANGELOG Unreleased: completed with the cross-file conflict-guard fix and the exact-audit-matching (substring false-match) fix; noted the x/text bump. - Bumped golang.org/x/text v0.38.0 → v0.39.0 (GO-2026-5970, newly published; required to pass the govulncheck gate — not covered by dependabot #332). - Merged origin/main (13 commits) to bring the branch up to date (clean). go test ./... green, golangci-lint 0, specter 143/143, govulncheck clean. Still founder-gated: FMA ratification + two-human rollback review + OpenWatch `staged` mapping before its go.mod bump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
remyluslosius
added a commit
that referenced
this pull request
Jul 23, 2026
Newly-published vuln in x/text v0.38.0; required to pass the govulncheck gate. Not covered by dependabot #332 (its group still pins v0.38.0). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
remyluslosius
added a commit
that referenced
this pull request
Jul 23, 2026
* feat(cli): shell completion for all commands (bash, zsh, fish) Adds `kensa completion <bash|zsh|fish>`, emitting a static completion script that completes every subcommand and each subcommand's long flags, plus the global flags. The CLI is pflag-based (no cobra), so this is a hand-rolled generator driven by a single command/flag table (completionSpecs). - completion.go: the table + bash/zsh/fish generators + the `completion` subcommand (wired into the runCLI dispatch + top-level --help listing). - completion_test.go: a DRIFT-GUARD — for every command it runs `<cmd> --help`, extracts the advertised flags, and asserts they exactly match the table (fails the build if a flag is added to a command without updating the table, so completion can never silently omit a real flag). Also asserts every dispatch command is covered and each shell script names all commands+flags. Covers all 16 commands: detect, check, remediate, rollback, recover, history, plan, mechanisms, coverage, list, info, diff, agent, verify, migrate, version (+ completion itself). Bash completion functionally verified (che→check, `check --ho`→--host, `rollback --`→flags); zsh/fish scripts structurally validated (markers + all commands/flags present). Install: `kensa completion --help` prints per-shell source/install instructions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore(deps): bump golang.org/x/text to v0.39.0 (GO-2026-5970) Newly-published vuln in x/text v0.38.0; required to pass the govulncheck gate. Not covered by dependabot #332 (its group still pins v0.38.0). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dependabot
Bot
force-pushed
the
dependabot/go_modules/minor-and-patch-51698a0d21
branch
from
July 23, 2026 11:01
326c076 to
2c9c8a4
Compare
remyluslosius
added a commit
that referenced
this pull request
Jul 23, 2026
… StatusStaged) [RED — founder-gated] (#325) * feat(audit): stage audit_rule_set on immutable hosts instead of failing (StatusStaged) audit_rule_set could never complete on a STIG-hardened (immutable, enabled 2) RHEL host: the runtime load EPERMs, the engine's post-apply re-check fails, and the transaction rolls back to nothing. Since immutable audit is itself a STIG requirement, this blocked all 104 audit_rule_set rules on exactly the hosts under assessment. This adds a reboot-deferred "staged" outcome. - api: new TransactionStatus "staged" + StepResult.Staged + Staged event/StagedData - auditnl: AuditClient.GetStatus() (adapter over libaudit) to positively detect enabled 2 before attempting a load; fake models Enabled/AddErr - handler: on immutable, stage the persist layer (merge drop-in) and return Staged:true without loading (netlink GetStatus + shell auditctl -s) - engine: an apply step reporting Staged terminates StatusStaged WITHOUT the runtime re-check and WITHOUT rollback; signed+persisted like committed; HostUnchanged=false; neither CommittedAt nor RolledBackAt set - output: text + pdf remediation summaries count "staged" distinctly (not skipped) - specs: auditnl-rule-set C-06/AC-07; engine-transaction C-14/AC-25 Rollback is unchanged and byte-perfect (persist file fully captured; immutability guarantees runtime never diverged). --- FAILURE-MODE ANALYSIS (AI-DRAFT, pending founder ratification per RED gate) --- 1. What could this change do wrong in production? - A false-positive immutable detection would stage a rule on a MUTABLE host, leaving it non-compliant when it could have loaded. Mitigated: positive GetStatus/auditctl-s confirmation of enabled==2; a status-read error falls through to the normal load path (which surfaces AddRule EPERM as a failed step), never to a false stage. - A staged change that the operator never reboots leaves the host runtime-non-compliant indefinitely. Mitigated by honest reporting: scan stays fail, remediation terminal status is "staged" (not committed), OpenWatch must render "reboot required" (boundary change tracked). 2. Is captured state sufficient to fully restore on rollback? - Yes. On immutable the persist file is the ONLY mutated layer and Capture records it byte-perfect (base64 whole-file). Runtime is frozen (enabled 2), so it cannot diverge between capture and rollback. /etc/audit/audit.rules is a derived artifact regenerated from rules.d; not independently captured. 3. What edge case is this NOT safe for, is it documented + gated? - Default persist file 99-kensa.rules sorts after 99-finalize.rules (-e 2) so a staged rule there would not load even at reboot; latent (all 104 corpus rules set persist_file explicitly). Tracked as standalone finding F-1. - Remediating -e 2 before its siblings flips immutable mid-run (F-2). - Live atomicity proof on a mutable-audit host still required (hosts 213/247). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): carry StepResult.Staged over the wire + make staged txns rollback-able Two integration bugs caught by live agent-mode verification on the fleet (offline in-process fakes could not surface either): 1. WIRE DROP: StepResult.Staged was not in the agent wire protocol (WireStepResult). In agent mode Apply runs on the host and its StepResult is serialized back to the client engine — so the agent staged the file but the client received Staged=false, ran the runtime re-check, and rolled back. Result on immutable 211: "rolled_back" instead of "staged". Fixed: add `bool staged = 7` to wire.proto, regenerate wire.pb.go (codegen-drift gate green), carry it in both APIStepResultToWire / WireStepResultToAPI, and lock it with a round-trip bridge test case. 2. ROLLBACK EXCLUSION: staged transactions were absent from RollbackableSessions (WHERE txn_committed > 0) and CommittedTxnIDs (status = 'committed'), so a staged change — a real on-disk file with captured pre-state — could not be reverted via `kensa rollback`. Fixed: both queries now admit 'staged'. LIVE-VERIFIED (agent-mode remediate + rollback, byte-perfect sha): - 211 (RHEL 9.6, enabled 2): stage → status=staged, file written, runtime NOT loaded → rollback → file ABSENT (byte-perfect). - 213 (RHEL 9.8, enabled 1): remediate → committed, file + runtime watch loaded → rollback → ABSENT + unloaded (byte-perfect). Normal path unaffected. - 203 (RHEL 8.10, enabled 2): stage → REBOOT → watch LOADED at boot before -e 2 re-locked (convergence proven) → cleanup → clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): address adversarial-panel BLOCK — staged rollback, renderer, counters The 5-seat adversarial panel returned BLOCK with a confirmed BLOCKER + 3 must-fixes. All addressed: 1. [BLOCKER] Staged rollback called DeleteRule for rules the staged Apply never loaded; an immutable kernel rejects that unload with EPERM (211 only passed because its kernel returns the tolerated ENOENT — a single-host false positive). Fix: Capture is now immutable-aware (symmetric with Apply) — records no kernel-unload set and marks the pre-state immutable_staged; both rollback paths short-circuit to a success (drop-in removed, nothing was loaded) instead of a false PartialRestore. Regression test uses a realistic fake (Enabled=2 + DeleteErr=EPERM) that fails pre-fix. 2. [must-fix] Default console renderer showed a successful staging as red FAIL ("0 passed, 1 failed") — the buffered text/pdf writers were updated but the canonical stream renderer (scan.go/stream_scan.go) was not. Fix: progress.Update gains Staged; the renderer shows a distinct amber STAGED row + "N staged (reboot required)" tally. Live-confirmed on 211. 3. [must-fix] 'staged' was classified as txn_failed at three SQL counter sites (sessions.go FinishSession, sqlite.go post-rollback refresh, migrate.go backfill) — a class-incomplete sweep of the earlier rollback-able fix. Fix: exclude 'staged' from the failed bucket at all three, so a staged session is never reported "failed: N". (Per-txn --info already shows the staged status.) 4. [minor] Frozen-api additions had no CHANGELOG entry. Added an Unreleased section flagging the api additions + the required OpenWatch staged mapping. LIVE RE-VERIFIED on 211: remediate → "STAGED (reboot required)", rollback → succeeded 1/1, file ABSENT (byte-perfect). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): close panel re-run findings — ExecutePlan staged sweep + shell rollback consistency Second adversarial-panel pass (no BLOCKER; prior BLOCKER resolved). Fixes: 1. [Sweep Auditor, CONFIRMED — "fix one path, ship the sibling"] ExecutePlan (internal/engine/plan.go) is the SECOND apply→terminal path (public api.Kensa.ExecutePlan, consumed by OpenWatch) and lacked the anyStaged intercept that Run gained — a staged step there failed the re-check and mis-reported rolled_back. Added the same intercept. Test TestExecutePlan_Staged. 2. [Refuter, PLAUSIBLE] rollbackShell used a bare `&& augenrules --load` while the staged apply path uses `|| true`; on a kernel where augenrules exits non-zero on immutable, the !res.OK() guard would fire first and report a byte-perfect restore as rollback_failed, making the immutableStaged success branch dead code. Rollback now tolerates augenrules failure for the staged case exactly as apply does (committed rollback keeps bare `&&` so a genuine reload failure still surfaces). Live re-checked on 211 (shell path): STAGED → rollback succeeded → ABSENT. 3. [MINOR] Documented the anyStaged whole-transaction short-circuit's single-mechanism assumption (no corpus rule mixes mechanisms; tighten to a per-step verdict before authoring a mixed rule). Remaining is founder-gated: the frozen-api StatusStaged addition needs a minor semver decision + coordinated OpenWatch staged mapping (flagged in CHANGELOG); plus the FMA + two-human rollback review the Red gate requires. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): honest post-reboot staged-rollback verdict (panel pass-3 SHOULD-FIX) Adversarial-panel pass-3 (verdict ESCALATE, no blockers) found — and live testing on RHEL 8.10 CONFIRMED — a rollback-verdict honesty gap: rolling back a staged audit txn AFTER a reboot reported clean success while the running kernel still enforced the rolled-back rule. Mechanism: rollback trusted the CAPTURE-time immutable_staged flag, which is stale once the host reboots — auditd loads the persisted rule into the kernel and re-locks immutable, so the rule IS live and cannot be unloaded, yet the drop-in removal reported "no runtime rule was loaded". Fix (verdict from LIVE state, not the stale flag): - rollbackNetlink/rollbackShell: on a staged rollback, read the live ruleset (GetRules / auditctl -l) and report PartialRestore when the rule is still loaded (honest, mirrors the committed-immutable path); clean success only when genuinely absent. Never calls DeleteRule (immutable would EPERM). New helper auditRuleLoadedShell for the shell path. - cmd/kensa rollback --start: counted only errors, so a PartialRestore printed "succeeded". Now counts+surfaces a distinct "partial: N (disk reverted; running state clears on reboot)" line + per-txn warning. (Pre-existing gap for all handlers, surfaced by the staged path; RollbackResult.PartialRestore is carried over the wire already.) Regression test TestRollback_Netlink_StagedPostRebootReportsPartial (rule loaded at rollback → PartialRestore). LIVE-PROVEN on 203 (RHEL 8.10): stage → reboot (rule loads) → rollback now reports "succeeded: 0, partial: 1" + warning; disk ABSENT (byte-perfect); final reboot leaves the host clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): shell staged-rollback matcher handles syscall rules (panel pass-4) Panel pass-4 SHOULD-FIX: auditRuleLoadedShell did a whitespace-normalised full-line compare against `auditctl -l` with a comment claiming rules "print verbatim" — true for WATCH rules but FALSE for SYSCALL rules, which auditctl -l reorders/normalises (-k → -F key=, fields reordered). So a staged syscall rule loaded post-reboot was missed → rollback over-reported a clean restore instead of PartialRestore. The default agent/netlink path was already correct (containsWire against GetRules); this was shell-transport-only. Fix: export internal/check.AuditLineLoaded (the exact matcher the audit_rule_exists check uses — handles watch verbatim, syscall field-matching, -k/-F key= equivalence, syscall-set reordering, auid normalisation) and delegate to it from auditRuleLoadedShell. Regression test TestRollback_Shell_StagedSyscallPostRebootReportsPartial (canonical -k rule vs normalised -F key= in auditctl -l). LIVE-PROVEN on 203 (RHEL 8.10) with the SHIPPING binary (sha 616fc820): stage a SYSCALL rule via the shell path → reboot (loads as `-F key=`) → rollback reports "succeeded: 0, partial: 1" + warning; disk ABSENT byte-perfect; host left clean. NOTE: the first syscall live attempt reported a false "succeeded" — it ran a STALE ./bin/kensa (I did not `make build` after the fix). Rebuilding fixed it. The repo's stale-binary-live-test hazard recurred; always rebuild before live. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): surface staged count in rollback --list/--info (founder-caught) `rollback --info` showed "committed: 0 / 1 total" for a staged-only session with no staged line, so it read as "nothing to roll back" — even though rollback --start DOES process staged transactions (CommittedTxnIDs matches status IN ('committed','staged')). The query was staged-aware; the display was not. - rollback --list: new `staged` column - rollback --info: new `staged: N (reboot-pending; rollback-able)` line - JSON: listSessionRow gains txn_staged staged is derived (total - committed - rolled - failed; the only status excluded from all counters). Live-verified on 203: staged session shows "committed 0, staged 1"; rollback --start reports "attempted: 1". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): detect cross-file rule conflicts before writing (don't break the audit load) Root-caused on a live host: audit_rule_set's mergeRuleLines dedups only WITHIN the target drop-in, so remediating a rule whose audit action is already audited elsewhere (e.g. the audit-file-shadow `-k identity` watch on a host that already watches /etc/shadow under `-k audit_rules_usergroup_modification`, or the perm_mod syscall rule under the same key in a second file) silently wrote a second drop-in. The kernel dedups on the ACTION (watch path+perms; syscall signature), NOT the key, so both load → "Rule exists" → auditctl aborts the ruleset load → `-e 2` (last) never applies → the host boots MUTABLE. This actually dropped host 192.168.1.211 out of immutable state (confirmed + fixed). Fix — detect the conflict and gate, don't silently apply (the operator owns the resolution, per the ownership boundary): - check.AuditActionLoaded: key-AGNOSTIC matcher (watch path+perms; syscall fields) — "is this action already loaded under any key?" — distinct from the key-strict AuditLineLoaded used by the check itself. - audit_rule_set.guardConflict: before writing, if a rule line NEW to this drop-in has its action already in the live ruleset (`auditctl -l`), refuse with Success=false and a detail naming the existing rule; do NOT write the duplicate. Idempotent re-apply of the rule's own drop-in is not a conflict; an unreadable live ruleset never blocks a legitimate apply (best-effort). - scan.go: surface a handler's refusal detail in the remediate row (was bare "rolled_back"). - spec auditnl-rule-set C-07/AC-08; matcher + handler + absent-conflict tests. NOTE: this is NOT the corpus-level `--allow-conflicts` (which gates declared conflicts_with between rules at resolution time) — it is a new runtime state-conflict guard in the handler. LIVE-PROVEN on 211 (RHEL 9.6, immutable, /etc/shadow already watched): remediate audit-file-shadow now prints "conflict — action already audited as ...; would duplicate it and abort the audit load at reboot. Not applied", writes NO 50-identity.rules, and the host stays enabled 2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(audit): conflict guard scans rules.d files, not just the live ruleset (panel pass-5) Panel pass-5 SHOULD-FIX (same-session gap): guardConflict read only `auditctl -l` (the LIVE ruleset). On an immutable host, two staged rules writing the same audit action to different drop-ins in ONE remediate run both pass the guard (neither is loaded yet) and both load at the next reboot — augenrules "Rule exists" → the very immutability drop the guard exists to prevent. Fix: scan the on-disk rules.d FILES (what augenrules actually loads at reboot), not the live ruleset. This closes the same-session gap AND is strictly more robust — it also catches a pre-existing duplicate that is not currently loaded (e.g. on a host whose load already aborted). grep exit 1 (no rules) is not an error; a non-root/failed read still degrades to no-scan (best-effort, never blocks a legitimate apply). LIVE-PROVEN on 211 (RHEL 9.6, immutable): remediate audit-file-shadow still refuses with the naming conflict detail (now matched from audit_rules_usergroup_modification.rules on disk), writes no 50-identity.rules, host stays enabled 2. Panel note on the class-wide behavior change (audit_rule_set now refuses a rule whose action is already audited under a different key): the kernel-dedups-on- action-not-key premise is confirmed by the live 211 boot log ("Rule exists" for two different-key /etc/shadow watches). Refuse-over-brick is the intended, safer behavior; ratifying it (and confirming no in-corpus fleet host is newly reported unremediable) is a founder call, tracked on the PR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(check): exact audit field/key matching — stop path/auid/key prefix false-matches (cross-session panel BLOCKER) A concurrent session's adversarial panel found (empirically reproduced) that the audit matchers used strings.Contains (substring), not field equality. Effect, confirmed by test AND live on 211: - AuditLineLoaded (the COMPLIANCE CHECK): "-F path=/usr/bin/su" substring-matched a loaded "-F path=/usr/bin/sudo" (su ⊂ sudo) → the su control FALSE-PASSES on a host that only audits sudo. A false-COMPLIANT in the check itself — worse than the note framed, and the cardinal sin for a compliance tool. - AuditActionLoaded (the new conflict guard): same substring → falsely refuses a legitimate distinct rule (su) as "already audited" because sudo is loaded → su permanently unremediable. Generalizes to any path that is a prefix of another (also -k key prefixes and auid>=1000 ⊂ auid>=10000). Fix: exact field-token matching. arch/path/perm/exit compared via auditFieldEqual (whole "-F field=value" token, not substring); the -k key via extractAuditKey (now also parses the auditctl -l "key=" form) compared for equality; auid tokens via auditFieldPresent (whole whitespace-delimited field). This also corrects the pre-existing check's false-PASS, not just the new guard. Regression: TestAuditMatch_NoPrefixPathFalseMatch (su≠sudo for both matchers; exact su still matches; auid>=1000 ≠ auid>=10000). LIVE-VERIFIED on 211: a check for the non-audited /usr/bin/sud (prefix of audited /usr/bin/sudo) now correctly FAILs "rule line not loaded" (pre-fix it false-PASSed). go test ./... green, lint 0, specter 143. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore(release): prep #325 — VERSION 0.8.0, CHANGELOG, x/text security bump, sync main Release prep for the staged-remediation branch (one-click merge once the RED gates clear): - VERSION 0.7.6 → 0.8.0 (frozen-api/ addition + behavior change + substantial capture/rollback work = the v0.8 major-position line per CLAUDE.md; founder to confirm the release-line number). - CHANGELOG Unreleased: completed with the cross-file conflict-guard fix and the exact-audit-matching (substring false-match) fix; noted the x/text bump. - Bumped golang.org/x/text v0.38.0 → v0.39.0 (GO-2026-5970, newly published; required to pass the govulncheck gate — not covered by dependabot #332). - Merged origin/main (13 commits) to bring the branch up to date (clean). go test ./... green, golangci-lint 0, specter 143/143, govulncheck clean. Still founder-gated: FMA ratification + two-human rollback review + OpenWatch `staged` mapping before its go.mod bump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… updates Bumps the minor-and-patch group with 3 updates in the / directory: [golang.org/x/sys](https://github.com/golang/sys), [golang.org/x/term](https://github.com/golang/term) and [modernc.org/sqlite](https://gitlab.com/cznic/sqlite). Updates `golang.org/x/sys` from 0.46.0 to 0.47.0 - [Commits](golang/sys@v0.46.0...v0.47.0) Updates `golang.org/x/term` from 0.44.0 to 0.45.0 - [Commits](golang/term@v0.44.0...v0.45.0) Updates `modernc.org/sqlite` from 1.53.0 to 1.54.0 - [Changelog](https://gitlab.com/cznic/sqlite/blob/master/CHANGELOG.md) - [Commits](https://gitlab.com/cznic/sqlite/compare/v1.53.0...v1.54.0) --- updated-dependencies: - dependency-name: golang.org/x/sys dependency-version: 0.47.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: golang.org/x/term dependency-version: 0.45.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: modernc.org/sqlite dependency-version: 1.54.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/go_modules/minor-and-patch-51698a0d21
branch
from
July 27, 2026 09:24
2c9c8a4 to
2a7f32c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the minor-and-patch group with 3 updates in the / directory: golang.org/x/sys, golang.org/x/term and modernc.org/sqlite.
Updates
golang.org/x/sysfrom 0.46.0 to 0.47.0Commits
9e7e939cpu: handle vendor suffixes in parseReleasef6fb8a1unix: use epoll_pwait rather than epoll_waitf3eeabfwindows: avoid length overflow in NewNTString3cb6647unix: update glibc to 2.43c507910windows: document safe usage of TrusteeValueUpdates
golang.org/x/termfrom 0.44.0 to 0.45.0Commits
9f69229go.mod: update golang.org/x dependenciesUpdates
modernc.org/sqlitefrom 1.53.0 to 1.54.0Changelog
Sourced from modernc.org/sqlite's changelog.
... (truncated)
Commits
693ff38upgrade to SQLite 3.53.35d24346Merge branch 'texttotime-aggregates' into 'master'892d847sqlite: document _texttotime empty-decltype upgrade, widen #248 comment, add ...f2c8758sqlite: _texttotime best-effort parse for empty-decltype TEXT columns (#248)