- Pacman-dev - lists.archlinux.org

[RFC] libalpm: validate archive entry paths in extract_single_file
by Strykar 15 Apr '26

15 Apr '26

Hi all, I'd like to introduce a small hardening change (found by Claude) in lib/libalpm/add.c and get upstream's take before sending an MR. Branch (2 signed commits, rebased on current master): https://gitlab.archlinux.org/strykar/pacman/-/tree/harden/extract-entry-val… perform_extraction() passes ARCHIVE_EXTRACT_OWNER | PERM | TIME | UNLINK | XATTR | SECURE_SYMLINKS to libarchive (add.c:118) — no SECURE_NODOTDOT, no SECURE_NOABSOLUTEPATHS. extract_single_file then builds the on-disk path as snprintf("%s%s", handle->root, entryname) (add.c:216) from the archive's entryname and overrides the entry pathname via archive_entry_set_pathname. An entryname with a leading /, or one whose .. components leave handle->root after concatenation (e.g. foo/../../etc/evil), extracts outside handle->root. One accidental mitigation to note: entries starting with . route to extract_db_file, which silently drops anything other than .INSTALL/.MTREE/.CHANGELOG (add.c:204-208). So a literal ../etc/x is a no-op today — the practical exploit requires either a non-dot-prefixed traversal (foo/../../etc/x) or a leading /. The alpm_filelist_contains gate at add.c:208 does not provide independent validation: per be_package.c:612-618, newpkg->files is populated from the archive's own .MTREE (preferred) or from the tar entries as fallback. In the unsigned / -U / SigLevel = TrustAll case, both sources are attacker-controlled in a tampered archive, so a malicious builder lists the traversal path in .MTREE and ships the matching tar entry — the check passes. Signed repo install: package is trusted, .INSTALL runs as root, traversal adds nothing. Not trying to escalate this. Where the gap matters. pacman -U on locally-built or SigLevel = TrustAll packages; --root for staging / image builds / pacstrap-like flows (the 2024 Trail of Bits audit, Recommendations p.7, notes --root does not guarantee files outside the root remain untouched); non-root libalpm consumers. Why libarchive flags alone don't cut it. Adding SECURE_NOABSOLUTEPATHS to archive_flags rejects every entry, because pacman itself sets the entry pathname to handle->root + entryname, which is absolute. SECURE_NODOTDOT would catch middle-.. cases (the concat is a dumb snprintf, not normalizing, so .. survives in the final path) but not a leading / in the entry (concat yields //etc/foo, which has no ..). So any fix needs a lexical check on the raw entryname anyway. I dropped SECURE_NODOTDOT as redundant; happy to add it as belt-and-braces if reviewers prefer. Proposed change. A small lexical validator on archive_entry_pathname and archive_entry_hardlink, called before alpm_filelist_contains. Reject on leading /, empty/NULL, or any .. path component. On reject: log and abort the install. Build/test. Builds clean on master. Full meson test passes: 341 OK, 6 pre-existing ExpectedFail, 0 failures — including three new tests covering foo/../../etc/evil (rejected), /etc/evil (rejected), and usr/share/foo..bar/baz (accepted, false-positive guard). Tests assert PACMAN_RETCODE=1 and !FILE_EXIST=etc/evil. One minor test-infra addition: an allow_unsafe_paths flag on pmpkg so absolute-path entries can be authored into a test archive (pmpkg.py:201 refuses them by default). Empirical check. Scanned every file entry in the synced core/extra/multilib/aurpkgs file databases on my machine — 7,712,742 entries, zero with leading / or .. components. The list will have broader visibility than I do; I'd welcome counter-examples from cross / dev-kit packaging in particular. Open questions: Abort vs skip-and-warn? I lean abort: presence is evidence of tampering or a broken build tool. Any legitimate case in Arch packaging where a tar entry has .. or leading /? Follow-up patch to extend to extract_db_file for symmetry? Interest in also enabling SECURE_NODOTDOT as defense-in-depth alongside the lexical check? Orthogonal observation worth a separate thread: when -U extraction fails mid-transaction, the package is left registered in the local db (discovered while writing these tests — not caused by this patch). Happy to file separately. Not framing this as a vulnerability — the declared trust model covers default installs. But the --root / unsigned--U / non-root-consumer gap is the shape of thing the ToB audit flagged as under-specified, and this is ~20 lines that closes it. Commits are signed with key E4A8486E91D492EA. Please let me know if an MR is preferred over this RFC flow or is this a umad / wontfix trustmodel? Thanks, Strykar

