• Independent security audit of 3.4.3 — source, signed binary, and how to verify your own copy

[Ranbo-codez]

Nobody asked for this and I am not affiliated with the project. Vorssaint kept coming up in places I read, always with some version of "it does thirty things, it's free, what's the catch?", so I spent a day checking rather than speculating. Posting it here because this is where the people deciding whether to install it actually are, and because every claim below can be checked against the source in this repo.

Disclosure: this was done with heavy help from an AI model (Claude Opus 5.5 Max Ultracode). I directed the work, it did the heavy lifting. Every finding carries a file reference or a reproducible command precisely so that it does not rest on my word or the model's.

Short version: nothing hidden, and several things are done better than in commercial utilities I have looked at.

Scope

• Source at commit a5da7633e09d0ebbf5b5607c0434ded28a239469 (29 Oct 2026) — 706 Swift files, 313,427 lines, plus build scripts, CI workflows and the full 2,059-commit history.
• Vorssaint-3.4.3.dmg, 27,809,266 bytes, SHA-256 d1d59435f949539968adcbc9aa2545a6b90610b753bf843d8113c85615a20396, from the GitHub release.

Method, and why it is worth stating

I ran this twice. The first pass reached four wrong conclusions because it leaned on searching the source for strings.

Text search cannot establish that a capability is absent — an empty result means the pattern did not match, not that the behaviour is missing. So the second pass led with evidence that does not depend on spelling an API correctly:

1. The binary's imported symbol table (nm -u), 4,376 symbols — what the compiled code can actually call.
2. Every dlsym/dlopen string, since dynamic resolution bypasses the import table.
3. Signature and entitlements read from the shipped binary rather than the repo.
4. A magic-byte scan of all 14,537 history blobs over 2KB, rather than trusting file extensions.
5. Source reading last, to explain what the first four turned up.

The corrections section at the end lists exactly what the first pass got wrong.

Does the shipped binary match this source?

Every independent comparison agreed.

Signature. The DMG satisfies the exact designated requirement the updater itself pins in Sources/Vorssaint/Services/Update/UpdateInstallerSupport.swift:66, and the staged app satisfies the stricter one at line 123 that also pins the bundle identifier. Team ID in the certificate matches the constant in the source.

Notarization. spctl returns accepted / source=Notarized Developer ID, and the stapled ticket validates offline.

Entitlements. The shipped binary declares exactly the four in Resources/Vorssaint.entitlements — Apple Events, camera, audio input, calendars — and nothing more. No disable-library-validation, no allow-unsigned-executable-memory, no get-task-allow. Hardened Runtime on.

Network hosts. All 19 hosts in the compiled binary appear in the source. Zero extras.

Bundle contents. Four executables, all accounted for, and Resources/now-playing.pl is byte-identical to the file in this repo.

Findings

Check	Result
Keychain / credential access	No keychain symbol imported
Keystroke capture capability	Present — 31 event taps, all opt-in
Keystroke storage or transmission	None
Analytics or telemetry SDK	None
Device fingerprinting	No serial, UUID or MAC read
Browser credentials, keys, wallets	Not referenced
Undisclosed network hosts	None — binary matches source
Obfuscated payloads	None
Binaries in git history	None in 2,059 commits
Third-party dependencies	Zero
Root daemon client authentication	Mutual code-signing requirement
Sudoers rule scope	One uid, two exact argvs, no wildcard
Root shell command injection	Allowlist-validated
CI action pinning	All 7 pinned to full SHA
pull_request_target code execution	No checkout of PR code

Nothing rose to a vulnerability, and nothing warranted a private security report.

Keyboard input

This is the part users most deserve a straight answer about, and the part my first pass got wrong.

The app creates 31 CGEvent taps; 13 observe keyDown. That is inherent to the features — text expansion cannot match a trigger it cannot see, and a switcher cannot react to Command-Tab without watching modifiers — but it is worth stating plainly rather than leaving for someone to discover.

What constrains it:

• Every feature owning a tap defaults to off (textSnippetsEnabled, superKeyEnabled, keyboardDebounceEnabled and so on are all false in the defaults map).
• Of the 25 files that own a tap, exactly one performs a write — saving a pasted image as a PNG in FinderCutPaste.swift:391. None constructs a network request.
• Secure Event Input means macOS withholds keystrokes from every tap in password fields.
• The snippet buffer is a 64-character rolling window (TextSnippetSupport.swift:59), held in memory and cleared on app switch, click, or expansion. Never serialised.

Privileged components

The fan-control daemon. Registered via SMAppService.daemon(), so it must be approved in System Settings; zero entitlements. The XPC channel is mutually authenticated: the daemon sets a code-signing requirement on the listener itself at Sources/FanControlHelper/main.swift:602, built from FanControlXPC.swift:22-31, and the app pins the daemon in return at FanControlService.swift:285 and :427. Because the requirement sits on the listener, non-matching clients are rejected before the delegate runs. Interface is five fan methods, levels clamped 0-100, one-second watchdog restoring automatic cooling.

