Log integrity

Every operation this Connector performs is written to a signed record that cannot be turned off.

Monitoring, then Log integrity, reports two independent things. They are deliberately never merged into one verdict, because the dangerous state is the one where signing looks perfect and nothing has been confirmed for a week.

Signed on this machine

Each line is chained to the one before it, so a changed or removed line breaks the chain.

The key lives on this machine. So a clean chain proves nobody else altered the record. On its own it proves nothing about somebody with access to this machine, because verifying a chain and forging one are the same capability there.

The panel shows the log identity fingerprint and where the files are.

Check the files now replays the integrity chain across the newest files in the log directory, within a budget, and says in log time what it covered. It is safe to run at any time; it reads only, and only one check runs at a time. Anything it reports as a note is information rather than a finding: where a retention trimmed record begins, or an empty file a rotation left behind. The offline tool below replays everything.

How much of the record this machine keeps is set under Settings, Logging: a number of days and a size, with floors of seven days and 256 MB. The oldest files are retired first, in chain order, and the record stays verifiable from whatever file is the oldest kept.

Confirmed by a third party

At intervals this Connector signs a short commitment describing what the log contained, and sends it to be recorded elsewhere.

Once recorded, everything up to that moment can no longer be rewritten without the difference being provable. This is the half that makes the record evidence rather than a claim.

Field	Meaning
Everything recorded up to	The point the log is confirmed through
Commitments waiting	Signed and not yet recorded
Confirmation received	When the last confirmation came back

Commitments follow activity within minutes. A quiet machine has nothing new to confirm, so these values advance only when the log does. A Connector that nobody used all weekend is not broken.

Two states worth acting on

Discarded commitments. Delivery stopped for too long and commitments were dropped. The resulting gap is permanent. Keep a note of why it happened, so it is not later mistaken for tampering.

Commitments that could not be made. The periods they covered are not bound to anything and cannot be proven later.

Both are reported with a count. Neither can be repaired after the fact, which is why they are shown rather than quietly retried forever.

Verify it yourself

A check only we can perform is not evidence.

The page shows a command that runs on your own machine, reads only the files you already hold, and contacts nothing:

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

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

Install it, or build it yourself, which is the point:

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

There are no dependencies outside the Go standard library, so the build works on an air gapped machine and there is no dependency tree to audit before you believe the result.

Exit codes: 0 verified, 1 did not verify, 2 bad arguments or the evidence could not be read.

The customer side of the same thing

Your Portal's Tamper evidence page shows the other end: which commitments SFTP.cloud actually received, which are missing, and which were refused for contradicting one already recorded.

Read both. This page tells you what the machine believes about itself; that page tells you what somebody else can prove about it.