2 2

[PATCH] conf: Fix off-by-one heap overrun in escape_chars()
by Chris Down 14 Apr '26

14 Apr '26

escape_chars() computes the post-escaping buffer size as len + pattern_chars, but unfortunately never accounts for the null terminator it unconditionally writes afterwards. That means that when pacman-conf applies --sysroot to an Include directive and that sysroot path contains a character that also happens to be a glob metacharacter, the null terminator is written one byte past the end of the allocation. Fix both the overflow guard and the malloc size so the terminator always falls within the allocated region. The off by one write is reliably caught by ASAN, so add a dedicated TAP test to prevent regressions. Fixes: 7016adcb7035 ("manually apply --sysroot to configuration") --- meson.build | 2 +- src/pacman/conf.c | 4 +-- test/util/meson.build | 9 +++++ test/util/pacman-conf-sysroot-escape.sh | 45 +++++++++++++++++++++++++ 4 files changed, 57 insertions(+), 3 deletions(-) create mode 100755 test/util/pacman-conf-sysroot-escape.sh diff --git a/meson.build b/meson.build index 8e2444d1..800f37e9 100644 --- a/meson.build +++ b/meson.build @@ -374,7 +374,7 @@ pacman_bin = executable( install : true, ) -executable( +pacman_conf_bin = executable( 'pacman-conf', pacman_conf_sources, include_directories : includes, diff --git a/src/pacman/conf.c b/src/pacman/conf.c index e391735a..fd419529 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -1132,8 +1132,8 @@ static char *escape_chars(const char *pattern, const char *escape) } /* allocate new string with overflow check */ - if(SIZE_MAX - len < pattern_chars - || !(escaped = malloc(len + pattern_chars))) { + if(SIZE_MAX - len <= pattern_chars + || !(escaped = malloc(len + pattern_chars + 1))) { errno = ENOMEM; return NULL; } diff --git a/test/util/meson.build b/test/util/meson.build index b4046298..71921296 100644 --- a/test/util/meson.build +++ b/test/util/meson.build @@ -5,3 +5,12 @@ test('vercmptest', args : [ join_paths(meson.current_source_dir(), 'vercmptest.sh') ]) + +test('pacman-conf-sysroot-escape', + BASH, + env : TEST_ENV, + protocol : 'tap', + args : [ + join_paths(meson.current_source_dir(), 'pacman-conf-sysroot-escape.sh') + ], + depends : [pacman_conf_bin]) diff --git a/test/util/pacman-conf-sysroot-escape.sh b/test/util/pacman-conf-sysroot-escape.sh new file mode 100755 index 00000000..473c369d --- /dev/null +++ b/test/util/pacman-conf-sysroot-escape.sh @@ -0,0 +1,45 @@ +#!/bin/bash +# +# pacman-conf-sysroot-escape - verify sysroot glob escaping under ASAN +# +# Copyright (c) 2026 Pacman Development Team <pacman-dev(a)lists.archlinux.org> +# +# This program is free software; you can redistribute it and/or modify it under +# the terms of the GNU General Public License as published by the Free Software +# Foundation; either version 2 of the License, or (at your option) any later +# version. +# +# This program is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS +# FOR A PARTICULAR PURPOSE. See the GNU General Public License for more +# details. +# +# You should have received a copy of the GNU General Public License along with +# this program. If not, see <http://www.gnu.org/licenses/>. + +source "$(dirname "$0")"/../tap.sh || exit 1 + +bin=${1:-${PMTEST_UTIL_DIR}pacman-conf} + +if ! type -p "$bin" &>/dev/null; then + tap_bail "pacman-conf binary ($bin) could not be located" + exit 1 +fi + +tmpdir=$(mktemp -d) +trap 'rm -rf "$tmpdir"' EXIT + +sysroot="$tmpdir/sys[root" +mkdir -p "$sysroot/etc" "$sysroot/dev" +: > "$sysroot/dev/null" +printf '[options]\nInclude = /dev/null\n' > "$sysroot/etc/pacman.conf" + +tap_plan 2 + +output=$("$bin" --sysroot "$sysroot" --config /etc/pacman.conf RootDir 2>&1) +ret=$? + +tap_is_int "$ret" 0 "pacman-conf parses Include under metachar sysroot" +tap_is_str "$output" "$sysroot/" "pacman-conf preserves the escaped sysroot" + +tap_finish base-commit: a6f7467d8c7c4d7e9cc846884e74c0ab7215c48d -- 2.53.0

2 3

[RFC] Proposal: 1-byte status signaling for db.lck
by Carsten Heine 05 Apr '26

05 Apr '26

Hello, I am proposing a specification update for the ALPM/Pacman lock file. The current binary-existential state (exists/not exists) is insufficient for modern multi-process environments and leads to significant state-blindness for administrators. Specification: # Feature-Request: Content-Based Lock-State Signaling (CBLSS) Author: Carsten Udo Heine <cuheine(a)gmail.com> Version: 20260404-1316 Abstract: The current db.lck mechanism in ALPM/Pacman is purely binary. This proposal introduces a 1-byte status register (Hex-Nibbles) and vector-based logging (New (Old)) to ensure transparency. Rationale: 1. Context Awareness: Allows admins to distinguish between critical mutations (Writing) and non-invasive tasks (Pending/Info). 2. Deterministic Forensics: The New (Old) notation (e.g., 01 (30)) documents transitions. Missing transitions reveal crashes. 3. Architectural Discipline: Forces UI wrappers to justify their state, exposing preemptive locking "overcast". Technical Specification (The "Hex-Nipple" Model): The file /var/lib/pacman/db.lck shall contain exactly 1 Byte. High Nipple (Soft/Info) : Low Nipple (Hart/Action) : Definition 0 0 doneOK: System is free. 1 0 Pending: Background update check in progress. 2 0 Information: Updates found; no active mutation. 3 0 Waiting: GUI awaiting user input (Block risk!). 0 1 Writing: CRITICAL. Database mutation in progress. 0 3 Error: Process aborted; potential inconsistency. Logging Protocol (db.lck.log): Format: TIMESTAMP | PID | PROCESS | NEW (OLD) Principle: Append-only. This proposal maintains DRY principles and POSIX integrity without adding new dependencies or daemons. I am looking forward to technical feedback. Regards, Carsten

2 1

Interest in config option for TLS cert and key?
by nibo 17 Mar '26

17 Mar '26

Hello, I have an idea for a feature that I would like to write and eventually merge into pacman. I post in this mailing list to find out if there is an interest in it before I start coding. My goal is to have a custom repository that can only be used by me. First I tried to create an ssh host in ~/.ssh/config ... ``` Host Custom Hostname custom.org User root Port 1 IdentityFile /path/to/file ``` ... and then use it /etc/pacman.conf ... ``` [custom] Server = ssh://Custom:~/path/to/repo ``` ... but that doesn't work. But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file. Maybe there is a better solution already available without changing any code that I overlooked. Maybe you have a different solution to my goal. Maybe you are a maintainer and know that such a feature is not wanted. I'm interested in hearing all these thoughts. Best regards, nibo

5 5

Parallel signature checks
by Isaac Yeo 04 Mar '26

04 Mar '26

Hullo folks, Wonder if I could try implementing parallel package signature checks? On some old systems with large upgrades it'd spend over a minute just checking signatures. Would be a nice qol upgrade imo, is this worth taking a stab at? P.S. I'm new here, pardon if this has been asked before :) - Isaac

2 1

[Git][pacman/pacman][release/7.1.x] Prevent overflow when sorting package download order
by Allan McRae (＠allan) 04 Feb '26

04 Feb '26

Allan McRae pushed to branch release/7.1.x at Pacman / Pacman Commits: cb7452f6 by Allan McRae at 2026-02-05T09:53:42+10:00 Prevent overflow when sorting package download order When comparing the package download size, the difference is cast to an int. This results in an integer overflow for very large packages. Return -1, 0, or 1 to indicate relative size to avoid the overflow. Fixes #305. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - lib/libalpm/dload.c View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/cb7452f63414291b5206116… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/cb7452f63414291b5206116… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] Prevent overflow when sorting package download order
by Allan McRae (＠allan) 04 Feb '26

04 Feb '26

Allan McRae pushed to branch master at Pacman / Pacman Commits: a6f7467d by Allan McRae at 2026-01-25T22:50:56+10:00 Prevent overflow when sorting package download order When comparing the package download size, the difference is cast to an int. This results in an integer overflow for very large packages. Return -1, 0, or 1 to indicate relative size to avoid the overflow. Fixes #305. Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - lib/libalpm/dload.c View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/a6f7467d8c7c4d7e9cc8468… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/a6f7467d8c7c4d7e9cc8468… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][release/7.1.x] libmakepkg: fix linting of xdata
by Allan McRae (＠allan) 07 Jan '26

07 Jan '26

Allan McRae pushed to branch release/7.1.x at Pacman / Pacman Commits: 54d94116 by Allan McRae at 2026-01-07T21:33:46+10:00 libmakepkg: fix linting of xdata Signed-off-by: Allan McRae <allan(a)archlinux.org> (cherry picked from commit 2979f35840f1adbb04fee2d224d114a079c0e803) - - - - - 1 changed file: - scripts/libmakepkg/lint_pkgbuild/xdata.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/54d94116164b0b2202c6061… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/54d94116164b0b2202c6061… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][master] libmakepkg: fix linting of xdata
by Allan McRae (＠allan) 07 Jan '26

