safing/portmaster: technical due diligence, read from its repository

The median source file here is 89 lines. 7 files exceed 1,000 lines, the largest being 4,749. Size is not a defect on its own — some problems genuinely live in one place — but these are where merge conflicts, review fatigue and single-owner knowledge concentrate, and they are the first thing that slows an inheriting engineer down.

Of five ordinary markers — CI workflows, CODEOWNERS, a pull-request template, pre-commit hooks, contribution guidance — 1 is present: CI workflows. Branch protection itself is a GitHub setting rather than a file, so this is a reading of proxies and not of the rules themselves. What it does establish is that the process is not written down anywhere a new engineer would find it.

The code is pinned to Go 1.21 (end of life 2024-08-13). None of these receives security fixes any more; the first stopped on 2024-08-13. Moving off an unsupported runtime is rarely a one-line change, so a buyer should ask whether the upgrade is planned and what it touches.

2 HTTP calls use a client with no timeout (Python `requests` without `timeout=`, or Go's default client). When a dependency slows down, each one holds a worker until the connection gives up, and enough of them take the service down with the dependency.

3 places in product code build SQL by formatting or joining strings rather than passing parameters. 3 of them put a value into the string; in the rest, what the code shows going in is a table or column name, a constant, or something the line does not show. Ask whether any value reaches these strings, rather than a parameter.

The root licence changed 1 time(s). Code taken under earlier terms stays under them; check which terms any fork or customer relied on.

Nothing in the service initialises an error reporter (Sentry, Rollbar, Bugsnag, Honeybadger or an APM agent). An exception in production reaches a person only if someone is reading the logs, which usually means a customer reports it first.