The sudoers rule (SudoersSupport.swift:17-19):

#<uid> ALL=(root) NOPASSWD: /usr/bin/pmset disablesleep 1, /usr/bin/pmset disablesleep 0

Scoped to one uid, root only, absolute path, both argument vectors fully specified so no other pmset invocation matches. Written and validated with visudo -c in ShellSupport.swift:173, rolled back on failure. This is tighter than most NOPASSWD rules I have seen in shipping software.

Root shell paths. Six run a command as root. Four are hardcoded constants. The kill path interpolates a value, but it is validated against ^[A-Za-z0-9: ]+$ in KillProcessSupport.swift:53-58 first, which excludes every shell metacharacter, so the interpolation is safe by construction.

Third-party update feeds. AppUpdateFeedSupport.swift:44-53 fetches SUFeedURL from other installed apps, behind a validator that requires HTTPS, rejects embedded credentials, raw IPs, .local/.localhost and non-ASCII labels, and drops feed configs carrying tokens or custom headers. Worth noting in any privacy discussion, since it means outbound traffic is not limited to the hardcoded host list.

Screenshot sharing. The endpoint is overridable only for the .dev bundle identifier (ScreenshotSharingSupport.swift:84-95), so release builds cannot be redirected.

Supply chain

• Zero third-party dependencies; every source file carries the project's SPDX header, so nothing is vendored.
• All seven CI uses: entries pinned to full commit SHAs.
• The pull_request_target workflow performs no checkout, which the file documents deliberately. No PR title or body reaches a shell; the one user-influenced value is env-passed and regex-validated.
• No Mach-O, archive or compressed object has ever been committed — 14,537 blobs scanned by magic bytes.

Verifying your own copy

These need no admin password and change nothing:

codesign -dv --verbose=2 ~/Downloads/Vorssaint-3.4.3.dmg
spctl -a -t open --context context:primary-signature -vv ~/Downloads/Vorssaint-3.4.3.dmg
codesign --verify --deep --strict -R='anchor apple generic and certificate leaf[subject.OU] = "3D485NHW29"' /Applications/Vorssaint.app
codesign -d --entitlements - --xml /Applications/Vorssaint.app 2>/dev/null | plutil -p -

The third should produce no output; the fourth should list exactly four entitlements.

Limits

• No reproducible build, so matching signature, entitlements and host list are strong evidence the binary came from this source — not proof. A reproducible build would close that gap and is the single thing that would most improve verifiability here.
• One version, one commit. The app self-updates, and signature pinning means the maintainer remains the trust anchor.
• Static analysis only. Nothing was executed and no traffic was captured.
• Coverage is uneven: privileged code, the updater, every event tap, all network call sites, the uninstaller and the build/CI scripts were read in full; ordinary UI code was not.

One suggestion

shouldAcceptNewConnection in Sources/FanControlHelper/main.swift:566 returns true unconditionally. That is correct, because the real gate is setConnectionCodeSigningRequirement on the listener at line 602 — but read in isolation the delegate looks unguarded, and I briefly concluded it was a vulnerability before spotting line 602. A one-line comment at 566 pointing to it would save the next reviewer the same detour.

Where I got it wrong

Four wrong conclusions in the first pass, all from the same error — treating an empty search as proof of absence:

Wrong conclusion	Cause
No privileged helper exists	grep -E with an escaped pipe matches a literal character, not alternation
The root daemon has no client authentication	Searched setCodeSigningRequirement; the API is setConnectionCodeSigningRequirement
The app cannot log keystrokes	Searched the C name CGEventTapCreate; Swift spells it CGEvent.tapCreate
Safari cookies never referenced	Pattern required a prefix the actual string lacked

The second nearly produced a vulnerability report about something that was never broken. Listing them because a review whose misses are hidden cannot be judged, and because the lesson generalises: a search proves presence, never absence.

Bottom line

Nothing deceptive, and several things here are done properly rather than merely adequately. The sudoers rule is scoped more tightly than most shipping software manages. The updater verifies what it installs before swapping it in, rather than trusting the download. The fan daemon's XPC channel is authenticated in both directions. Those are the three places utilities in this category usually get it wrong, and none of them is wrong here.

What an audit cannot settle is the part that is not a code question. The app holds broad permissions and updates itself, so running it means trusting the maintainer on an ongoing basis rather than trusting one build that someone checked once. That is true of every auto-updating utility with this level of access, and it is a judgement each person makes for themselves. The findings above are meant to inform that judgement, not to replace it.

For what it is worth, the things that would strengthen it further are small: a reproducible build, and a comment at line 566. Neither is a defect.

Happy to expand on any part of this, and glad to be corrected on anything I have read wrong.