Review Results

Comment

The only change in this .SRCINFO hunk is a version bump from 1.3.18.1-3 to 1.3.18.2-1. There are no new sources, build steps, install scripts, permissions changes, or metadata red flags visible in the provided diff. On its face this is a routine package update with no security-relevant behavior introduced by the .SRCINFO change itself.

@@ -1,7 +1,7 @@
 pkgbase = aseprite
 	pkgdesc = Create animated sprites and pixel art
-	pkgver = 1.3.18.1
-	pkgrel = 3
+	pkgver = 1.3.18.2
+	pkgrel = 1
 	url = https://www.aseprite.org/
 	arch = x86_64
 	license = LicenseRef-Aseprite-EULA

Comment

The change is a straightforward version bump in .SRCINFO: it updates the upstream release ZIP from 1.3.18.1 to 1.3.18.2 and pins the accompanying strings git source to a specific commit. The sources remain HTTPS and pinned, and there are no new build-time downloads, scripts, or privilege-related changes visible in this diff. Based on this hunk alone, I do not see a security regression.

@@ -32,12 +32,12 @@ pkgbase = aseprite
 	depends = fontconfig
 	depends = libxcursor
 	depends = libxrandr
-	noextract = Aseprite-v1.3.18.1-Source.zip
+	noextract = Aseprite-v1.3.18.2-Source.zip
 	noextract = skia-m124.tar.gz
-	source = https://github.com/aseprite/aseprite/releases/download/v1.3.18.1/Aseprite-v1.3.18.1-Source.zip
+	source = https://github.com/aseprite/aseprite/releases/download/v1.3.18.2/Aseprite-v1.3.18.2-Source.zip
 	source = skia-m124.tar.gz::https://github.com/aseprite/skia/archive/refs/tags/m124-08a5439a6b.tar.gz
 	source = skia-m124-icu::git+https://chromium.googlesource.com/chromium/deps/icu.git#commit=a0718d4f121727e30b8d52c7a189ebf5ab52421f
-	source = aseprite-strings::git+https://github.com/aseprite/strings.git#commit=417074f649f359f98511fc87a707c276d87f5739
+	source = aseprite-strings::git+https://github.com/aseprite/strings.git#commit=b43be33343efa40c1c4bda00f985b8cd83bddf2a
 	source = desktop.patch
 	source = shared-fmt.patch
 	source = shared-libarchive.patch

Comment

The change is limited to .SRCINFO metadata updates for a new upstream release: version bump, source URL/filename updates, and refreshed checksums/commit pin for the aseprite-strings dependency. The sources remain HTTPS and the VCS source is still pinned to a specific commit, with no new build-time commands, install scripts, or packaging logic introduced by this diff. I do not see any supply-chain red flags in the metadata itself beyond the normal trust shift to a new upstream release artifact.

@@ -50,10 +50,10 @@ pkgbase = aseprite
 	source = shared_libjpeg-turbo.patch
 	source = change_use_of_removed_intrinsic.patch
 	source = fmt-12.2.0-include-format.patch
-	sha256sums = 438e7a1571990383beca761eca829402f14f225e164730eb2edc71b2e9566e58
+	sha256sums = 5729921c1b22f5ad0577a558c8ebf3f3d00a088d82972c45905954eda9c68ab1
 	sha256sums = c2a567d6b8bb933a92615cbdee0de268d02c3a06863337ee8822eedab9ed66ba
 	sha256sums = b52f179a687ef2f91a52b696ab6581f4a37df5e88cb22040fa1ec6567cf0ebb1
-	sha256sums = 883d1b25014deded64c3baa8e680dc3e2e486ca7b9c9116015c3cc557c2af781
+	sha256sums = 80471354d55d785291bb719596d37ec785e01e94a322f127c0f91d2d8b01be0f
 	sha256sums = 8b14e36939e930de581e95abf0591645aa0fcfd47161cf88b062917dbaaef7f9
 	sha256sums = c3591d376180d99ff8001c3d549c0bd18ef5e4d95f1755ccaa8e2fd65dd5d2b3
 	sha256sums = 96d75ecc951712e80734f476511658fcc3c91fc1655fe9a01453c3fc8c2a9274

Comment

The change is low risk. It only bumps pkgver/pkgrel, updates the pinned aseprite-strings git commit and corresponding checksums, and removes an explicit CMAKE_AR/CMAKE_RANLIB override while the build still exports AR=ar and NM=nm. I did not find any new network fetches, unpinned sources, suspicious scripts, or packaging actions outside $pkgdir. The removed CMAKE_AR/CMAKE_RANLIB line could affect build behavior, but it does not introduce a security issue by itself.

