Review Results

Comment

The only change in this .SRCINFO hunk is a pkgrel bump from 1 to 2. No sources, build steps, dependencies, install scripts, or package contents are altered here, so there is no new security impact visible in this diff. This appears to be a metadata-only rebuild/release increment.

@@ -1,7 +1,7 @@
 pkgbase = xrdp
 	pkgdesc = An open source remote desktop protocol (RDP) server
 	pkgver = 0.10.6.1
-	pkgrel = 1
+	pkgrel = 2
 	url = https://github.com/neutrinolabs/xrdp
 	install = xrdp.install
 	arch = i686

Comment

The .SRCINFO update only adds two new packaged files, sysusers.d and tmpfiles.d, and bumps pkgrel. Based on the accompanying PKGBUILD context already reviewed, these files are benign systemd-style account/tmpfiles definitions: they create an xrdp daemon user and ensure /etc/xrdp exists with correct ownership. There is no evidence of network fetches, privilege escalation, persistence, or other malicious behavior in this metadata-only change. Low risk.

@@ -31,7 +31,11 @@ pkgbase = xrdp
 	backup = etc/default/xrdp
 	source = https://github.com/neutrinolabs/xrdp/releases/download/v0.10.6.1/xrdp-0.10.6.1.tar.gz
 	source = arch-config.diff
+	source = sysusers.d
+	source = tmpfiles.d
 	sha256sums = 2f7beb5a3b2529c8d72dc0df9b8cdca31ab0e0c14d1e3421210f5e6ec0ab3b75
-	sha256sums = e0ffce5b1a436990281fe2cc4a3cd9c2840a1dad99740aeaea866ccd9ef56db0
+	sha256sums = c69bdcf3b7f7e5ef1dad8caab0e5a438f0857c1e36a7b2b5aa1e6dcf5e45882c
+	sha256sums = 72f2e1d945d91ddf7034fbe9b64d55e8fbe88d737b0cc3cedd779321b63d05c1
+	sha256sums = d75eb05321d247ce792471a9f5176b1b03cf6166673d6bdd110da8fb7e8bd856
 
 pkgname = xrdp

Comment

This change only bumps pkgrel from 1 to 2 in PKGBUILD with no other modifications. There are no source, build, install-script, dependency, or packaging behavior changes to review, so it does not introduce any new security risk.

@@ -8,7 +8,7 @@
 
 pkgname=xrdp
 pkgver=0.10.6.1
-pkgrel=1
+pkgrel=2
 pkgdesc="An open source remote desktop protocol (RDP) server"
 url="https://github.com/neutrinolabs/xrdp"
 arch=(i686 x86_64 armv6h armv7l aarch64)

Comment

The change is low risk. It only adds two packaged systemd helper files and adjusts the patch strip level for an existing local patch. I inspected the added sysusers/tmpfiles content: it creates an xrdp daemon user with nologin and ensures /etc/xrdp exists with correct ownership, which is expected packaging behavior. The install script still only generates rsakeys locally and removes them on uninstall; no network access, privilege escalation, or suspicious persistence mechanisms were introduced. The only notable change is the patch application path, but it still applies a local source patch already present in the package and does not add new code execution paths.

@@ -26,13 +26,18 @@ backup=('etc/xrdp/sesman.ini'
 	'etc/default/xrdp')
 install="${pkgname}.install"
 source=("https://github.com/neutrinolabs/xrdp/releases/download/v${pkgver//_/-}/xrdp-${pkgver//_/-}.tar.gz"
-	"arch-config.diff")
+	'arch-config.diff'
+	'sysusers.d'
+	'tmpfiles.d')
 sha256sums=('2f7beb5a3b2529c8d72dc0df9b8cdca31ab0e0c14d1e3421210f5e6ec0ab3b75'
-            'e0ffce5b1a436990281fe2cc4a3cd9c2840a1dad99740aeaea866ccd9ef56db0')
+            'c69bdcf3b7f7e5ef1dad8caab0e5a438f0857c1e36a7b2b5aa1e6dcf5e45882c'
+            '72f2e1d945d91ddf7034fbe9b64d55e8fbe88d737b0cc3cedd779321b63d05c1'
+            'd75eb05321d247ce792471a9f5176b1b03cf6166673d6bdd110da8fb7e8bd856')
 
 prepare() {
   cd "${pkgname}-${pkgver//_/-}"
-  patch -Np2 -b -z .orig <../arch-config.diff
+  patch -Np1 -b -z .orig < "../arch-config.diff"
+  #patch -Np2 -b -z .orig <../arch-config.diff
   ./bootstrap
 }
 

Comment

The change adds packaging of two new systemd integration files: a sysusers.d entry creating the dedicated xrdp daemon user and a tmpfiles.d entry creating /etc/xrdp with xrdp ownership. These files are minimal, local, and consistent with the package's existing install script, which already expects /etc/xrdp and generates rsakeys there. The PKGBUILD still fetches the upstream release tarball over HTTPS and there are no new network fetches, privilege escalations, or suspicious commands. The only notable change is switching the patch application from -Np2 to -Np1, but the patch file itself was not shown to contain anything malicious and this appears to be a packaging fix rather than a security issue. Overall low risk.

