Security Analysis: Unknown Risk Present - Critical Areas to Investigate (Inconclusive)

[eyeofastarte]

Status: Inconclusive. No malicious code was proven, but the review is
not a clean bill of health. The installer executes a large amount of
remote, unverified code, so residual risk remains unknown until the items
below are checked. Treat this thread as "proceed with caution," not "safe."

---

TL;DR

• Reviewed AffinityScripts/AffinityLinuxInstaller.py. Found no evidence of
  a virus and no malicious handling of the sudo password.
• However, the password prompt is the least interesting attack surface. The real
  risk is unverified remote code execution via downloaded dependencies.
• There is no checksum or signature verification anywhere across ~22 archive
  extractions and many binary/source downloads.
• Conclusion is inconclusive: a compromised upstream release or repo could
  ship malware that static review of this repo cannot detect.

---

What was checked and looks OK

• Sudo password is masked on entry, kept only in memory, sent to sudo/gpg
  via stdin (never argv, never shell=True), and is not logged, written to
  disk, or sent over the network.

---

Critical areas to investigate (ranked by leverage)

1. Wine build tarballs — highest risk.
   ElementalWarrior-wine-*.tar.xz and Kron4ek/Wine-Builds are downloaded and
   extracted with no hash check, then run for every launch. A trojaned
   wine/ntdll.so would be invisible and persistent.
   Refs: AffinityLinuxInstaller.py:4790, :11644-11662, extraction :11709+.

2. Compile-and-run remote C#.
   AffinityPatcher.cs / ReturnColors fetched from raw GitHub or git clone,
   built with dotnet, and the produced .dll executed. Whoever controls those
   files gets code execution.
   Refs: :15499-15500, :15569, :15634, :15787-15828.

3. Third-party shim DLL loaded into every Affinity process.
   wintypes_shim.dll.so from an external repo, dropped into the prefix and
   force-loaded. Ideal payload location.
   Ref: :10664.

4. Live assets fetched from main.
   Icons and wine-dark-theme.reg pulled from raw.githubusercontent.com/.../main/.
   A single malicious commit would hit all users immediately; a .reg merged
   into Wine is a subtle foothold.
   Refs: :6381, :11570, :12555.

5. The Affinity .exe / AppImage.
   Repackaged binaries where malware is trivial to bundle and hard to spot.
   Refs: :8712, :16173.

Areas not yet reviewed (open)

• The shell scripts AffinityScripts/*.sh (same download-and-run pattern).
• Transitive trust: winetricks cloned from upstream then executed (:9526).
• TOCTOU / path traversal across the ~22 extractall calls (not all use
  filter="data").
• Supply-chain: DNS/CDN takeover or maintainer account compromise.

---

How anyone can verify (reproduce this analysis)

1. List every remote endpoint:
   grep -noE "https?://[^\"' ]+" AffinityScripts/AffinityLinuxInstaller.py | sort -u
2. Prove the gap in integrity checks (expect ~no relevant hits):
   grep -niE "sha256|sha512|md5|gpg --verify|signature|hashlib" AffinityScripts/AffinityLinuxInstaller.py
3. Count archive extractions (attack surface):
   grep -c "extractall\|zf.extract\|zip_ref.extract" AffinityScripts/AffinityLinuxInstaller.py
4. Trace compile-and-run of remote source: read ensure_patcher_files (:15490)
   and build_affinity_patcher (:15734).
5. Runtime check: install inside a VM/container and watch outbound traffic
   (ss -tnp, tcpdump) and new files during the process.

Recommended mitigations

• Pin releases and verify sha256/signatures before extract/run; stop fetching
  from live main/latest.
• Diff downloaded Wine tarballs against upstream originals.
• Build the C# patcher from a pinned, reviewed commit — not main.
• Prefer the official Affinity installer from Serif; run everything sandboxed.

---

Bottom line

No proof of a virus, but unknown risk remains because the program runs
unverified third-party code. Until the critical areas above are audited and
integrity checks are added, consider the security posture unresolved.