@@ -10,10 +10,10 @@
 # Contributor: Jomar Milan <jomarm@jomarm.com>
 
 pkgname=aseprite
-pkgver=1.3.18.1
+pkgver=1.3.18.2
 _skiaver=m124
 _skiahash=08a5439a6b
-pkgrel=3
+pkgrel=1
 pkgdesc='Create animated sprites and pixel art'
 arch=('x86_64')
 url="https://www.aseprite.org/"

Comment

The change only updates the pinned commit for the aseprite-strings git source and refreshes the corresponding checksum/package version metadata. I did not find any new red flags: the source remains HTTPS and pinned to an explicit commit, there are no added build-time network fetches, and no packaging/install-script behavior changed. The removed CMAKE_AR/CMAKE_RANLIB flags are a build configuration change, not a security issue in this diff. Overall this looks like a routine dependency/source refresh with low risk.

@@ -46,7 +46,7 @@ source=("https://github.com/aseprite/aseprite/releases/download/v$pkgver/Aseprit
         # forgive me, I couldn't figure out linker errors.
         # update commit with skia
         skia-$_skiaver-icu::git+https://chromium.googlesource.com/chromium/deps/icu.git#commit=a0718d4f121727e30b8d52c7a189ebf5ab52421f
-		aseprite-strings::git+https://github.com/aseprite/strings.git#commit=417074f649f359f98511fc87a707c276d87f5739
+		aseprite-strings::git+https://github.com/aseprite/strings.git#commit=b43be33343efa40c1c4bda00f985b8cd83bddf2a
         desktop.patch
         shared-fmt.patch
         # Based on https://patch-diff.githubusercontent.com/raw/aseprite/aseprite/pull/2535.patch

Comment

The change only updates two SHA-256 checksums in PKGBUILD, which is consistent with an upstream source/patch refresh. No new sources, URLs, build steps, privilege changes, or packaging logic were introduced in the reviewed hunk. Based on the provided diff alone, there is no evidence of malicious behavior or integrity regression beyond the expected checksum update.

@@ -63,10 +63,10 @@ source=("https://github.com/aseprite/aseprite/releases/download/v$pkgver/Aseprit
         fmt-12.2.0-include-format.patch)
 noextract=("Aseprite-v$pkgver-Source.zip"
            "skia-$_skiaver.tar.gz") # Don't extract Aseprite or skia sources at the root
-sha256sums=('438e7a1571990383beca761eca829402f14f225e164730eb2edc71b2e9566e58'
+sha256sums=('5729921c1b22f5ad0577a558c8ebf3f3d00a088d82972c45905954eda9c68ab1'
             'c2a567d6b8bb933a92615cbdee0de268d02c3a06863337ee8822eedab9ed66ba'
             'b52f179a687ef2f91a52b696ab6581f4a37df5e88cb22040fa1ec6567cf0ebb1'
-            '883d1b25014deded64c3baa8e680dc3e2e486ca7b9c9116015c3cc557c2af781'
+            '80471354d55d785291bb719596d37ec785e01e94a322f127c0f91d2d8b01be0f'
             '8b14e36939e930de581e95abf0591645aa0fcfd47161cf88b062917dbaaef7f9'
             'c3591d376180d99ff8001c3d549c0bd18ef5e4d95f1755ccaa8e2fd65dd5d2b3'
             '96d75ecc951712e80734f476511658fcc3c91fc1655fe9a01453c3fc8c2a9274'

Comment

The change only removes explicit `CMAKE_AR` and `CMAKE_RANLIB` overrides from the CMake invocation in `build()`. This does not introduce new code execution, network access, privilege escalation, or packaging side effects; it simply lets CMake/toolchain defaults choose `ar`/`ranlib`. I don't see any security regression in this hunk.

@@ -157,7 +157,6 @@ build() {
 -DENABLE_UPDATER=OFF -DENABLE_{SCRIPTING,WEBSOCKET}=ON \
 -DLAF_WITH_{EXAMPLES,TESTS}=OFF -DLAF_BACKEND=skia \
 -DSKIA_DIR="$PWD/skia" -DSKIA_LIBRARY_DIR="$_skiadir" \
--DCMAKE_AR=$(command -v ar) -DCMAKE_RANLIB=$(command -v ranlib) \
 -DUSE_SHARED_{CMARK,CURL,FMT,GIFLIB,LIBJPEG_TURBO,ZLIB,LIBPNG,TINYXML,PIXMAN,FREETYPE,HARFBUZZ,LIBARCHIVE,WEBP}=ON \
 -DCMAKE_POLICY_VERSION_MINIMUM=3.5 # workaround
 	cmake --build build