@@ -76,4 +81,6 @@ package() {
   rm -f "$pkgdir"/etc/xrdp/rsakeys.ini
   install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING
   install -Dm644 instfiles/default/xrdp "$pkgdir"/etc/default/xrdp
+  install -Dm644 "${srcdir}/sysusers.d" "${pkgdir}/usr/lib/sysusers.d/xrdp.conf"
+  install -Dm644 "${srcdir}/tmpfiles.d" "${pkgdir}/usr/lib/tmpfiles.d/xrdp.conf"
 }

Comment

The change is low risk overall. The startwm.sh patch only adjusts session startup behavior for Arch by sourcing ~/.xinitrc or /etc/X11/xinit/xinitrc after pre_start/post_start, which is expected desktop-session integration and does not introduce privilege escalation, persistence, or network activity. The other hunks are test tolerance and enabling runtime_user/runtime_group in xrdp.ini, which are configuration changes consistent with running xrdp under its dedicated user/group. No suspicious downloads, sudo usage, or system-wide modifications are present in the reviewed diff.

@@ -1,7 +1,7 @@
-diff -up src/xrdp-0.9.16/sesman/startwm.sh.orig src/xrdp-0.9.16/sesman/startwm.sh
---- src/xrdp-0.9.16/sesman/startwm.sh.orig	2020-12-28 07:03:43.000000000 -0700
-+++ src/xrdp-0.9.16/sesman/startwm.sh	2021-05-12 17:06:31.690000000 -0600
-@@ -58,11 +58,26 @@ post_start()
+diff -uNr a/sesman/startwm.sh b/sesman/startwm.sh
+--- a/sesman/startwm.sh
++++ b/sesman/startwm.sh
+@@ -58,11 +58,26 @@
  #start the window manager
  wm_start()
  {

Comment

The diff only changes a test tolerance constant and enables the default runtime_user/runtime_group in xrdp.ini.in. I don't see any added code execution, network access, privilege escalation, or packaging-time writes outside the package directory. The config change is a normal packaging/defaults adjustment for running the daemon as the dedicated xrdp user/group, and the test tweak affects only test behavior. No security red flags in this hunk.

@@ -30,3 +30,29 @@ diff -up src/xrdp-0.9.16/sesman/startwm.sh.orig src/xrdp-0.9.16/sesman/startwm.s
    # debian
    if [ -r /etc/X11/Xsession ]; then
      pre_start
+
+diff -uNr a/tests/xrdp/test_bitmap_load.c b/tests/xrdp/test_bitmap_load.c
+--- a/tests/xrdp/test_bitmap_load.c
++++ b/tests/xrdp/test_bitmap_load.c
+@@ -43,7 +43,7 @@
+  *
+  * This is the Pythagorean distance we allow between two colors for them to
+  * be considered close enough to each other */
+-#define MAX_SIMILAR_COLOR_DISTANCE 3
++#define MAX_SIMILAR_COLOR_DISTANCE 160
+
+ /* Time to allow some large bitmap test suites to run on slower platforms */
+ #define LARGE_BM_TEST_SUITE_TIMEOUT 10
+
+diff -uNr a/xrdp/xrdp.ini.in b/xrdp/xrdp.ini.in
+--- a/xrdp/xrdp.ini.in
++++ b/xrdp/xrdp.ini.in
+@@ -43,8 +43,8 @@
+ ; It is HIGHLY RECOMMENDED you set these values. See the xrdp.ini(5)
+ ; manpage for more information on setting and checking these.
+-#runtime_user=xrdp
+-#runtime_group=xrdp
++runtime_user=xrdp
++runtime_group=xrdp
+
+ ; regulate if the listening socket use socket option tcp_nodelay

Comment

The change only adds a sysusers.d entry creating the dedicated xrdp daemon account with a non-login shell and /etc/xrdp as its home directory. This is standard packaging metadata for a service account and does not introduce network access, privilege escalation, persistence, or other suspicious behavior. The surrounding package already ships matching tmpfiles/sysusers integration and the install script only generates keys locally on install/upgrade.

@@ -0,0 +1,2 @@
+# Type Name ID GECOS Home directory Shell
+u xrdp - "xrdp daemon user" /etc/xrdp /sbin/nologin

Comment

The tmpfiles.d addition is low risk. It creates /etc/xrdp with root-owned directory semantics implied by systemd-tmpfiles and then applies SELinux/xattrs relabeling via 'Z' for that path. There are no network calls, privilege escalations, persistence mechanisms, or writes outside the expected system directory. The only notable concern is that managing /etc via tmpfiles is somewhat unusual, but in this context it is a standard packaging mechanism for ensuring configuration directory presence and labeling.

@@ -0,0 +1,3 @@
+#Type Path    Mode UID  GID  Age Argument
+d /etc/xrdp   0755 xrdp xrdp -   -
+Z /etc/xrdp   -    xrdp xrdp -   -