AUR AI Reviewer

Review Results

Version #2957 of mailspring-bin · commit 213c1f0da34e · status Reviewed

Risk 0/5 · Safe .SRCINFO
Result #5623

Comment

The only change in this .SRCINFO hunk is a version bump from 1.26.1 to 1.26.2. There are no changes to source URLs, checksums, build steps, dependencies, install scripts, or packaging behavior in the reviewed diff. On its face this does not introduce any new security risk; any risk would depend on the upstream release contents, which are not modified here and are outside the scope of this single metadata-only change.

@@ -1,6 +1,6 @@
 pkgbase = mailspring-bin
 	pkgdesc = A beautiful, fast and fully open source mail client.
-	pkgver = 1.26.1
+	pkgver = 1.26.2
 	pkgrel = 1
 	url = https://getmailspring.com/
 	arch = aarch64
Risk 0/5 · Safe .SRCINFO
Result #5624

Comment

The change is a routine version bump in .SRCINFO for a binary package: it updates the provided version and the upstream GitHub release URLs/checksums for the new release. The added source entry for mailspring.js is consistent with the package metadata and there are no signs of new build-time code execution, privilege escalation, or suspicious external fetches beyond the official upstream release artifacts. One minor anomaly is the duplicated sha256sums line in .SRCINFO, but that appears to be a metadata formatting issue rather than a security concern in the reviewed diff.

@@ -10,13 +10,15 @@ pkgbase = mailspring-bin
 	depends = krb5
 	depends = db5.3
 	depends = tidy
-	provides = mailspring=1.26.1
+	provides = mailspring=1.26.2
 	conflicts = mailspring
+	source = mailspring.js
 	source = mailspring.sh
-	sha256sums = a175afba52c8032d84ffe4277eec56f2e4868ae55692a741266b806b98b89953
-	source_aarch64 = mailspring-1.26.1-aarch64.rpm::https://github.com/Foundry376/Mailspring/releases/download/1.26.1/mailspring-1.26.1-0.1.aarch64.rpm
-	sha256sums_aarch64 = 1d56ca1ee2a68532a931a157941e33a74956d3aa85678480e2c3e632761b8619
-	source_x86_64 = mailspring-1.26.1-x86_64.rpm::https://github.com/Foundry376/Mailspring/releases/download/1.26.1/mailspring-1.26.1-0.1.x86_64.rpm
-	sha256sums_x86_64 = 2e05fc97dfa9b5b0e99a77953db5ab275de0bfefda2a1762534db9da2abeb3ae
+	sha256sums = 562897be8a17076176f8d985c0d7bc1c685f2e7c9b3a932339ce015963243627
+	sha256sums = 0f4675ddc96a032accf82723c7b6b66007bafd18aa8d919b61e983a68fd25328
+	source_aarch64 = mailspring-1.26.2-aarch64.rpm::https://github.com/Foundry376/Mailspring/releases/download/1.26.2/mailspring-1.26.2-0.1.aarch64.rpm
+	sha256sums_aarch64 = 31ec6250dfc11a5c48a08ca26bd469b864ef92ba57b4fef2e2401e4fbfb73e39
+	source_x86_64 = mailspring-1.26.2-x86_64.rpm::https://github.com/Foundry376/Mailspring/releases/download/1.26.2/mailspring-1.26.2-0.1.x86_64.rpm
+	sha256sums_x86_64 = 94eea2db420faae4ee6a05ee65c7a6b7fa21ee19972a51bef67c02368eb30621
 
 pkgname = mailspring-bin
Risk 0/5 · Safe PKGBUILD
Result #5625

Comment

The change only bumps pkgver from 1.26.1 to 1.26.2 in PKGBUILD. No source URLs, checksums, build steps, install scripts, permissions, or packaging logic were altered in the provided diff, so there is no new security concern visible from this change alone.

@@ -1,7 +1,7 @@
 # Maintainer: zxp19821005 <zxp19821005 at 163 dot com>
 pkgname=mailspring-bin
 _pkgname=Mailspring
-pkgver=1.26.1
+pkgver=1.26.2
 _electronversion=44
 pkgrel=1
 pkgdesc="A beautiful, fast and fully open source mail client."
