Tamper evidence

Your Storage Connector keeps a signed record of every file operation it performs. At intervals it sends us a short signed commitment describing what that record contained.

Once we have recorded a commitment, neither you nor we can change what the log said for that period without the difference being provable.

The Tamper evidence page is where you see that: what your machines committed to, and what we can prove we received. For the whole arrangement in one page, from the signed files on your machine to the copy we hold, read How witnessed signed logging works.

Why two halves are needed

The record on your machine is signed with a key that lives on that machine. That proves nobody else altered it. It proves nothing against somebody with access to that machine, because verifying a signature and producing one are the same capability there.

A commitment held by somebody else, at a time that has already passed, is what closes that. It cannot be revised afterwards, not even by whoever owns the machine and holds every key on it.

So: the log is the record, and the commitment is what makes the record evidence.

What the page shows

For each of your machines:

Field	Meaning
Reporting or Gone quiet	Whether commitments are still arriving
Machine key	The identity the machine signs with
Commitments held	How many we have recorded
Last received	When the most recent one arrived
Holding everything since	Shown once our retention has retired this machine's oldest commitments: everything recorded after this moment is still held here

The three things that need your attention

The page flags these, and each one has a legitimate explanation and a worrying one. That is exactly why they are surfaced rather than resolved for you.

Missing commitments. We are missing a numbered run from a machine. This happens legitimately when a machine is offline long enough to run out of local space. It is worth confirming the cause rather than assuming either explanation.

Refused commitments. A commitment was refused because it contradicted one we had already recorded. This should never happen in normal operation and is worth investigating.

A rotated key. The machine now signs with a new key, and the page names the previous one. That is expected after a rebuild or a reinstall. If neither happened, ask why.

Take your own copy

Choose Download the evidence file.

It contains every commitment we hold for this site, exactly as your machines signed them, our countersigned record of when each one arrived, and instructions for checking all of it.

It needs nothing from us to verify.

Keep it somewhere we do not control

Evidence held only by the party you might one day be in dispute with is not evidence. That includes us.

We hold each commitment for at least 400 days and then retire the oldest, from the oldest end of each machine's sequence only, never from the middle. The page states the window in force. A copy you took earlier stays valid for everything it contains, and a gap that existed before the retention horizon stays listed as one, marked as being before the horizon.

Verifying it yourself

The verifier is a public, open source program with no dependencies outside the Go standard library. It reads only: it never writes to the evidence it is given, never creates a key, and cannot produce a log line, an anchor or a commitment.

go install github.com/syncplify/logverify/cmd/logverify@latest

Or build it yourself, which is the point:

git clone https://github.com/syncplify/logverify
cd logverify
go build ./cmd/logverify

To check the log on your own Connector:

logverify verify -dir /opt/Syncplify/sc-conn/audit -identity /opt/Syncplify/sc-conn

On Windows the two paths are under C:\ProgramData\Syncplify\sc-conn.

To check a log against a signed commitment, which is the check that means something to a third party:

logverify anchor -dir ./logs -anchor ./anchor.json -pubkey @./producer.pub -identity ./producer-data-dir

Exit codes: 0 verified, 1 did not verify, 2 bad arguments or the evidence could not be read. The last two are kept apart deliberately: "this evidence is bad" and "I could not read this evidence" are different findings.

The format is specified in the repository's SPEC.md, in enough detail to be reimplemented without reading the code. If you would rather write your own verifier than run ours, that is a reasonable thing to want, and the specification exists for it.

What a passing check does and does not prove

Worth reading before quoting an output anywhere it matters.

• The per line chain proves nobody without the key altered, inserted, removed or reordered a line. It proves nothing against whoever holds that key.
• The signed commitments can be checked by anyone with the public key and produced by nobody without the private one. But the producer holds the private key, and could rewrite old history and re-sign all of it.
• A commitment an independent party received and retained, at a time that has already passed, is what makes rewriting detectable.

The honest claim, and the only one this supports: the producer is cryptographically bound to its contemporaneous record and cannot alter it later. Cryptography cannot say whether what was written was true when it was written. It can say that nobody rewrote it afterwards.

Holding us to the same standard

We witness your machines. Nobody witnesses us.

So we publish our own log's position openly, at /api/v1/transparency/log on the Portal, with no sign in required.

Record what it says from time to time and keep that alongside your own evidence. It is the only thing that stops us quietly revising our own history later.

Who can see this page

Every role, including tech members. It is the transparency record rather than an operational control.