Chainfire (@Chainfire) privately reported the passwordless asdcontrol watchdog reboot on August 25, 2026.
The fix landed in the 4.0.2 security work: #9200 (df819a6f) removed Omarchy's unrestricted sudo grant, while omacom/omarchy-pkgs#242 and omacom/omarchy-pkgs#243 restricted the package's grant. This records the reporter credit omitted from those changes.
Reported-by: Chainfire (https://github.com/Chainfire)
Thanks to _SiCk // afflicted.sh for independently reproducing the passwordless sudo persistence issue and reviewing the proposed fix in #7990. The follow-up fix landed in #9387 (945af75a), with the 4.0.3 backport in cf459ba7.
The original boot-cleanup patch was contributed by @Adolanium. Preserve that co-author credit alongside this acknowledgment.
Co-authored-by: Adolanium <94890352+Adolanium@users.noreply.github.com>
Arch removed the prebuilt broadcom-wl package on 2026-09-02 and rebuilt
broadcom-wl-dkms with replaces=(broadcom-wl). A replaces entry only helps
upgrades of an already-installed package, so the name is now unresolvable
as an explicit pacman target and the ISO offline mirror download fails
with "target not found: broadcom-wl".
broadcom-wl-dkms depends on dkms, so the explicit dkms in the hardware fix
is redundant; linux-headers stays because the module has to build against
the running kernel.
T3 Code reads themes an environment publishes into its state directory, so
a generated t3code.json carries the palette the same way claude.json and
vscode-theme.json already do, and omarchy-theme-set-t3code republishes it
on every theme change for the app to pick up live.
The template overrides only the roles a theme actually designs -- terminal
and code surfaces, text on canvas, borders, selection -- and leaves muted
text, placeholders, and status foregrounds to T3 Code, which contrast-solves
them against whatever canvas it is given. Overriding those directly cost
readability on light themes: White fell to 1.0:1 on placeholder text.
Installing from the menu now routes through omarchy-install-ai-t3-code so a
fresh install publishes the current palette and opens wearing it.
The old setup command enabled sshd before importing a key, so an aborted
run left a password-only server exposed. Skipping that machine kept the
hole Omarchy opened; close it instead by disabling sshd. Omarchy is a
desktop distro, so the console remains, and the warning explains how to
set up key-based access or deliberately re-enable password logins.
With the stakes flipped from skip to disable, "no usable key" must not
false-positive: follow an authorized_keys symlink to its key (dotfiles
setups have working key auth), and treat an unreadable file as
unverifiable rather than keyless.
Amends the unreleased 1788124236 migration in place; no released install
has run it, so every machine still gets the new behavior in one pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Validate authorized_keys line by line with the question sshd actually
asks: ssh-keygen -lf on the whole file also fingerprints a private key
copied there by mistake, which sshd cannot use, so the migration would
have disabled the only working login path.
Tighten ~/.ssh and authorized_keys the way omarchy-setup-security-sshd
does, and back off from a group-writable home directory: StrictModes
makes sshd ignore the key either way, with the same lockout.
Complete with a notice instead of failing on conditions the migration
cannot repair (a broken or pre-Include sshd_config, an overriding admin
rule, a failed reload of a valid config), so those machines keep passwords
as they were without blocking every migration queued behind this one.
Only missing privileges stay pending, since a terminal rerun fixes that.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Without a terminal sudo keys its cached credential on the parent
process of each call, so the timestamp validated by sudo -S -v in the
test shell never reached omarchy-setup-security-sshd's own sudo calls
when omarchy-iso-test drove the suite over ssh with no pty, and the
exercise died with 'a terminal is required'. Run it under script(1)
and validate the password on that pseudo-terminal first, so every sudo
underneath shares the terminal-keyed credential.
The missing-checker case dropped $ROOT/bin from PATH to make
omarchy-git-url-check unfindable, but installed machines carry the
packaged checker in /usr/bin, so it was always found and the test
failed on every 4.x machine. Shadow it with a stub that reports
command-not-found so the scenario holds regardless of the host.
The mount-boundary test tmpfs-mounts over /home before sourcing
$ROOT/bin/omarchy-windows-vm, so a checkout living under /home vanished
mid-test and set -e aborted with no output. Take a mount-safe copy of
the helper into the test tmpdir before the mounts land.
The suite verifies the finished product: VM runs never use a dev-linked
tree, so the session-environment lookup and own-checkout fallback were
needless indirection. /usr/share/omarchy is the default; a caller testing
a different tree passes OMARCHY_PATH itself.
Assert the closed session-to-root paths on an installed system — no blanket
input-group membership, no shipped asdcontrol sudoers grant — and exercise
omarchy-setup-security-sshd unattended end to end: sshd up, key authorized,
password and keyboard-interactive authentication off in the effective
config, SSH port rate limited in the firewall.
The sshd section mutates the machine, so it requires the explicit
OMARCHY_ACCEPTANCE_SUDO_PASSWORD opt-in that omarchy-iso-test passes for
its throwaway VMs; elsewhere it skips.
Tesseract routinely drops small caption text at native resolution — the
weather panel's detail labels fail the WIND assertion with the text plainly
on screen. Let the compositor upscale the capture instead.
Run over SSH with no OMARCHY_PATH, the acceptance runner defaulted it to
its own root — wrong in both sync modes omarchy-iso-test uses. With only
test/ synced, the root has no shell or install manifests: omarchy-shell
refuses every call and the package audit passes vacuously against an empty
manifest. With a full tree synced, the path disagrees with the config path
the session shell was started from, and since qs matches instances by that
path, every omarchy-shell call reads as "not running".
The suite acts on the running session, so ask the user manager for the
session's own OMARCHY_PATH first, then fall back to this checkout, then to
the installed tree.
The shell notices the bar-off flag through a FileView watch on the toggles
directory, and that watch can permanently stop delivering events after flag
changes land in quick succession — the bar then stays parked off screen
until the shell restarts. Have omarchy-toggle-bar nudge the bar's probe
over IPC after flipping the flag, so the toggle no longer depends on the
watch staying alive. The watch remains for other writers of the flag.
The Style submenu grew its Unlock entry back (d411c90a) the same day the
menu acceptance test was written, so the blind Down-key walk landed on
Font and picked a font instead of opening the Menu Bar submenu — the bar
position assertion then timed out on every run.
OpenSSH 10.x prints configuration keywords in CamelCase in its sshd -T
dump, where 9.x printed them lowercase. The case-sensitive grep in
omarchy-setup-security-sshd therefore never matched on OpenSSH 10.x, so
the hardening drop-in was always judged ineffective and removed, leaving
password authentication enabled.
pacman-rc.conf shipped with [omarchy] on pkgs.omarchy.org/edge — a
leftover from when release candidates published there. Candidates now
publish to a dedicated rc channel, so a machine switched to rc with
omarchy-refresh-pacman was pairing the rc Arch mirror with edge omarchy
packages, and omarchy-version-channel could not name the rc repository
at all (an rc install reported 'rc / unknown').
Point the conf at pkgs.omarchy.org/rc, teach omarchy-version-channel
the rc repository, and repoint existing rc-channel machines with a
migration. The migration only rewrites the shipped pairing (rc mirror +
edge [omarchy]); an administrator's deliberate combination is kept.
Apply the Omabot patch on Quattro, verify effective SSH hardening, prevent stored provisioning state from restoring the blanket input-group grant, and stop Omarchy from shipping asdcontrol authorization that belongs to the package.
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Ryan Hughes