Risk 0/5 · Safe PKGBUILD
Result #5626

Comment

The change is low risk. It adds a new local source file (mailspring.js) with a matching checksum and installs it into /usr/lib, while also updating the launcher to require it. I inspected the new JS helper: it only adjusts Electron runtime paths/environment and wraps some fs calls to redirect resource lookups into the packaged app directory. There are no network calls, privilege escalation, persistence mechanisms, or writes outside $pkgdir. The package still fetches only the upstream RPMs over HTTPS with pinned versioned URLs and checksum verification. Overall this looks like a packaging/runtime compatibility update rather than a security regression.

@@ -20,12 +20,16 @@ depends=(
     'db5.3'
     'tidy'
 )
-source=("${pkgname%-bin}.sh")
+source=(
+    "${pkgname%-bin}.js"
+    "${pkgname%-bin}.sh"
+)
 source_aarch64=("${pkgname%-bin}-${pkgver}-aarch64.rpm::${_ghurl}/releases/download/${pkgver}/${pkgname%-bin}-${pkgver}-0.1.aarch64.rpm")
 source_x86_64=("${pkgname%-bin}-${pkgver}-x86_64.rpm::${_ghurl}/releases/download/${pkgver}/${pkgname%-bin}-${pkgver}-0.1.x86_64.rpm")
