Security overview

PubSalvage is built for organisations that can't send documents to anyone else's servers. This page says what it protects against, how, what it doesn't do, and how you can check each part yourself.

• No network
• Sandbox
• Hostile files
• Safe output
• Your data
• Limits
• Security review answers
• Report a problem

Short version: PubSalvage has no network code, no account and no telemetry. It only reads the files you give it, opens each one in a locked-down process, and writes its results to a new folder you choose.

What it protects against

• Your documents leaving your computer. There's no upload, sync, telemetry, crash reporting, update check or licence check over the network. The programs contain no networking code to do any of it.
• A malicious or damaged .pub file. Publisher files often arrive by email. A crafted file aimed at a bug in the layout engine is contained in a sandboxed process with no network, no access to your files and hard resource limits.
• Accidental damage to the archive. PubSalvage never writes to, moves or deletes your .pub files, and never overwrites its own earlier results.
• Active content in the output. Rebuilt pages are cleaned so opening them can't run scripts or contact other sites.
• Leaving traces. No index, history, recent-files list or logs.

No network

PubSalvage never needs a connection: licences are offline keys, updates are manual downloads, and there's no telemetry. This isn't just a setting. The build includes a gate that fails if the programs import any networking function:

• Linux: no imported socket, DNS, TLS or dynamic-loading symbols.
• Windows: no imported networking libraries (Winsock, WinHTTP, WinINet, URLMon, the DNS API and others).

The gate covers the layout-engine libraries too, not only our own code. The desktop app also has no network code, and a test checks its sources for network, settings and history use.

Check it yourself: run PubSalvage on a machine with no network, or block it in your firewall and watch for attempts. On Windows, Process Monitor's network view shows none. On Linux, strace -f -e trace=network pubsalvage render ... shows none.

A sandbox for every file

The layout engine is the part that parses the file's pages, so it's the part most exposed to a hostile file. It never runs inside the main program. Each file is handed, as bytes in memory, to a separate process that runs under these restrictions:

Windows

• An AppContainer with no capabilities: no network, no access to your files, no registry, no other processes' objects.
• A Job Object: memory cap, CPU-time cap, at most one process, killed when PubSalvage closes it, and no clipboard, desktop or display changes.
• Exploit protections: DEP, SEHOP, bottom-up and high-entropy ASLR, strict handle checks, Win32k and font loading off, no extension points, no dynamic code, no remote or low-label images, and no child processes.
• Exactly three handles: the file in, the results out, and nothing else.

Linux

• A seccomp filter that blocks networking, starting programs, debugging other processes, signals to other processes, and every way of changing files: write-opens, delete, rename, truncate, create and change permissions.
• Landlock removes all file-system write rights, where the kernel supports it.
• CPU, memory and file-size limits, a wall-clock deadline, and no core dumps.

Both

The main program enforces a deadline and an output cap, and is the only process that writes results. A crash or hang in the engine is reported for that file and the run continues.

Check it yourself: pubsalvage --selftest-sandbox starts a deliberately hostile engine on your machine that tries to write files, reach the network, start programs, make memory executable, use too much memory and run forever, and prints whether each attempt was stopped. It succeeds only if every attempt was stopped.

macOS isn't available yet. It's planned for version 1.1 with its own sandbox profile, and won't ship without one.

Hostile-input testing

• The file reader checks every sector chain for bounds and loops. Directory walks can't cycle, and truncated files fail cleanly. Size limits apply throughout.
• Tests run under AddressSanitizer and UndefinedBehaviorSanitizer, including a 2,500-case mutation test.
• Coverage-guided fuzzing (libFuzzer) of the file reader and the export formats.
• Tests start deliberately hostile engines that hang, spin, flood output and attack a real file, and check that each is contained.

Safe output

• Every rebuilt SVG page is stripped of scripts, embedded HTML, event handlers, external links, CSS url() and entity declarations. The browser index carries a strict Content-Security-Policy.
• The editable ODG export has its package checked before it's written. Hyperlinks aren't carried over (the link text is kept), because a link in an editable file can point to a program or a macro.
• Output names are cleaned against path traversal, and folder walks don't follow symbolic links.

Your data

• PubSalvage touches only the files and folders you name, at the moment you run it.
• Nothing is stored about you or your files: no index, recent-files list, usage log or crash report.
• The desktop app redirects every settings and cache location into a temporary folder deleted when it closes, and uses its own file dialogs, so the operating system's recent-files lists aren't updated.
• We, the makers of PubSalvage, never receive your documents or anything about them.

Licence keys

A key is a short piece of text holding an Ed25519 signature, checked on your computer against a public key built into the program. There's no activation server, no call-home and no usage count. The free tier's limit is per run, so nothing is remembered between runs. A key is stored only in your own settings folder, or in a machine-wide folder if your administrator places it there.

How it's built

• All third-party sources are pinned to exact versions, verified by SHA-256 checksum, and compiled by our own build rules, never the projects' own scripts. The layout libraries are linked statically.
• Hardened compiler and linker settings: _FORTIFY_SOURCE=3, _GLIBCXX_ASSERTIONS, stack protector, PIE and full RELRO.
• Every third-party component and its licence is listed in the program: pubsalvage licences.
• Every change runs the full test suite, the sanitizers, the fuzzing smoke tests and the no-network gate in CI.

What PubSalvage doesn't do

• It doesn't protect against a computer that is already compromised.
• It doesn't encrypt its output. Results are ordinary files in the folder you choose, protected like any other files there.
• It doesn't scan files for viruses. Use your normal antivirus as well.
• It hasn't had an independent security review yet. One is planned.
• Windows installers aren't code-signed yet, so Windows shows an "unknown publisher" warning until they are.

Answers for your security review

Does the software send data anywhere?	No. It has no network code.
Does it need an internet connection?	No, not to install, activate or run.
Does it need user accounts or single sign-on?	No. There are no accounts.
What personal data do you process?	None. We never receive your files or anything about them, so no data-processing agreement is needed.
Where is data stored?	Only in the output folder you choose, on your own systems.
Does it collect telemetry or crash reports?	No.
Does it need administrator rights?	Not to run. Installing for every user of a machine does, as with any all-users install.
How are untrusted files handled?	One sandboxed process per file (see above), with memory, CPU and time limits.
Third-party components?	Listed by pubsalvage licences, pinned and checksum-verified.
How do we report a vulnerability?	See below.

Reporting a security problem

A security contact address will be published here before downloads open. When you report a problem, please don't include confidential documents. Describe the problem and, if you can, attach a file that shows it, after removing anything private. We'll reply, keep you updated, and credit you if you'd like.