Review Results

Comment

The change only updates the generated pkgver in .SRCINFO for mesa-git, reflecting a newer upstream git snapshot. There are no source URL changes, no new build steps, no install scripts, and no packaging metadata changes that would introduce persistence, privilege escalation, or integrity issues. Based on the provided diff, this is a routine version bump with no security red flags.

@@ -1,6 +1,6 @@
 pkgbase = mesa-git
 	pkgdesc = an open-source implementation of the OpenGL specification, git version
-	pkgver = 26.3.0_devel.228038.f0bcf544881.d41d8cd
+	pkgver = 26.3.0_devel.231264.0ad3997b86e.d41d8cd
 	pkgrel = 1
 	url = https://www.mesa3d.org
 	arch = x86_64

Comment

The change is low risk. It only updates .SRCINFO metadata to add two makedepends/dependencies and a new git source entry for venus-protocol, which is an upstream Mesa-related repository over HTTPS. There is no evidence here of shell execution, privilege escalation, or suspicious external downloads beyond normal source metadata. The duplicated source/checksum lines appear to be a .SRCINFO formatting artifact rather than an introduced payload, and the actual package logic is not changed in this diff.

@@ -22,6 +22,8 @@ pkgbase = mesa-git
 	makedepends = wayland-protocols
 	makedepends = python-packaging
 	makedepends = python-pyaml
+	makedepends = libdisplay-info
+	makedepends = libpng
 	makedepends = llvm
 	makedepends = clang
 	makedepends = libclc

Comment

The change is low risk overall. It updates .SRCINFO metadata to reflect new build/runtime dependencies (libdisplay-info, libpng) and a newer mesa-git pkgver, and adds a new git source for venus-protocol. The source URLs are HTTPS and point to upstream projects, with no signs of typosquatting, shell execution, privilege escalation, or external downloads outside declared sources. The duplicated source/checksum lines appear to be a metadata generation artifact in .SRCINFO rather than an executable change. No high-confidence security issue is evident from this diff alone.

@@ -51,7 +53,8 @@ pkgbase = mesa-git
 	depends = glibc
 	depends = zlib
 	depends = xcb-util-keysyms
-	depends = libLLVM.so=22.1-64
+	depends = libdisplay-info
+	depends = libpng
 	depends = clang
 	depends = libclc
 	depends = spirv-llvm-translator

Comment

The change is low risk overall. It updates .SRCINFO metadata to match the package’s current build inputs: a newer Mesa git snapshot, added makedepends/depends for libdisplay-info and libpng, and an added venus-protocol source entry. The only notable issue is that the diff shows a duplicated venus-protocol source and duplicated checksum lines in .SRCINFO, but this is a metadata inconsistency rather than a security problem; the source URL is HTTPS and points to the expected upstream project, with no new suspicious hosts, scripts, or privilege-related changes. I don’t see evidence of malicious build-time execution or persistence mechanisms in this change.

@@ -88,6 +91,7 @@ pkgbase = mesa-git
 	options = !lto
 	options = !debug
 	source = mesa::git+https://gitlab.freedesktop.org/mesa/mesa.git#branch=main
+	source = venus-protocol-1.1::git+https://gitlab.freedesktop.org/virgl/venus-protocol.git
 	source = LICENSE
 	source = venus-protocol-1.1::git+https://gitlab.freedesktop.org/virgl/venus-protocol.git
 	source = rustc-hash-2.1.1.tar.gz::https://static.crates.io/crates/rustc-hash/2.1.1/download

Comment

The change is limited to .SRCINFO metadata and appears to be a mechanical regeneration/update: pkgver bump, added makedepends/depends entries, and duplicated checksum lines corresponding to the new source ordering. I do not see any malicious indicators such as new executable scripts, network-fetching build logic, privilege escalation, or suspicious sources. The only notable issue is the duplicated source/checksum entries in .SRCINFO, which looks like a packaging metadata inconsistency rather than a security problem.

@@ -97,6 +101,7 @@ pkgbase = mesa-git
 	source = paste-1.0.14.tar.gz::https://static.crates.io/crates/paste/1.0.14/download
 	source = syn-2.0.87.tar.gz::https://static.crates.io/crates/syn/2.0.87/download
 	sha256sums = SKIP