-sha256sums=('a175afba52c8032d84ffe4277eec56f2e4868ae55692a741266b806b98b89953')
-sha256sums_aarch64=('1d56ca1ee2a68532a931a157941e33a74956d3aa85678480e2c3e632761b8619')
-sha256sums_x86_64=('2e05fc97dfa9b5b0e99a77953db5ab275de0bfefda2a1762534db9da2abeb3ae')
+sha256sums=('562897be8a17076176f8d985c0d7bc1c685f2e7c9b3a932339ce015963243627'
+            '0f4675ddc96a032accf82723c7b6b66007bafd18aa8d919b61e983a68fd25328')
+sha256sums_aarch64=('31ec6250dfc11a5c48a08ca26bd469b864ef92ba57b4fef2e2401e4fbfb73e39')
+sha256sums_x86_64=('94eea2db420faae4ee6a05ee65c7a6b7fa21ee19972a51bef67c02368eb30621')
 _get_app_dir() {
 	find "${srcdir}" -type f -name "resources.pak" ! -path "*/node_modules/*" -printf '%h\n' 2>/dev/null \
 		| while read -r d; do [[ -d "${d}/resources" ]] && { echo "$d"; return 0; }; done
Risk 0/5 · Safe PKGBUILD
Result #5627

Comment

The change is low risk. It adds a second source file (.js) to the package, updates checksums, and ensures both the launcher shell script and JS helper are patched and installed. I did not find any new network fetches, privilege escalation, persistence mechanisms, or suspicious install-time behavior in the diff. The only notable concern is that a new source file is introduced, but it is fetched via the normal source array and verified by sha256, so integrity is preserved.

@@ -53,7 +57,7 @@ prepare() {
     sed -i -e "
         s/@electronversion@/${_electronversion}/g
         s/@appname@/${pkgname%-bin}/g
-    " "${srcdir}/${pkgname%-bin}.sh"
+    " "${srcdir}/${pkgname%-bin}.sh" "${srcdir}/${pkgname%-bin}.js"
     _check_electron_version
     _desktop_env="$(_get_current_desktop_env)"
     if [ "${_desktop_env}" = "gnome" ];then
Risk 1/5 · Low PKGBUILD
Result #5628

Comment

The change adds a new shipped JavaScript helper into /usr/lib and wires it into the launcher via --require. I inspected the added file: it only adjusts Electron app path handling and redirects filesystem lookups back into the packaged app directory. There are no network calls, privilege changes, persistence mechanisms, or suspicious downloads in the diff. The packaging change itself is consistent with the launcher update and remains confined to $pkgdir. Risk is low, though this is a runtime hook that deserves scrutiny because it executes on every launch.

@@ -63,7 +67,7 @@ prepare() {
 }
 package() {
     install -Dm755 "${srcdir}/${pkgname%-bin}.sh" "${pkgdir}/usr/bin/${pkgname%-bin}"
-    install -Dm755 -d "${pkgdir}/usr/lib/${pkgname%-bin}"
+    install -Dm644 "${srcdir}/${pkgname%-bin}.js" -t "${pkgdir}/usr/lib/${pkgname%-bin}"
 	cp -a "$(_get_app_dir)/resources/." "${pkgdir}/usr/lib/${pkgname%-bin}/"
     install -Dm644 "${srcdir}/usr/share/applications/${_pkgname}.desktop" -t "${pkgdir}/usr/share/applications"
     find "${srcdir}" -type f \( -name "*.png" -o -name "*.svg" \) -path "*share/icons/*" | while read -r _i; do
Risk 1/5 · Low mailspring.js
Result #5629

Comment

The new mailspring.js is a preload-style runtime override that rewrites Electron's resourcesPath and monkey-patches fs/fs.promises to transparently redirect reads from the packaged Electron resources directory into an app directory. This is a broad filesystem interception mechanism, but in the context of a desktop app launcher it appears intended to make the packaged app work correctly when installed under Arch's packaging layout. I do not see network access, privilege escalation, persistence, or hidden execution paths introduced here. The main risk is functional: it changes file resolution globally and could affect any code that relies on resourcesPath or fs path semantics, but the redirect is constrained to paths under the Electron resources prefix and only when the target exists. Overall this looks like a packaging compatibility shim rather than a malicious backdoor.

@@ -0,0 +1,109 @@
+'use strict';
+try {
+	const path = require('path');
+	const fs = require('fs');
+	const resolveAppDir = () => {
+		const argv = process.argv || [];
+		for (let i = 0; i < argv.length; i++) {
+			if (argv[i] === '--app' && i + 1 < argv.length) {
+				return path.dirname(argv[i + 1]);
+			}
+			if (argv[i].startsWith('--app=') && argv[i].length > 6) {
+				return path.dirname(argv[i].slice(6));
+			}
+		}
+		const entry = argv[1];
+		if (typeof entry === 'string' && entry.startsWith('/usr/lib/')) {
+			const m = entry.match(/^\/usr\/lib\/([^/]+)\//);
+			if (m) {
+				const candidate = '/usr/lib/' + m[1];
+				for (const probe of ['app.asar', 'app', 'app.asar.unpacked']) {
+					if (fs.existsSync(path.join(candidate, probe))) {
+						return candidate;
+					}
+				}
+			}
+		}
+		if (process.env._APPDIR) {
+			return process.env._APPDIR;
+		}
+		return '/usr/lib/@appname@';
+	};
+	const appDir = resolveAppDir();
+	if (process.resourcesPath !== appDir) {
+		Object.defineProperty(process, 'resourcesPath', {
+			value: appDir,
+			writable: false,
+			configurable: true,
+			enumerable: true,
+		});
+	}
+	if (!process.env.ELECTRON_IS_DEV && !process.env.NODE_ENV) {
+		const argv = process.argv || [];
+		let appPath = null;
+		for (let i = 0; i < argv.length; i++) {
+			if (argv[i] === '--app' && i + 1 < argv.length) {
+				appPath = argv[i + 1];
+				break;
+			}
+			if (argv[i].startsWith('--app=') && argv[i].length > 6) {
+				appPath = argv[i].slice(6);
+				break;
+			}
+		}
+		if (appPath) {
+			const isAsar = appPath.endsWith('.asar') && fs.existsSync(appPath);
+			const isAppDir = fs.existsSync(appPath) && fs.statSync(appPath).isDirectory();
+			const isUnpacked = appPath.endsWith('.asar.unpacked') && fs.existsSync(appPath);
+			if (isAsar || isAppDir || isUnpacked) {
+				console.log('[app-override] packaged app detected, forcing production env');
+				process.env.ELECTRON_IS_DEV = '0';
+				process.env.NODE_ENV = 'production';
+			}
+		}
+	}
+	if (!process.env._APPDIR_NO_FS_REDIRECT) {
+		const electronResources = path.join(path.dirname(process.execPath), 'resources');
+		if (electronResources !== appDir && fs.existsSync(appDir)) {
+			let topLevel = null;
+			try {
+				topLevel = new Set(fs.readdirSync(appDir));
+			} catch (e) {
+				topLevel = null;
+			}
+			const debug = !!process.env._APPDIR_DEBUG;
+			if (topLevel) {
+				const prefix = electronResources + path.sep;
+				const redirect = (p) => {
+					if (typeof p !== 'string' || !p.startsWith(prefix)) return p;
+					const rel = p.slice(prefix.length);
+					if (rel.split(path.sep).includes('..')) return p;
+					const first = rel.split(path.sep)[0];
+					if (!topLevel.has(first)) return p;
+					const target = appDir + path.sep + rel;
+					if (debug) console.log('[app-override] fs redirect: ' + p + ' -> ' + target);
+					return target;
+				};
+				const wrap = (obj, name) => {
+					const orig = obj[name];
+					if (typeof orig !== 'function') return;
+					obj[name] = function (p, ...rest) {
+						return orig.call(this, redirect(p), ...rest);
+					};
+				};
+				for (const name of [
+					'readFile', 'readFileSync', 'existsSync', 'createReadStream',
+					'statSync', 'lstatSync', 'accessSync', 'openSync',
+					'realpathSync', 'readdirSync', 'opendirSync',
+				]) wrap(fs, name);
+				for (const name of [
+					'readFile', 'stat', 'lstat', 'access', 'open',
+					'realpath', 'readdir', 'opendir',
+				]) wrap(fs.promises, name);
+			}
+		}
+	}
+} catch (e) {
+	console.error('[app-override] WARNING: override threw: ' + e.message +
+		'; resourcesPath-relative lookups (product.json, application-icons) will fail.');
+}
\ No newline at end of file
Risk 0/5 · Safe mailspring.sh
Result #5630

Comment

The change removes the fallback assignment of _RUNNAME to the packaged placeholder path when neither ${_APPDIR}/app nor ${_APPDIR}/app.asar.unpacked exists. This is a small behavior change in a launcher script, but it does not introduce any new execution, network access, privilege escalation, or persistence mechanism. The script still only selects among local application directories and then proceeds with the existing sandbox/root checks. Security impact appears negligible; at worst this could affect startup behavior if the expected directory layout is missing, but it does not create a new attack surface.

@@ -9,8 +9,6 @@ elif [[ -d "${_APPDIR}/app" ]]; then
 	_RUNNAME="${_APPDIR}/app"
 elif [[ -d "${_APPDIR}/app.asar.unpacked" ]]; then
 	_RUNNAME="${_APPDIR}/app.asar.unpacked"
-else
-	_RUNNAME="${_APPDIR}/@runname@"
 fi
 _SANDBOX_ARG=()
 if [[ "${EUID}" -eq 0 ]] && [[ "${ELECTRON_RUN_AS_NODE}" != "1" ]]; then
Risk 0/5 · Safe mailspring.sh
Result #5631

Comment

The change is low risk overall. It only updates a fallback log message from Chinese to English and adds an explicit `--require "${_APPDIR}/@appname@.js"` argument to the Electron launch command. That `--require` points at the packaged app’s own JS entrypoint inside the application directory, which is consistent with normal Electron packaging and does not introduce network access, privilege escalation, or persistence behavior by itself. No suspicious downloads, shell execution, or system modifications are introduced in this hunk.

@@ -32,8 +30,8 @@ auto)
 	:
 	;;
 *)
-	echo "${0##*/}: 未知 Ozone 平台 '${_OZONE_HINT}' (可用: x11|wayland|auto), 按 x11 处理" >&2
+	echo "${0##*/}: Unknown Ozone platform '${_OZONE_HINT}' (available: x11|wayland|auto), falling back to x11" >&2
 	_OZONE_ARG=("--ozone-platform=x11")
 	;;
 esac
-exec electron@electronversion@ "${_SANDBOX_ARG[@]}" "${_OZONE_ARG[@]}" --app "${_RUNNAME}" "$@"
\ No newline at end of file
+exec electron@electronversion@ "${_SANDBOX_ARG[@]}" "${_OZONE_ARG[@]}" --require "${_APPDIR}/@appname@.js" --app "${_RUNNAME}" "$@"
\ No newline at end of file