Sync upstream omarchy 0ae16948
#2
Open
gitea-actions
wants to merge 9 commits from
sync/upstream-0ae16948 into quattro
pull from: sync/upstream-0ae16948
merge into: :quattro
:quattro
:sync/upstream-83881e97
:sync/upstream-0ae16948
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
0ae1694830 |
Constrain the tzupdate sudoers rule to a single timezone argument (#8194)
The wildcard granted passwordless root for timedatectl set-timezone plus any trailing arguments, so -H/--host and -M/--machine reached the SSH and machine transports as root. Systemd 261 guards argv injection into ssh, but -H still drives root's SSH client at an attacker-chosen host, and the transport resolves its helper through PATH; only Defaults secure_path stands between that and a planted ssh running as root. Match the argument with an anchored POSIX ERE that admits exactly one timezone token (no whitespace, no leading-dash segment, no traversal component), so no second argument and no option can ever match. The sole caller, omarchy-menu-timezone, passes one list-timezones value and is unaffected. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
77305ed3b9 |
Enable Dell XPS 13 sidecar speaker amplifiers (#7032)
The Dell XPS 13 DX13260 drives its two CS35L56 sidecar speaker amplifiers through a quirk that Linux only gains in 7.2, so until Arch ships that kernel the machine plays through one amplifier with no bass. The dell-xps13-sidecar-amps package selects the same driver path with a module override; this installs it on that exact machine and nowhere else. The detector requires both the DX13260 product name and SKU 0E53, because the override forces a quirk value rather than merging into one, and a machine that gets it wrong loses whatever quirk the kernel would have chosen for itself. Pacman registers a package even when its post_install scriptlet fails, so the leaf calls dell-xps13-sidecar-amps-apply itself instead of trusting the install to have applied: a failed cleanup or boot-image rebuild has to reach the caller rather than hide behind a package pacman considers installed. That is also why the migration marks reboot-required only after the apply succeeds — a migration that exits non-zero keeps no completion marker and retries the apply on the next run, even though pacman already has the package. The leaf runs after intel/ptl-kernel.sh rather than beside the other Dell leaf at the top of install/hardware/all.sh, so its boot-image rebuild sees the Panther Lake kernel that step swaps in rather than the stock one it removes. Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
Naeem MalikandGitHub
|
9301092404 | Update Omarchy on Mac guide link to omarchy-mac repo (#8192) | ||
|
|
4cd8a081cb |
Fix Codex usage collection on 0.149 (#7649)
* Fix Codex usage collector approval policy * Capture codex argv with boundaries in the scanner test The stub joined its arguments with "$*", so the assertion compared one flattened string and could not tell five arguments from fewer containing spaces. Passing "-s read-only" and "-a on-request" as single arguments -- which codex rejects as an unexpected argument -- passed the test. NUL separation and an array comparison keep the boundaries the assertion is about. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Omabot <omabot@omarchy.org> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
23dab9ec4d |
[Security] Stop the FIDO2 setup staging its authfile at a predictable /tmp path (#7904)
* [Security] Stop the FIDO2 setup staging its authfile at a predictable /tmp path pamu2fcfg wrote to /tmp/fido2 and the registration was then moved into place with `sudo mv`. Any other local user can pre-create /tmp/fido2, and rename(2) does not dereference the final component, so the privileged move installed the attacker's symlink itself as pam_u2f's global authfile -- a file consulted by `sufficient` lines in /etc/pam.d/sudo and /etc/pam.d/polkit-1. The same move also carried the staged file's ownership into /etc, so on every install to date /etc/fido2/fido2 is owned by the invoking user at mode 0644. That needs no attacker: anything running as that uid can add its own credential and satisfy the machine's sudo prompt without root. Stage under mktemp and hand the bytes to `install` instead, so the authfile is always a fresh root-owned regular file rather than an inode a non-root user still controls. Guard the already-registered check with -L, which -f would otherwise follow, and reject a symlinked /etc/fido2 in the remove path for the same reason. A migration takes ownership of authfiles left behind by the old code; it reports a symlink rather than repairing one, since chown would follow it and removing it would strip sudo from anyone whose only credential is the token. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012e6WagC5iUigCGoK1tQeFz * Install the FIDO2 authfile with -T and refuse a non-regular path `install SRC DEST` without -T treats an existing directory at DEST as a destination directory: it drops the credential inside as /etc/fido2/fido2/tmp.XXXX, exits 0, and setup reports a successful registration while PAM goes on reading a path that is not a file. -T makes that an error. The already-registered check has the same blind spot from the other side. -f follows symlinks, so it reads a symlinked authfile as a registration and leaves it in place, and is false for a directory, so it tries to register over one. Only a regular file is a pam_u2f authfile; anything else is now refused with the same advice to remove it and set FIDO2 up again. The test deleted every staged path that fell outside its scratch directory, taking the path from the script under test and already resolved through any symlink -- so a script staging through one would have named a file of the user's and had it unlinked. It now unlinks only a file its own stub wrote into. On a machine that already has /etc/fido2/fido2 the staging assertions cannot run at all, and the file used to pass without exercising one of them. That branch now asserts what the host state promises instead: a regular authfile still has to be recognised as a registration and left alone, and anything else has to be refused. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Replace the FIDO2 authfile inode rather than chowning it in place Permission is checked at open(2), not at write(2), so a descriptor the registering user opened on the authfile while it was still theirs stays writable through chown and chmod alike. pam_u2f resolves /etc/fido2/fido2 to that same inode, so the repair left the account it authenticates able to append a credential it controls -- the exact state the migration exists to end, now recorded as migrated and never revisited. Installing a fresh root-owned copy and renaming it over the path leaves any such descriptor writing to a file nothing reads. Credit to #7703, which reached the same conclusion independently. An interrupted run heals: the staged copy is root-owned 600 and inert, no marker is written, and the next run replaces it. A directory or device at the authfile path is no more ours to rewrite than a symlink is, and chmod 600 on a directory would only make it untraversable, so both are now reported rather than repaired. The repair had no test, because it names an absolute path no unprivileged suite can write. It is exercised through a scratch copy with that one literal retargeted, rather than by reading the path from the environment: the migration hands `install` and `mv` root, and an operand the caller can choose is a privileged write to anywhere. The copy is only as honest as the substitution, so the test fails if the migration stops naming the path exactly once. Covered: the no-op on a machine that never registered a key, which must not cost a password prompt; the repair itself; the new inode; the absence of a staged copy afterwards; a second account finding it done; and the symlink and non-regular cases. Each assertion was checked against a mutation that defeats it -- notably a repair with the right install call, mode, content and cleanup that writes through the old inode, which only the inode assertion catches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Finish hardening FIDO2 authfile installation * Guard the FIDO2 directory and the stage path the setup writes through install -d follows a symlink at /etc/fido2 and applies the mode and ownership to whatever it points at, so the credential would be staged and published inside the link target and that directory silently reopened to root:root 755. The leaf guard above it only covered fido2 itself, and this is the same threat omarchy-remove-security-fido2 already names on its side. mktemp's output is an operand for a privileged tee, chmod, mv and rm. The migration validates it before any of them run; the setup did not, so take only the name it asked for there too. The suite was guarded on the host's own /etc/fido2/fido2 and exited early when one existed, which meant the staging assertions asserted nothing on exactly the machines that use FIDO2. Drive a retargeted copy the way the migration suite already does, so every branch is a fixture and all of them run everywhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Stop the FIDO2 migration recording a repair it never made omarchy-migrate writes the per-user completion marker on any zero exit, so the two states this migration cannot repair got one line in the update terminal and were then silenced for good: no login notice, no re-run, the migration recorded as done having repaired nothing. Those are precisely the machines where the authfile may already be under someone else's control, so raise them through omarchy-notification-send as well, where they outlive the scrollback. Delivery is best-effort: a machine with no user bus or no notification server must not abort the migration and take every later one with it. The early exit had the same shape of problem. It read the authfile unprivileged, and the old setup created /etc/fido2 with `sudo mkdir -p`, which took the union of the caller's umask and sudoers' 0022 — so registering under `umask 077` left the directory mode 0700 with the user-owned authfile still inside. Absence and "cannot look" are the same answer to those tests, and the migration exited 0 and marked itself complete. Ask root whether a registration is actually behind an untraversable directory before reopening it, so an aborted setup that left an empty directory, or one an administrator keeps private, does not have its mode widened and its group and special bits discarded for a repair it does not need. A machine that never set FIDO2 up has no directory here and still reaches exit 0 without a password prompt. The notification assertion checks argument shape rather than a substring of the command line. The glyph is a private-use codepoint, and losing it shifts every argument left: -g swallows the headline, the body becomes the title, and the message goes out with no description — which a substring match reads as a pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Cover the FIDO2 removal's symlink guard The -d to -e || -L change is load-bearing for the threat its own comment names — a dangling link at /etc/fido2 that -d reads as absent, left for the next setup to install an authfile through — and it was the one part of this work with no test behind it. Name the directory once so the suite can retarget a copy, the same seam the setup and migration suites use, and assert both halves: the link goes, and the directory it pointed at does not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
9285b19d6a |
[Security] Stop USB device names from being executed as Hyprland Lua (#8129)
* Stop device names from being executed as Hyprland Lua Hyprland input-device and monitor names come from USB descriptors and hyprctl output, so they are attacker-influenceable, yet the toggle and monitor commands interpolated them straight into hyprctl eval and into generated Lua that Hyprland re-executes on every reload. The input-device toggle keys are bound with locked = true, so a malicious USB name reached Lua code execution from the lock screen; a persisted disable made it run on every start. This closes that class everywhere it appeared. - The touchpad/touchscreen disable is now the device name in a plain-text sidecar file, read back by a packaged Lua module on reload, never a generated Lua file. hyprctl eval Lua-quotes the name and control characters are rejected outright. - Dropped the shipped *-disabled.lua templates so nothing seeds a disabled state to /etc/skel, making the name file the single source of truth read from a hardcoded ~/.local/state to match the sibling tools. - The reload loader excludes those two legacy filenames, so a leftover generated *-disabled.lua on a not-yet-migrated install can never be sourced as code again; a migration then recovers the device name from it and deletes it, sanitizing installs that ran the vulnerable version. - All four monitor scripts (internal, mirror, clamshell, scaling) now validate an output name against a plain-connector-name pattern before writing it as Lua, closing the same latent pattern in the siblings. - paths.lua treats a set-but-empty XDG_STATE_HOME as unset, matching the bash side so state is never read from the filesystem root. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0144ZDt44vtxjyF8j9Y88NrM * Let a failing Lua assertion fail the test lua discards the status of a chunk read from stdin, so a blown assert printed its traceback and still exited 0: the surrounding `set -euo pipefail` never fired and the following `pass` printed `ok`. Every Lua block in these two files was unenforced, including the assertion that a quoted `hyprctl eval` cannot reach `os.execute` and the negative control that proves the test can detect the injection at all. Passing the chunk as a script argument makes lua report the failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Re-apply a recovered input-device disable to the running session The package hook reloads Hyprland during `omarchy-update-system-pkgs`, before `omarchy-migrate` runs, and at that reload the generated Lua is already excluded while the name file does not exist yet — so a touchpad or touchscreen the user had switched off comes back on, and stays on until their next login. Reload once more once the name has been recovered, which is the same path a login already takes to read it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <codex@openai.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Omarchybot <omabot@omarchy.org> Co-authored-by: Codex XHigh <codex@openai.com> |
||
|
|
4637735aa2 |
Pin trusted PATH in privileged DNS helper (#8172)
* Pin PATH to trusted dirs when omarchy-dns holds root A dev link prepends a user-writable checkout bin/ to sudo's secure_path, so the passwordless `omarchy-dns Cloudflare` sudoers rule lets root resolve a bare helper (dirname, install, tee, nmcli, ...) out of that checkout — turning checkout-write access into arbitrary root execution. Pin PATH to trusted system directories once EUID is 0, leaving the unprivileged wrapper phase free to locate sudo/pkexec on the caller's PATH. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YUWoHbBoKMjsjV6X3nu1H5 * Assert the trusted-PATH pin is gated on root, not merely present The EUID assertion matched `(( EUID == 0 ))` anywhere in the file, and require_root has carried that exact test since long before the pin existed. Deleting the pin left the assertion passing, so it stood for nothing: a run with the pin neutered reached the behavioural probe with both greps green. Anchor on the unindented guard and require the pin to be the line it opens, which no other construct in the script satisfies. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Skip the DNS trusted-PATH probe where user namespaces are unavailable `fail` ends the file, so a sandbox or hardened kernel that refuses unprivileged user namespaces did not just lose the probe — it took the two elevation assertions below it down as well, reporting a product defect where there was only a missing capability. The non-graphical suites are meant to run on any machine and treat a skip as a passing test, the way require_compositor and plugin-add-test.sh already do. Gate the probe on the namespace it needs and say so when it is absent; the static checks above and the elevation checks below run either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
|
68ab12f77d |
Share the git URL check, and refuse the transports Omarchy does not clone from (#8174)
* Share the git URL check between theme-install and plugin-add Both commands clone a URL a stranger can choose, and each carried its own copy of the rule that refuses a git option or a `<helper>::<address>` transport helper before cloning. Two copies of a security check drift: the second one arrived four months after the first, and only because someone went looking for it. The rule now lives in omarchy-git-url-check and the callers ask it. Its absence refuses the URL rather than waving it through, since the callers read a non-zero status as a refusal and a missing command exits 127. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> * Refuse a git URL naming a transport Omarchy does not clone from `<helper>::<address>` is only one of the two ways a URL reaches a remote helper. git also resolves git-remote-<scheme> for `<scheme>://<address>` whenever the scheme is not one it connects itself, so `ext::sh -c id` and `ext://sh -c id` arrive at the same helper while only the first was refused. That shape cannot be refused outright, because it is also how every legitimate URL arrives, so the scheme is checked against the transports git still connects itself. `git+ssh` and `ssh+git` are on that list: they are spelled like a helper and read as plain ssh, and leaving them off would refuse a URL that clones today. `ext` and `fd` are off it deliberately -- git ships a helper for each, and `ext` runs whatever command the URL carries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-Authored-By: Codex XHigh <noreply@openai.com> --------- Co-authored-by: David Heinemeier Hansson <david@hey.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Codex XHigh <noreply@openai.com> |
||
|
BastiandGitHub
|
30471bf35a |
Guard plugin-add against git transport-helper URLs (match theme-install) (#8067)
* Guard plugin-add against git transport-helper URLs omarchy-plugin-add cloned a user-supplied git URL without the transport-helper guard that omarchy-theme-install already applies (added in #7884, which did not touch plugin-add). Port that guard (reject ext::/fd:: and leading-dash forms, keep https/ssh/scp-style incl. IPv6) and add a regression test. Stock systems are unaffected (git default protocol.ext.allow=never); this removes the silent dependency on that default and aligns the two install paths. * Test the plugin-add guard's leading-dash arm via the gum input path The prior leading-dash cases only exercised the argv option parser, not the guard (removing the guard's -* arm left them green). Drive a dash value through the interactive gum prompt under a pty so the post-input guard is actually covered; skip cleanly where util-linux script is unavailable. |