+	sha256sums = SKIP
 	sha256sums = 7fdc119cf53c8ca65396ea73f6d10af641ba41ea1dd2bd44a824726e01c8b3f2
 	sha256sums = SKIP
 	sha256sums = 357703d41365b4b27c590e3ed91eabb1b663f07c4c084095e60cbed4362dff0d

Comment

The change only adds a duplicate `b2sums = SKIP` entry in `.SRCINFO`. This does not introduce new sources, code execution, privilege changes, or packaging behavior; it is at most a metadata inconsistency and has no security impact on the package contents. No malicious indicators are present in the reviewed hunk.

@@ -106,6 +111,7 @@ pkgbase = mesa-git
 	sha256sums = de3145af08024dea9fa9914f381a17b8fc6034dfb00f3a84013f7ff43f29ed4c
 	sha256sums = 25aa4ce346d03a6dcd68dd8b4010bcb74e54e62c90c573f394c46eae99aba32d
 	b2sums = SKIP
+	b2sums = SKIP
 	b2sums = cc60238726b35133b5b729fb4ed1e76e04136588533615d84b4a54656d5b41727d5e7ff06ef4de3eb102eed6669d6c5c5cb8ac9fbdf6fc25aa477877c5c3ba87
 	b2sums = SKIP
 	b2sums = 7a1b3b82bbbf6a123512815c3e8f068a17890cbbb8b68e88a5a492f62469942fadd776207eebd913052a1c06e1fd37a549e86526b9fc8f08b9ca7cb0044ac16b

Comment

The change only bumps pkgver in PKGBUILD to a newer Mesa git snapshot identifier. No build logic, sources, checksums, install scripts, permissions, or dependency changes are introduced. This is a routine version update with no security-relevant behavior visible in the provided diff.

@@ -12,7 +12,7 @@
 
 pkgname=mesa-git
 pkgdesc="an open-source implementation of the OpenGL specification, git version"
