Review Results

Comment

The only change in this .SRCINFO diff is a pkgrel bump from 5 to 6. No sources, checksums, build steps, install scripts, dependencies, or runtime artifacts changed. This is a metadata-only packaging revision with no security-relevant behavior introduced by the diff shown.

@@ -1,7 +1,7 @@
 pkgbase = pi-hole-core
 	pkgdesc = The Pi-hole is an advertising-aware DNS/Web server. Arch adaptation for lan wide DNS server.
 	pkgver = 6.4.3
-	pkgrel = 5
+	pkgrel = 6
 	url = https://github.com/pi-hole/pi-hole
 	install = pi-hole-core.install
 	arch = any

Comment

The .SRCINFO change only adds a new packaged source file, pihole.sudo, and updates its checksum plus pkgrel. I checked the corresponding PKGBUILD and the new file is a sudoers drop-in granting the pihole user passwordless execution of /usr/bin/pihole, which is already expected by the package’s install script and is restricted to a single command. There is no evidence in this diff of network fetches, shell injection, privilege escalation beyond the intended sudoers rule, or other malicious persistence. The main risk is the inherent sensitivity of shipping a sudoers file, but in this context it matches the package’s existing behavior and scope.

@@ -32,8 +32,9 @@ pkgbase = pi-hole-core
 	source = pi-hole-logtruncate.timer
 	source = mimic_basic-install.sh
 	source = piholeDebug.sh
+	source = pihole.sudo
 	sha256sums = defe72687f90af45c3e735aa9bfabc01d1d75a3b3d6197e92c6216971859e57e
-	sha256sums = cc3b1864234eae8b5501cc4ef53645f44d3c6cb98c1e60f2e94ae173ab586fc2
+	sha256sums = 8c03411068b01c83d2128c00d641e6e11278c3fc2032f59a847c4136fae09097
 	sha256sums = d09f9d10ebdfb6db24d4e1abff8cd09519a7b3f3878ef3974c26aa6838f74e7e
 	sha256sums = 9b72d7769036f8f4bb7121968d2ae4bdba427e4b16787ce340205a5f62b45c7c
 	sha256sums = 5228b4f923eab7784952a0fd6da895e7bff2f80a7f91c4a7c6350491dfdbb2e8

Comment

The change only adds a new source file to .SRCINFO with its corresponding SHA-256 and bumps pkgrel. From the surrounding PKGBUILD context, the new file is a sudoers drop-in granting the pihole user passwordless sudo for /usr/bin/pihole, but that file is already present in the package sources and the PKGBUILD already installs it into /etc/sudoers.d with restrictive permissions. This .SRCINFO-only update does not introduce new execution paths, network fetches, or packaging changes beyond metadata synchronization. The main security-relevant content is the existing sudoers rule, but it is not newly introduced by this diff hunk.

@@ -41,5 +42,6 @@ pkgbase = pi-hole-core
 	sha256sums = ff507ce58c9492cce57e947696e1b814469fc2d856a1e303c6e68f98c62ebf46
 	sha256sums = 27288535f7d5e18c73b9fe13aa0bcd78a2fd935cb2e978c70d51b0439c87844f
 	sha256sums = 69a71c29dbe42ef0cbd3655fd7ce5cf04e8a77e27a5b2c3a1fcce0b544223309
+	sha256sums = 4bda286d2776edf43065e49474c156548b7e4cee26603cbba9c67602b3c8a3b5
 
 pkgname = pi-hole-core

Comment

This change only bumps pkgrel from 5 to 6 in PKGBUILD with no other content changes. There are no source, build, install, dependency, or packaging logic modifications to introduce supply-chain, privilege, or persistence risks. Based on the provided diff, this is a no-op packaging revision.

@@ -5,7 +5,7 @@
 pkgname=pi-hole-core
 _pkgname=pi-hole
 pkgver=6.4.3
-pkgrel=5
+pkgrel=6
 pkgdesc='The Pi-hole is an advertising-aware DNS/Web server. Arch adaptation for lan wide DNS server.'
 arch=('any')
 license=('EUPL-1.2')

Comment

The change only moves the sudoers policy from an upstream template inside the extracted source tree to a separately shipped file in the PKGBUILD, with a matching checksum update. The content of the sudoers rule is unchanged: it grants the `pihole` user passwordless sudo for `/usr/bin/pihole`, which is a privilege escalation mechanism, but it was already present before this change and is not newly introduced by the diff. I do not see any added network fetches, obfuscation, persistence, or other new attack surface in this hunk.

