Review Results

Comment

The change only updates .SRCINFO metadata to add several build/runtime dependencies and an optdepend for the headers package. There are no source URL changes, no new build commands, no install scripts, and no evidence of network fetches or privilege escalation. The added dependencies (binutils, glibc, libgcc, openssl, xxhash, zlib, zstd) are plausible for a kernel/headers package and do not by themselves introduce a security issue in this metadata-only diff. Risk is low.

@@ -6,9 +6,13 @@ pkgbase = linux-xanmod
 	arch = x86_64
 	license = GPL-2.0-only
 	makedepends = bc
+	makedepends = binutils
 	makedepends = cpio
 	makedepends = gettext
+	makedepends = glibc
 	makedepends = libelf
+	makedepends = libgcc
+	makedepends = openssl
 	makedepends = pahole
 	makedepends = perl
 	makedepends = python

Comment

The change only adds `xxhash` to makedepends in .SRCINFO. This is a metadata-only update that does not affect the built package contents or introduce any execution, network, privilege, or persistence behavior. `xxhash` is a normal build dependency and the source list remains unchanged and pinned to an official HTTPS kernel tarball. No security concerns are evident from this diff alone.

@@ -16,6 +20,7 @@ pkgbase = linux-xanmod
 	makedepends = rust-bindgen
 	makedepends = rust-src
 	makedepends = tar
+	makedepends = xxhash
 	makedepends = xz
 	options = !strip
 	source = https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.tar.xz

Comment

The change only adds an optdepends entry in .SRCINFO for the optional linux-xanmod-headers package. This is metadata-only and does not alter build steps, package contents, permissions, or introduce any network/download/execution behavior. No security-relevant issues are evident in the provided diff hunk.

@@ -34,6 +39,7 @@ pkgname = linux-xanmod
 	depends = coreutils
 	depends = initramfs
 	depends = kmod
+	optdepends = linux-xanmod-headers: headers and scripts for building modules
 	optdepends = linux-firmware: firmware images needed for some devices
 	optdepends = scx-scheds: to use sched-ext schedulers
 	optdepends = wireless-regdb: to set the correct wireless channels of your country

Comment

The change only adds runtime dependencies to the linux-xanmod-headers package in .SRCINFO: binutils, glibc, libelf, libgcc, openssl, xxhash, zlib, and zstd. This is metadata-only and does not introduce new sources, build commands, install scripts, or privilege/network behavior. The added dependencies are plausible for kernel headers/module build tooling and do not by themselves indicate a supply-chain or persistence risk. No security issues are evident from this diff hunk alone.

@@ -47,4 +53,12 @@ pkgname = linux-xanmod
 
 pkgname = linux-xanmod-headers
 	pkgdesc = Headers and scripts for building modules for the Linux Xanmod - Stable Mainline [MAIN] kernel
+	depends = binutils
+	depends = glibc
+	depends = libelf
+	depends = libgcc
+	depends = openssl
 	depends = pahole
+	depends = xxhash
+	depends = zlib
+	depends = zstd

Comment

The change is a harmless PKGBUILD comment/update plus a shell-test style tweak for the optional _microarchitecture variable. It does not add any new sources, network access, privilege escalation, install-script behavior, or packaging changes. The only functional change is switching from a parameter-existence test to a quoted empty-string test, which preserves the intended defaulting behavior for an unset or empty variable and does not introduce a security concern in this context.

@@ -5,13 +5,13 @@
 ##
 ## The following variables can be customized at build time. Use env or export to change at your wish
 ##
-##   Example: env _microarchitecture=98 use_numa=n use_tracers=n makepkg -sc
+##   Example: env _microarchitecture=99 use_numa=n use_tracers=n makepkg -sc
 ##
 ## Look inside 'choose-gcc-optimization.sh' to choose your microarchitecture
 ## Valid numbers between: 0 to 99
 ## Default is: 0 => generic
-## Good option if your package is for one machine: 98 (Intel native) or 99 (AMD native)
-if [ -z ${_microarchitecture+x} ]; then
+## Good option if your package is for one machine: 99 (Native optimizations autodetected by GCC)
+if [[ -z "$_microarchitecture" ]]; then
   _microarchitecture=0
 fi
 

Comment