07 Jan '26

Allan McRae pushed to branch master at Pacman / Pacman Commits: 2979f358 by Allan McRae at 2026-01-07T21:30:47+10:00 libmakepkg: fix linting of xdata Signed-off-by: Allan McRae <allan(a)archlinux.org> - - - - - 1 changed file: - scripts/libmakepkg/lint_pkgbuild/xdata.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/2979f35840f1adbb04fee2d… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/2979f35840f1adbb04fee2d… You're receiving this email because of your account on gitlab.archlinux.org.

1 0

[Git][pacman/pacman][release/7.1.x] repo-add: prevent package file deletion with -R is readding a package
by Allan McRae (＠allan) 07 Jan '26

07 Jan '26

Allan McRae pushed to branch release/7.1.x at Pacman / Pacman Commits: 563f038b by Allan McRae at 2026-01-07T10:25:07+10:00 repo-add: prevent package file deletion with -R is readding a package Using "repo-add -R" on a package file that was already present in the repo resulted in the package file being deleted. Given the package file was being readded to the repo, this was likely not the desired outcome. Fixes #294. Signed-off-by: Allan McRae <allan(a)archlinux.org> (cherry picked from commit 5ff7d06b5c63952b2e2e229b7bcdfe58d6c22306) - - - - - 1 changed file: - scripts/repo-add.sh.in View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/563f038b27bdd977079bfb5… -- View it on GitLab: https://gitlab.archlinux.org/pacman/pacman/-/commit/563f038b27bdd977079bfb5… You're receiving this email because of your account on gitlab.archlinux.org.

1 0