@@ -27,16 +27,18 @@ source=($pkgname-$pkgver.tar.gz::https://github.com/$_pkgname/$_pkgname/archive/
 	    $_pkgname-logtruncate.timer
 	    mimic_basic-install.sh
 	    piholeDebug.sh
+	    pihole.sudo
 )
 sha256sums=('defe72687f90af45c3e735aa9bfabc01d1d75a3b3d6197e92c6216971859e57e'
-            'cc3b1864234eae8b5501cc4ef53645f44d3c6cb98c1e60f2e94ae173ab586fc2'
+            '8c03411068b01c83d2128c00d641e6e11278c3fc2032f59a847c4136fae09097'
             'd09f9d10ebdfb6db24d4e1abff8cd09519a7b3f3878ef3974c26aa6838f74e7e'
             '9b72d7769036f8f4bb7121968d2ae4bdba427e4b16787ce340205a5f62b45c7c'
             '5228b4f923eab7784952a0fd6da895e7bff2f80a7f91c4a7c6350491dfdbb2e8'
             '88e3c78bbeaf5dc1100df65202ded8207877954a96bdf1b0ab3d9990d9fa759f'
             'ff507ce58c9492cce57e947696e1b814469fc2d856a1e303c6e68f98c62ebf46'
             '27288535f7d5e18c73b9fe13aa0bcd78a2fd935cb2e978c70d51b0439c87844f'
-            '69a71c29dbe42ef0cbd3655fd7ce5cf04e8a77e27a5b2c3a1fcce0b544223309')
+            '69a71c29dbe42ef0cbd3655fd7ce5cf04e8a77e27a5b2c3a1fcce0b544223309'
+            '4bda286d2776edf43065e49474c156548b7e4cee26603cbba9c67602b3c8a3b5')
 
 prepare() {
   cd "$srcdir"/"$_pkgname"-"$pkgver"

Comment

The change only switches the sudoers file installation from the upstream template inside the extracted source tree to a packaged local file `pihole.sudo`, and adds that file to `source=()` with a matching checksum. The new sudoers rule is still the same narrowly scoped NOPASSWD entry for `/usr/bin/pihole`, so this does not introduce a new privilege escalation path beyond the package’s existing design. No network fetches, shell execution, or other suspicious packaging behavior were added in this diff. Risk is low, though note that the package already ships a sudoers rule granting passwordless root execution of the pihole command, which is an inherent trust decision rather than a new issue in this change.

@@ -68,7 +70,7 @@ package() {
   cp -dpr --no-preserve=ownership $_pkgname-$pkgver/advanced/Scripts/database_migration "$pkgdir"/opt/pihole/
 
   install -dm750 "$pkgdir"/etc/sudoers.d
-  install -Dm440 $_pkgname-$pkgver/advanced/Templates/pihole.sudo "$pkgdir"/etc/sudoers.d/pihole
+  install -Dm440 pihole.sudo "$pkgdir"/etc/sudoers.d/pihole
 
   install -Dm644 pi-hole.tmpfile "$pkgdir"/usr/lib/tmpfiles.d/pi-hole.conf
 

Comment

The change removes a sudoers template that would have granted the `pihole` user passwordless root execution of `/usr/bin/pihole`. That is a meaningful security improvement: it eliminates an unnecessary privilege-escalation path and reduces the risk of abuse if the `pihole` account or the `pihole` command were compromised. No new execution, persistence, network, or packaging red flags are introduced by this hunk.

@@ -125,11 +125,6 @@ diff -uprN pi-hole-6.3/advanced/Templates/logrotate pi-hole-6.3.cust/advanced/Te
      # su #
      weekly
      create 640 pihole pihole
-diff -uprN pi-hole-6.3/advanced/Templates/pihole.sudo pi-hole-6.3.cust/advanced/Templates/pihole.sudo
---- pi-hole-6.3/advanced/Templates/pihole.sudo	1970-01-01 01:00:00.000000000 +0100
-+++ pi-hole-6.3.cust/advanced/Templates/pihole.sudo	2025-11-27 23:02:14.748944993 +0100
-@@ -0,0 +1 @@
-+pihole ALL=(ALL:ALL) NOPASSWD: /usr/bin/pihole
 diff -uprN pi-hole-6.3/gravity.sh pi-hole-6.3.cust/gravity.sh
 --- pi-hole-6.3/gravity.sh	2025-11-27 19:10:51.000000000 +0100
 +++ pi-hole-6.3.cust/gravity.sh	2025-11-27 23:02:14.734281312 +0100

Comment

The new sudoers rule grants the unprivileged `pihole` account passwordless sudo to run `/usr/bin/pihole` as any user/group. This is a significant privilege boundary change because the effective security now depends entirely on what the `pihole` CLI can do. If that command supports subcommands that modify system configuration, invoke helpers, or otherwise reach privileged operations, this becomes a root escalation path for any process able to act as the `pihole` user. The change is also broad (`ALL=(ALL:ALL)` and `NOPASSWD`) rather than narrowly scoped to a specific safe subcommand. I did not see evidence in this diff alone of an immediate exploit, but the rule is permissive enough to be risky and should be tightly constrained or justified by upstream documentation.

@@ -0,0 +1 @@
+pihole ALL=(ALL:ALL) NOPASSWD: /usr/bin/pihole