The change is a small shell-condition hardening in PKGBUILD: it replaces an unquoted parameter-expansion test with a quoted [[ -z "$use_numa" ]] check. This reduces the chance of word-splitting/globbing bugs and does not introduce any new execution, network, privilege, or packaging risks. No suspicious sources, install scripts, or build steps are affected by this hunk.

@@ -19,7 +19,7 @@ fi
 ## Archlinux and Xanmod enable it by default.
 ## Set variable "use_numa" to: n to disable (possibly increase performance)
 ##                             y to enable  (stock default)
-if [ -z ${use_numa+x} ]; then
+if [[ -z "$use_numa" ]]; then
   use_numa=y
 fi
 

Comment

The change is a small shell-syntax cleanup in PKGBUILD: it switches two tests to bash [[ ... ]] with proper quoting. It does not add new sources, network access, privilege escalation, install-script behavior, or any packaging changes. The logic remains equivalent for the intended variables, and there are no security-relevant side effects in this diff hunk.

@@ -28,14 +28,14 @@ fi
 ## Stock Archlinux has this enabled.
 ## Set variable "use_tracers" to: n to disable (possibly increase performance, XanMod default)
 ##                                y to enable  (Archlinux default)
-if [ -z ${use_tracers+x} ]; then
+if [[ -z "$use_tracers" ]]; then
   use_tracers=n
 fi
 
 # Unique compiler supported upstream is GCC
 ## Choose between GCC and CLANG config (default is GCC)
 ## Use the environment variable "_compiler=clang"
-if [ "${_compiler}" = "clang" ]; then
+if [[ "$_compiler" == clang ]]; then
   _compiler_flags="CC=clang HOSTCC=clang LLVM=1 LLVM_IAS=1"
 fi
 

Comment

The change is a small shell-condition refactor in PKGBUILD, replacing parameter-expansion tests with quoted [[ -z ... ]] checks. It does not introduce new sources, network access, privilege escalation, install-script behavior, or packaging changes. The logic remains equivalent for the intended variables, and there are no security-relevant side effects in this diff hunk.

@@ -43,12 +43,12 @@ fi
 # Possible values: config_x86-64-v1 / config_x86-64-v2 (default) / config_x86-64-v3
 # This will be overwritten by selecting any option in microarchitecture script
 # Source files: https://gitlab.com/xanmod/linux/-/tree/6.12/CONFIGS/xanmod/gcc?ref_type=heads
-#if [ -z ${_config+x} ]; then
+#if [[ -z "$_config" ]]; then
   _config=config
 #fi
 
 # Compress modules with ZSTD (to save disk space)
-if [ -z ${_compress_modules+x} ]; then
+if [[ -z "$_compress_modules" ]]; then
   _compress_modules=n
 fi
 

Comment

The change is a harmless shell-quoting fix in PKGBUILD conditionals, replacing unquoted POSIX test syntax with quoted bash [[ ... ]] checks. It does not add new sources, network access, privilege escalation, install-time actions, or packaging behavior changes. No security impact is apparent from this diff alone.

@@ -60,12 +60,12 @@ fi
 # This PKGBUILD read the database kept if it exists
 #
 # More at this wiki page ---> https://wiki.archlinux.org/index.php/Modprobed-db
-if [ -z ${_localmodcfg} ]; then
+if [[ -z "$_localmodcfg" ]]; then
   _localmodcfg=n
 fi
 
 # Tweak kernel options prior to a build via nconfig
-if [ -z ${_makenconfig} ]; then
+if [[ -z "$_makenconfig" ]]; then
   _makenconfig=n
 fi
 

Comment

The change is low risk. It only adds build-time dependencies and does not introduce new sources, network fetches, privilege escalation, install-script behavior, or runtime persistence mechanisms. The added makedepends/depends (binutils, glibc, libgcc, openssl, xxhash, zlib, zstd) are consistent with kernel/headers build requirements, and the surrounding PKGBUILD changes are mostly shell-safety and packaging refinements. One minor concern is that the package now relies on more host toolchain libraries during build, but this is normal for a kernel package and not a security issue by itself.