-pkgver=26.3.0_devel.228038.f0bcf544881.d41d8cd
+pkgver=26.3.0_devel.231264.0ad3997b86e.d41d8cd
 pkgrel=1
 arch=('x86_64')
 makedepends=(

Comment

The PKGBUILD changes are low risk. The added makedepends/depends (`libdisplay-info`, `libpng`) are standard libraries from official repos, and the new source entry is another git dependency from the upstream Mesa/virgl GitLab namespace over HTTPS. The build flag change swaps Vulkan layers from `anti-lag` to `screenshot` and `vram-report-limit`, but these are Mesa-provided layers, not an obvious persistence or privilege-escalation mechanism. The package() cleanup also removes the newly installed `mesa-screenshot-control.py` helper from /usr/bin, which is consistent with the existing removal of `mesa-overlay-control.py` and does not introduce a new attack surface. No suspicious network fetches, shell execution, sudo, or system-wide modifications were introduced in this diff.

@@ -33,6 +33,8 @@ makedepends=(
     'wayland-protocols'
     'python-packaging'
     'python-pyaml'
+    'libdisplay-info'
+    'libpng'
 )
 depends=(
     'libdrm'

Comment

Risk score 1/5. The change is mostly dependency and build-flag maintenance for mesa-git: it adds libdisplay-info/libpng, updates the vendored source list, drops an explicit libLLVM soname pin, swaps Vulkan layers, and removes an extra installed control script. I do not see any new network fetches outside source=(), privilege escalation, persistence, or suspicious install-script behavior. The duplicated venus-protocol source entry appears to be a packaging mistake rather than a security issue, and the new dependencies are standard libraries from the distro.

@@ -57,6 +59,8 @@ depends=(
     'glibc'
     'zlib'
     'xcb-util-keysyms'
+    'libdisplay-info'
+    'libpng'
 )
 optdepends=('opengl-man-pages: for the OpenGL API man pages')
 provides=(

Comment

Low-risk packaging update. The added venus-protocol source is another git dependency from the same upstream ecosystem, but it is not pinned to a commit/tag and is duplicated in the source array, which is a reproducibility/integrity smell rather than an obvious backdoor. The rest of the change is routine dependency/build-option churn: adding libdisplay-info/libpng, dropping an explicit libLLVM soname pin, switching Vulkan layers, and removing an installed helper script from the package. I do not see any curl|bash, privilege escalation, systemd/persistence, or suspicious install-time behavior in this diff.

@@ -94,10 +98,12 @@ license=('custom')
 # https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29275
 source=(
     'mesa::git+https://gitlab.freedesktop.org/mesa/mesa.git#branch=main'
+    'venus-protocol-1.1::git+https://gitlab.freedesktop.org/virgl/venus-protocol.git'
     'LICENSE'
     "venus-protocol-1.1::git+https://gitlab.freedesktop.org/virgl/venus-protocol.git"
 )
 sha256sums=('SKIP'
+            'SKIP'
             '7fdc119cf53c8ca65396ea73f6d10af641ba41ea1dd2bd44a824726e01c8b3f2'
             'SKIP'
             '357703d41365b4b27c590e3ed91eabb1b663f07c4c084095e60cbed4362dff0d'

Comment

The change is low risk overall. It updates the Mesa git snapshot, adds/duplicates the venus-protocol source entry and corresponding checksums, adjusts build dependencies, swaps Vulkan layer selection, and removes an extra installed control script. I do not see any suspicious network fetches outside source=(), privilege escalation, shell execution, or persistence mechanisms. The duplicate venus-protocol source line appears to be a packaging mistake rather than a security issue, and the new dependencies are standard libraries. No high-confidence supply-chain or post-install risks are introduced by this diff.

@@ -107,6 +113,7 @@ sha256sums=('SKIP'
             'de3145af08024dea9fa9914f381a17b8fc6034dfb00f3a84013f7ff43f29ed4c'
             '25aa4ce346d03a6dcd68dd8b4010bcb74e54e62c90c573f394c46eae99aba32d')
 b2sums=('SKIP'
+        'SKIP'
         'cc60238726b35133b5b729fb4ed1e76e04136588533615d84b4a54656d5b41727d5e7ff06ef4de3eb102eed6669d6c5c5cb8ac9fbdf6fc25aa477877c5c3ba87'
         'SKIP'
         '7a1b3b82bbbf6a123512815c3e8f068a17890cbbb8b68e88a5a492f62469942fadd776207eebd913052a1c06e1fd37a549e86526b9fc8f08b9ca7cb0044ac16b'

Comment

The change removes the explicit runtime dependency on `libLLVM.so=22.1-64` from `mesa-git`'s PKGBUILD while keeping `clang`, `libclc`, and `spirv-llvm-translator` as dependencies. This is a packaging/dependency adjustment, not an execution-path change: it does not introduce network access, privilege escalation, persistence, or bundled binaries. The main effect is to loosen ABI pinning, which could cause runtime breakage if the installed LLVM SONAME is incompatible, but that is a stability issue rather than a security issue. No malicious behavior is evident in this diff hunk.

@@ -214,7 +221,6 @@ case $MESA_WHICH_LLVM in
             'rust-bindgen'
         )
         depends+=(
-            'libLLVM.so=22.1-64'
             'clang'
             'libclc'
             'spirv-llvm-translator'

Comment

The change is low risk. It only adjusts Mesa build options and packaging: swaps Vulkan layers from anti-lag to screenshot/vram-report-limit, adds the corresponding source package entries, removes an explicit libLLVM soname pin, and deletes the installed mesa-screenshot-control.py helper from /usr/bin after packaging. I did not see any new network fetches outside source=(), privilege escalation, suspicious scripts, or unsafe install-time actions. The duplicated venus-protocol source entry appears to be a packaging mistake but not a security issue in itself.

@@ -285,7 +291,7 @@ build () {
         -D valgrind=disabled
         -D video-codecs=all
         -D vulkan-drivers=amd,intel,intel_hasvk,swrast,virtio,nouveau
-        -D vulkan-layers=device-select,intel-nullhw,overlay,anti-lag
+        -D vulkan-layers=device-select,intel-nullhw,overlay,screenshot,vram-report-limit
         -D tools=[]
         -D zstd=enabled
         -D buildtype=plain

Comment

The change only removes an additional installed script, `mesa-screenshot-control.py`, from `${pkgdir}/usr/bin` during packaging. This is a reduction in shipped surface area and does not introduce new build-time execution, network access, privilege changes, or persistence mechanisms. No security concern is evident from this diff hunk alone.

@@ -314,6 +320,7 @@ package() {
     # remove script file from /usr/bin
     # https://gitlab.freedesktop.org/mesa/mesa/issues/2230
     rm "${pkgdir}/usr/bin/mesa-overlay-control.py"
+    rm "${pkgdir}/usr/bin/mesa-screenshot-control.py"
     rmdir "${pkgdir}/usr/bin"
 
     # indirect rendering