Security and trust
Trust is part of the product, not a page about it.
Small utilities are the kind of software people download without much thought. That is exactly why every release here has to be verifiable, documented and honest about what it touches.
01 · Release requirements
What every release gets, and when.
Requirements marked for the first release are part of the release pipeline that must exist before any binary is published. Nothing ships without them.
| Req. | Requirement | State |
|---|---|---|
| R-01 | Read-only by default The first products only inspect. A tool that changes state must preview, validate, log and offer undo where possible. | In effect now |
| R-02 | No telemetry, no accounts Applications do not report usage and never require sign-in. A tool keeps working if this website disappears. | In effect now |
| R-03 | Clean Windows CI Applications are built and tested on clean Windows CI runners. Release builds will come from tagged commits only. | In effect now |
| R-04 | Honest signature status Each release says before download whether its executables are Authenticode signed. A signed release is RFC 3161 timestamped and checked against a pinned expected signer. Only the first PortWho release for Windows x64 may be unsigned, and only under the conditions below. | Required before first release |
| R-05 | Independent rebuild and owner approval The owner approves the exact version, commit and checksums of every release. An unsigned release also needs a separate reviewer to rebuild it from the approved source and match the published bytes exactly. | Required before first release |
| R-06 | SHA-256 for every file Checksums are published on the product page and in a checksum file next to the download. | Required before first release |
| R-07 | Immutable download paths A published file is never replaced. Changed bytes mean a new version number, and old versions stay at their original address. | Required before first release |
| R-08 | SBOM and build metadata Dependency records for every release, so affected versions can be identified quickly. | Required before first release |
| R-09 | Private source and CI Source, tests and CI remain in a private repository. Outsiders cannot inspect them; no public source availability is promised. | In effect now |
| R-10 | Second download location A GitHub Releases mirror with the same checksums, giving two independent places to compare, once the repository is public. | Planned |
02 · On your machine
What the tools touch.
- PortWho sends nothing. It reads local tables and the local certificate cache; revocation lookups are disabled, so verification never uses the network.
- Least privilege. Tools run as a normal user and ask for elevation only for a specific operation that needs it.
- Optional, transparent update checks. When releases exist, a product
reads a small static manifest (
/releases/<product>.json) and shows a non-modal notice. No silent updates. - Small attack surface. Input is validated, dependencies are kept small, and nothing downloads or runs unverified binaries.
No telemetry · no account · no update check in today's builds · revocation lookups disabled
03 · Verification
Check a download in under a minute.
Once releases exist, each product page lists the file name, size, SHA-256 and whether the release is signed, with the expected signer when it is. Nothing is offered for download today.
-
Compute the hash
Open PowerShell in the folder with the downloaded file.
Get-FileHash .\portwho-x.y.z-win-x64.zip -Algorithm SHA256 -
Compare it
The output must match the SHA-256 on the product page exactly. A match shows you have the published bytes; it does not by itself show who built them.
-
Check the signature status
If the product page says a file is signed, open the extracted executable’s Properties, then Digital Signatures, and confirm the signer is exactly the expected signer listed for that file. The signer is the certificate subject and can differ from the project publisher. If the page says unsigned, there is no signature to check and Windows will not show a verified publisher.
-
If anything differs, stop
Do not run the file. Keep it, and report it through the channel below. Downloads are only offered from this site.
04 · Disclosure
Reporting a vulnerability
If you believe you have found a security issue in a tool or in this website, report it privately first, so a fix can ship before details are public. Please include the product and version, steps to reproduce, and the impact you see. Reporters are credited in the release notes if they want to be named.
Email security@redlinesystems.de. Please include enough detail to reproduce the issue. No response deadline is guaranteed.
Channels today
- Security contact
- security@redlinesystems.de
- security.txt
- /.well-known/security.txt
- Advisories
- No public advisory channel; use the security contact
- Non-sensitive bugs
- Support options
Supported versions
Only the latest release of each product receives fixes. When a security fix ships, the release is flagged as a security update in the changelog and in the update manifest so that applications can highlight it.
Code signing and Windows warnings
No code-signing certificate exists and no signing provider has been chosen. Free signing that Windows trusts will be used if the project qualifies and the owner approves it; there is no paid fallback. Without it, only the first PortWho release for Windows x64 may be published unsigned, and only after an independent rebuild and review and the owner’s explicit approval of those exact files. Every other product and later version needs its own decision.
An unsigned release is labelled unsigned before download. Windows then shows no verified publisher, SmartScreen may warn that the app is unrecognised, Smart App Control on Windows 11 may block it, and organisation policy may stop it from running. A signed file can still see SmartScreen warnings. We will never ask you to turn these protections off; if you are unsure, do not run the file. Neither a signature nor its absence proves that a file is safe; the checksum proves only that you received the published bytes.