@@ -85,9 +85,13 @@ arch=(x86_64)
 license=(GPL-2.0-only)
 makedepends=(
   bc
+  binutils
   cpio
   gettext
+  glibc
   libelf
+  libgcc
+  openssl
   pahole
   perl
   python

Comment

The change is a small PKGBUILD refactor: it adds `xxhash` to makedepends and rewrites the conditional adding clang/llvm/lld from a shell `if` to a bash `[[ ... ]] &&` form. There is no new network access, privilege escalation, persistence mechanism, or suspicious build/install behavior introduced by this diff. The added dependency is a normal build-time package, and the logic change is functionally equivalent in a PKGBUILD context. Risk is therefore minimal.

@@ -95,11 +99,11 @@ makedepends=(
   rust-bindgen
   rust-src
   tar
+  xxhash
   xz
 )
-if [ "${_compiler}" = "clang" ]; then
-  makedepends+=(clang llvm lld)
-fi
+[[ "${_compiler}" == clang ]] && makedepends+=(clang llvm lld)
+
 options=('!strip')
 _srcname="linux-${pkgver}-xanmod${xanmod}"
 

Comment

The only reviewed change is a shell quoting/conditional cleanup in PKGBUILD. It does not introduce new sources, network fetches, privilege escalation, install-script behavior, or packaging destinations. The one notable functional change is in the modprobed-db lookup: it now selects a discovered database path into a local variable and quotes it when passed to make, which is a safety improvement rather than a risk. The rest are mostly bash syntax hardening and minor logic refactors. No security issue is evident from this diff alone.

@@ -114,7 +118,7 @@ validpgpkeys=(
 # Archlinux patches
 _commit="ec9e9a4219fe221dec93fa16fddbe44a34933d8d"
 _patches=()
-for _patch in ${_patches[@]}; do
+for _patch in "${_patches[@]}"; do
     source+=("${_patch}::https://raw.githubusercontent.com/archlinux/svntogit-packages/${_commit}/trunk/${_patch}")
 done
 

Comment

The change is a quoting-only adjustment to the patch filename in prepare(): `../"patch-${pkgver}-xanmod${xanmod}${_revision}"`. This does not alter the command semantics in a way that introduces network access, privilege escalation, persistence, or other security-relevant behavior. It simply makes the patch path safer with respect to shell parsing if variables contain special characters. No other suspicious changes are present in the reviewed hunk.

@@ -131,7 +135,7 @@ prepare() {
   cd linux-${_major}
 
   # Apply Xanmod patch
-  patch -Np1 -i ../patch-${pkgver}-xanmod${xanmod}${_revision}
+  patch -Np1 -i ../"patch-${pkgver}-xanmod${xanmod}${_revision}"
 
   msg2 "Setting version..."
   echo "-$pkgrel" > localversion.10-pkgrel

Comment

The change is a no-op shell syntax cleanup in PKGBUILD: `[[ $src = *.patch ]]` was changed to `[[ $src == *.patch ]]`. In bash, both forms are equivalent for pattern matching inside `[[ ... ]]`, and the surrounding logic still only applies local `.patch` sources via `patch -Np1 < "../$src"`. No new sources, commands, privilege changes, or packaging behavior are introduced by this diff.

@@ -143,7 +147,7 @@ prepare() {
     src="${src%%::*}"
     src="${src##*/}"
     src="${src%.zst}"
-    [[ $src = *.patch ]] || continue
+    [[ $src == *.patch ]] || continue
     msg2 "Applying patch $src..."
     patch -Np1 < "../$src"
   done

Comment

The change is a trivial shell syntax adjustment in prepare(): it switches from POSIX test `[ "${_compiler}" = "clang" ]` to Bash `[[ "$ _compiler" == clang ]]`. In the context of a PKGBUILD, this does not introduce network access, privilege escalation, persistence, or packaging integrity issues. It only affects how the existing clang check is evaluated and preserves the same behavior for the intended value. No security concern is evident from this diff hunk alone.

@@ -154,7 +158,7 @@ prepare() {
   # Applying configuration
   cp -vf CONFIGS/x86_64/${_config} .config
   # enable LTO_CLANG_THIN
-  if [ "${_compiler}" = "clang" ]; then
+  if [[ "$_compiler" == clang ]]; then
     scripts/config --disable LTO_CLANG_FULL
     scripts/config --enable LTO_CLANG_THIN
   fi

Comment

The change is low risk. It only adjusts shell test syntax in prepare() from POSIX [ ] to bash [[ ]], and slightly changes the compiler check to a clearer bash condition. The added msg2 line is informational only. There are no new sources, downloads, privilege changes, install-script changes, or packaging/install-path changes. I do not see a security impact from this diff.

@@ -171,22 +175,23 @@ prepare() {
   scripts/config --enable CONFIG_ANDROID_BINDER_IPC
 
   # User set. See at the top of this file
-  if [ "$use_tracers" = "y" ]; then
+  if [[ "$use_tracers" == "y" ]]; then
     msg2 "Enabling CONFIG_FTRACE only if we are not compiling with clang..."
-    if [ "${_compiler}" = "gcc" ] || [ "${_compiler}q" = "q" ]; then
+    if [[ "$_compiler" == gcc || -z "$_compiler" ]]; then
       scripts/config --enable CONFIG_FTRACE \
                      --enable CONFIG_FUNCTION_TRACER \
                      --enable CONFIG_STACK_TRACER
     fi
   fi
 
-  if [ "$use_numa" = "n" ]; then
+  if [[ "$use_numa" == n ]]; then
     msg2 "Disabling NUMA..."
     scripts/config --disable CONFIG_NUMA
   fi
 
   # Compress modules by default (following Arch's kernel)
-  if [ "$_compress_modules" = "y" ]; then
+  if [[ "$_compress_modules" == y ]]; then
+    msg2 "Compressing modues with ZSTD..."
     scripts/config --enable CONFIG_MODULE_COMPRESS
     scripts/config --enable CONFIG_MODULE_COMPRESS_ZSTD
   fi

Comment

The change is a minor shell-syntax cleanup in prepare(): it switches a numeric test from `[ ... -ne ... ]` to arithmetic evaluation and quotes the argument passed to `choose-gcc-optimization.sh`. This does not introduce new network access, privilege escalation, persistence, or packaging integrity issues. If anything, quoting the variable is slightly safer. No security concern identified in this hunk.

@@ -198,8 +203,8 @@ prepare() {
 
   # Let's user choose microarchitecture optimization in GCC
   # Use default microarchitecture only if we have not choosen another microarchitecture
-  if [ "$_microarchitecture" -ne "0" ]; then
-    ../choose-gcc-optimization.sh $_microarchitecture
+  if (( _microarchitecture != 0 )); then
+    ../choose-gcc-optimization.sh "$_microarchitecture"
   fi
 
   # This is intended for the people that want to build this package with their own config

Comment

The change is a minor shell-syntax cleanup in prepare(): it switches from POSIX test syntax to bash [[ ... ]] while preserving the same file-existence and non-empty checks before optionally sourcing a user-provided myconfig. It does not add new commands, network access, privilege changes, or packaging behavior. I do note that the existing logic still executes a user-controlled config file if it contains scripts/config, but that behavior predates this diff and is unchanged here.

@@ -207,7 +212,7 @@ prepare() {
   # If we detect partial file with scripts/config commands, we execute as a script
   # If not, it's a full config, will be replaced
   for _myconfig in "${SRCDEST}/myconfig" "${HOME}/.config/linux-xanmod/myconfig" "${XDG_CONFIG_HOME}/linux-xanmod/myconfig" ; do
-    if [ -f "${_myconfig}" ] && [ "$(wc -l <"${_myconfig}")" -gt "0" ]; then
+    if [[ -f "$_myconfig" && "$(wc -l <"${_myconfig}")" -gt 0 ]]; then
       if grep -q 'scripts/config' "${_myconfig}"; then
         # myconfig is a partial file. Executing as a script
         msg2 "Applying myconfig..."

Comment

The change is low risk. It only broadens the search path for an optional localmodconfig helper database from one user-local location to another XDG-compliant user-local location, and then passes that path to `make localmodconfig`. There are no new downloads, privilege changes, system-wide writes, or suspicious execution paths. The only minor concern is that the new code uses `local _modprobedpath=...` inside conditional expressions, but this is still confined to `prepare()` and only affects which existing user file is read. No security-relevant regression is evident in the diff provided.

@@ -224,10 +229,12 @@ prepare() {
 
   ### Optionally load needed modules for the make localmodconfig
   # See https://aur.archlinux.org/packages/modprobed-db
-  if [ "$_localmodcfg" = "y" ]; then
-    if [ -f $HOME/.config/modprobed.db ]; then
+  if [[ "$_localmodcfg" == "y" ]]; then
+    [[ -f $HOME/.config/modprobed.db ]] && local _modprobedpath="$HOME/.config/modprobed.db"
+    [[ -f ${XDG_DATA_HOME:-$HOME/.local/share}/modprobed-db/modprobed.db ]] && local _modprobedpath="${XDG_DATA_HOME:-$HOME/.local/share}/modprobed-db/modprobed.db"
+    if [[ -n "$_modprobedpath" ]]; then
       msg2 "Running Steven Rostedt's make localmodconfig now"
-      yes "" | make ${_compiler_flags} LSMOD=$HOME/.config/modprobed.db localmodconfig
+      yes "" | make ${_compiler_flags} LSMOD="$_modprobedpath" localmodconfig
     else
       msg2 "No modprobed.db data found"
       exit 1

Comment

The change is a trivial shell syntax adjustment in PKGBUILD prepare(): it replaces a POSIX test with Bash [[ ... ]]. This does not alter build inputs, network behavior, installed files, permissions, or any privilege-related behavior. No security-relevant impact is evident from the diff hunk.

@@ -240,7 +247,7 @@ prepare() {
   make -s kernelrelease > version
   msg2 "Prepared %s version %s" "$pkgbase" "$(<version)"
 
-  if [ "$_makenconfig" = "y" ]; then
+  if [[ "$_makenconfig" == "y" ]]; then
     make ${_compiler_flags} nconfig
   fi
 

Comment

The change is a trivial quoting fix in build(): `cd linux-${_major}` -> `cd "linux-${_major}"`. This does not alter build inputs, network behavior, privileges, installed files, or introduce any new execution path. It only improves robustness if the version string ever contains shell-special characters or spaces, which is not a security concern here. No other suspicious changes are present in the provided hunk.

@@ -249,7 +256,7 @@ prepare() {
 }
 
 build() {
-  cd linux-${_major}
+  cd "linux-${_major}"
   make ${_compiler_flags} all
   make -C tools/bpf/bpftool vmlinux.h feature-clang-bpf-co-re=1
 }

Comment

The change only adds an optdepends entry for the package's own headers package: "$pkgbase-headers: headers and scripts for building modules". This is a metadata-only packaging change with no code execution, no new sources, no install script changes, and no privilege or persistence implications. It simply improves discoverability for module builders and does not alter the built kernel or installed files.

@@ -262,6 +269,7 @@ _package() {
     kmod
   )
   optdepends=(
+    "$pkgbase-headers: headers and scripts for building modules"
     'linux-firmware: firmware images needed for some devices'
     'scx-scheds: to use sched-ext schedulers'
     'wireless-regdb: to set the correct wireless channels of your country'

Comment

The change is a harmless quoting fix in PKGBUILD: `cd linux-${_major}` becomes `cd "linux-${_major}"`. It does not alter sources, build steps, installed files, permissions, or any post-install behavior. No security-relevant impact is apparent from this diff.

@@ -278,7 +286,7 @@ _package() {
     wireguard-arch
   )
 
-  cd linux-${_major}
+  cd "linux-${_major}"
   local modulesdir="$pkgdir/usr/lib/modules/$(<version)"
 
   msg2 "Installing boot image..."

Comment

The change is low risk overall. It mainly broadens header-package dependencies to match additional kernel build artifacts, makes the header packaging logic architecture-aware, and conditionally installs objtool/resolve_btfids/Rust artifacts only when the corresponding kernel config options are enabled. I did not see any new network fetches, privilege escalation, persistence mechanisms, or writes outside $pkgdir. The only notable concern is that the package still sources a patch from SourceForge at build time and the PKGBUILD continues to use an HTTP homepage URL, but those are pre-existing and not introduced by this diff. The new conditional checks and path generalization appear packaging-oriented rather than malicious.

@@ -299,29 +307,47 @@ _package() {
 
 _package-headers() {
   pkgdesc="Headers and scripts for building modules for the $pkgdesc kernel"
-  depends=(pahole)
+  depends=(
+    binutils
+    glibc
+    libelf
+    libgcc
+    openssl
+    pahole
+    xxhash
+    zlib
+    zstd
+  )
 
-  cd linux-${_major}
+  cd "linux-${_major}"
   local builddir="$pkgdir/usr/lib/modules/$(<version)/build"
 
+  local karch
+  case "$CARCH" in
+    x86_64) karch=x86 ;;
+    *) echo "Unknown CARCH $CARCH"; exit 1 ;;
+  esac
+
   msg2 "Installing build files..."
   install -Dt "$builddir" -m644 .config Makefile Module.symvers System.map \
     localversion.* version vmlinux tools/bpf/bpftool/vmlinux.h
   install -Dt "$builddir/kernel" -m644 kernel/Makefile
-  install -Dt "$builddir/arch/x86" -m644 arch/x86/Makefile
+  install -Dt "$builddir/arch/$karch" -m644 arch/$karch/Makefile
   cp -t "$builddir" -a scripts
   ln -srt "$builddir" "$builddir/scripts/gdb/vmlinux-gdb.py"
 
-  # required when STACK_VALIDATION is enabled
-  install -Dt "$builddir/tools/objtool" tools/objtool/objtool
+  if [[ $(scripts/config -s CONFIG_HAVE_STACK_VALIDATION) == y ]]; then
+    install -Dt "$builddir/tools/objtool" tools/objtool/objtool
+  fi
 
-  # required when DEBUG_INFO_BTF_MODULES is enabled
-  install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids
+  if [[ $(scripts/config -s CONFIG_DEBUG_INFO_BTF_MODULES) == y ]]; then
+    install -Dt "$builddir/tools/bpf/resolve_btfids" tools/bpf/resolve_btfids/resolve_btfids
+  fi
 
   msg2 "Installing headers..."
   cp -t "$builddir" -a include
-  cp -t "$builddir/arch/x86" -a arch/x86/include
-  install -Dt "$builddir/arch/x86/kernel" -m644 arch/x86/kernel/asm-offsets.s
+  cp -t "$builddir/arch/$karch" -a arch/$karch/include
+  install -Dt "$builddir/arch/$karch/kernel" -m644 arch/$karch/kernel/asm-offsets.s
 
   install -Dt "$builddir/drivers/md" -m644 drivers/md/*.h
   install -Dt "$builddir/net/mac80211" -m644 net/mac80211/*.h

Comment

The change only gates installation of Rust-related header artifacts on CONFIG_RUST being enabled. This is a packaging/build hygiene adjustment and does not introduce network access, privilege escalation, persistence, or suspicious file installation. The new `install` calls are still confined to the build directory, and the condition uses the kernel config helper already present in the tree. No security-relevant regression is evident from this diff alone.

@@ -340,9 +366,11 @@ _package-headers() {
   echo "Installing KConfig files..."
   find . -name 'Kconfig*' -exec install -Dm644 {} "$builddir/{}" \;
 
-  msg2 "Installing Rust files..."
-  [ -f rust/*.rmeta ] && install -Dt "$builddir/rust" -m644 rust/*.rmeta
-  [ -f rust/*.so ] && install -Dt "$builddir/rust" rust/*.so
+  if [[ $(scripts/config -s CONFIG_RUST) == y ]]; then
+    echo "Installing Rust files..."
+    install -Dt "$builddir/rust" -m644 rust/*.rmeta
+    install -Dt "$builddir/rust" rust/*.so
+  fi
 
   msg2 "Installing unstripped VDSO..."
   make INSTALL_MOD_PATH="$pkgdir/usr" vdso_install \

Comment

The change narrows the headers pruning logic from always preserving only x86 to preserving the configured kernel architecture directory ($karch). This is a packaging correctness fix, not a security-sensitive behavior change. It does not introduce network access, privilege escalation, persistence, or installation outside the package directory. The only effect is which architecture subdirectory is retained during header packaging, and that remains confined to the build tree.

@@ -351,7 +379,7 @@ _package-headers() {
   msg2 "Removing unneeded architectures..."
   local arch
   for arch in "$builddir"/arch/*/; do
-    [[ $arch = */x86/ ]] && continue
+    [[ $arch == */$karch/ ]] && continue
     echo "Removing $(basename "$arch")"
     rm -r "$arch"
   done