Security and privacy
TSR works on your computer: the files you compress go nowhere. Here is how it protects archives, how it updates, what it sends if you allow it, and how to report a vulnerability.
With a password the whole archive is encrypted with XChaCha20-Poly1305, index included: file names, sizes, dates and permissions stay secret. The key comes from the password through Argon2id, with the parameters written into the archive, so they can be raised tomorrow without breaking yesterday’s archives.
Every block and every file carries the BLAKE3 fingerprint of the original content. A wrong password and a tampered archive give two different errors, and verification says which file is damaged and where.
With Reed–Solomon parity, 1 to 30%, damage within the quota is repaired into a new file. Parity covers the physical bytes: whoever keeps the media can repair it without the right to read it.
Zero home-made cryptography: public, well-tested primitives (XChaCha20-Poly1305, Argon2id, BLAKE3, Reed–Solomon), used as intended. Of an encrypted archive, the total size and how many times it was extended remain visible.
TSR is written in Rust, which rules out by construction the classes of defects most exploited in programs that read files. Every size field read from an archive has a cap: a 299-byte hostile archive with an inflated size is rejected in a tenth of a second. On extraction paths never leave the chosen folder, and links are not followed.
Coverage-guided fuzzing runs on 18 targets, one per input reader, under the memory error detector: 11.77 million recorded executions, zero defects. Before a change enters the repository, a local gate repeats it for ten seconds per target.
The beta periodically reads a signed document from our server, sending only its version and the operating system. Every update is signed with a key kept encrypted on the author’s computer, never on the server: the program checks signature, size and fingerprint before installing it, installs it at the next restart, never during a job, and keeps the previous version to go back.
A server that lied, with a different package or a document without the right signature, would not manage to install anything: a series of tests on the real packages proves it at every release.
On first launch the beta asks whether you want to send us crash reports and usage metrics: two separate choices, which stay off until you turn them on. A crash report says where the program stopped; a usage metric says which operation, with what outcome and with rounded numbers.
File or folder names, paths, contents, user names and passwords are never sent. Events are tied to a random identifier created on your computer, stay ninety days on our server in the European Union, which does not keep IP addresses, and you delete them yourself from the preferences.
tsr beta sonda mostra prints the queued events exactly as they will leave; tsr beta sonda cancella asks the service to delete those that arrived; TSR_SONDA=0 turns everything off.
Every package has its SHA-256 fingerprint, published on the download page and in the SHA256SUMS file, which carries an eIDAS qualified timestamp. The programs are not yet signed with Apple and Microsoft certificates: on macOS the signature is ad hoc, and until the certificates arrive the systems warn on first launch.
Write to matteo@feroldi.cloud with the subject [TSR security], without opening public reports and without publishing details before the agreed date. If you want to encrypt the report, say so in the first message: the key is exchanged in reply.
A useful report gives the version (tsr --version), the system, the steps to reproduce and, if any, the file that triggers the problem. For every confirmed vulnerability in a distributed version a CVE identifier is requested, and the advisory comes out with the fixed release.
The full policy is in the SECURITY.md file inside every package; the contacts also in security.txt.
| Step | Within |
|---|---|
| Acknowledgement, with a reference | 3 working days |
| Assessment: confirmed or not, severity (CVSS 3.1), affected versions | 10 working days |
| Fix in a new release | high or critical severity: 30 days; medium or low: within 90 |
| Advisory published | with the fixed release, and in any case within 90 days of the report |
