Review Results

Comment

The only change in this diff is a pkgrel bump from 1 to 2 in .SRCINFO. This is metadata-only and does not alter sources, checksums, build steps, dependencies, install scripts, or shipped artifacts. No security-relevant behavior changes are introduced by this diff alone.

@@ -1,7 +1,7 @@
 pkgbase = swift-bin
 	pkgdesc = Binary builds of the Swift programming language
 	pkgver = 6.4.0
-	pkgrel = 1
+	pkgrel = 2
 	url = https://www.swift.org/
 	arch = x86_64
 	arch = aarch64

Comment

The change only bumps pkgrel from 1 to 2 in PKGBUILD. No sources, checksums, build steps, install scripts, dependencies, or packaging behavior changed. This is a metadata-only rebuild/release bump with no security impact visible in the provided diff.

@@ -5,7 +5,7 @@
 
 pkgname=swift-bin
 pkgver=6.4.0
-pkgrel=1
+pkgrel=2
 pkgdesc="Binary builds of the Swift programming language"
 arch=('x86_64' 'aarch64')
 url="https://www.swift.org/"

Comment

The change is a narrow path refactor inside package(): it introduces a local variable `_swift_root="/usr/lib/swift/usr"` and uses it in the `find` invocation instead of the previously hardcoded `/usr/lib/swift`. This does not add any new network access, privilege escalation, persistence, or installation behavior; it only changes which packaged files are scanned for ELF stripping/processing. I do note the path change appears to be a packaging/layout adjustment, but there is no evidence of malicious intent or security impact in this diff alone.

@@ -22,8 +22,9 @@ sha256sums_x86_64=('50863678e3bafd91fcbc94c0bb76610bab37c1ee01e335fc7d8616904e03
 sha256sums_aarch64=('641931cd5fdd4d17e47b75b959ba21d67d0f5749cb7d14c854971b49e23bfbd2')
 
 package() {
+  _swift_root="/usr/lib/swift/usr"
   find_elf_only() {
-    find "${pkgdir}/usr/lib/swift" \
+    find "${pkgdir}${_swift_root}" \
       -executable -type f \
       '(' -path '*/bin/*' -o -name '*.so*' ')' \
       -not '(' -name '*.py' -o -name 'hwasan_symbolize' ')' \

Comment

The change is low risk and appears to be a packaging-path fix only. It relocates the installed Swift tree from /usr/lib/swift to /usr/lib/swift/usr and updates internal symlinks and ld.so.conf.d accordingly. There are no new network fetches, privilege escalations, post-install scripts, or suspicious binaries/patches introduced by this diff. The only notable issue is that the new ld.so.conf line is single-quoted, so it will literally write '${_swift_root}/lib/swift/linux' instead of expanding the variable, which looks like a packaging bug rather than a security problem. Overall this does not introduce a meaningful security risk.

@@ -34,13 +35,13 @@ package() {
   if [[ $CARCH == "aarch64" ]]; then
     _archsuffix="-aarch64"
   fi
-  mkdir -p "${pkgdir}/usr/lib/swift"
-  cp -Ppr "${srcdir}/swift-$pkgver-RELEASE-ubi10${_archsuffix}"/usr/* "${pkgdir}/usr/lib/swift"
+  mkdir -p "${pkgdir}${_swift_root}"
+  cp -Ppr "${srcdir}/swift-$pkgver-RELEASE-ubi10${_archsuffix}"/usr/* "${pkgdir}${_swift_root}"
 
   # Symlink the desired binaries to /usr/bin
   mkdir -p "${pkgdir}/usr/bin"
   for bin in sourcekit-lsp swift swiftc; do
-    ln -s "/usr/lib/swift/bin/$bin" "${pkgdir}/usr/bin/$bin"
+    ln -s "${_swift_root}/bin/$bin" "${pkgdir}/usr/bin/$bin"
   done
 
   # Patch the binaries to use the changed ncurses names

Comment

The change only alters the ld.so.conf.d entry from a hardcoded /usr/lib/swift/lib/swift/linux path to the package variable expansion '${_swift_root}/lib/swift/linux'. This is a packaging-path correction, not a code-execution or persistence change. It does not introduce network access, privilege escalation, suspicious scripts, or new installed artifacts beyond the existing config file. No security concern is evident from this diff alone.

@@ -51,5 +52,5 @@ package() {
   find_elf_only -exec "${patchelf[@]}" {} \;
 
   install -dm755 "${pkgdir}/etc/ld.so.conf.d"
-  echo '/usr/lib/swift/lib/swift/linux' >> "${pkgdir}/etc/ld.so.conf.d/swift.conf"
+  echo '${_swift_root}/lib/swift/linux' >> "${pkgdir}/etc/ld.so.conf.d/swift.conf"
 }