Syncthing

1. Overview

Peer-to-peer folder synchronisation with cryptographic device identities and conflict file preservation. It is synchronisation, not backup.

Category: OS & Infra.

2. Version and scope assessed

Version assessed: Pinned evidence d6d0181f7d466381c4b39ec8fd944c364f939b32.

4. Principle profile

5. Fundamental requirements

6. Evidence and verification

• E1: The official documentation for this entry provides a relevant independent access to essential information lead, but this desk review did not perform a version-pinned export, restore, migration, offline, or consequential-behavior test sufficient to establish the claim beyond the recorded status. (source), confidence medium
• E2: The official documentation for this entry provides a relevant practicable exit and migration lead, but this desk review did not perform a version-pinned export, restore, migration, offline, or consequential-behavior test sufficient to establish the claim beyond the recorded status. (source), confidence medium
• E3: The versioner helper resolves .stversions by default or a configured versioning filesystem and archives/restores using filesystem RenameOrCopy with timestamp handling. Archived versions are files, not merely opaque index entries; full metadata fidelity is not established by that code. (source), confidence medium
• E4: The official documentation for this entry provides a relevant continuing authority and custody over already-created work lead, but this desk review did not perform a version-pinned export, restore, migration, offline, or consequential-behavior test sufficient to establish the claim beyond the recorded status. (source), confidence medium
• E5: Trashcan archive uses the original filename rather than the Simple versioner's timestamp-tagged name. Its cleanup returns without removal when cleanoutDays <= 0; otherwise files older than the computed cutoff are removed. This resolves a retention-policy boundary, not proof that synchronization itself is a backup. (source), confidence medium
• sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for Syncthing does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
• longevity: E3 is not established for Syncthing's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
• locality: The official documentation for this entry provides a relevant locality lead, but this desk review did not perform a version-pinned export, restore, migration, offline, or consequential-behavior test sufficient to establish the claim beyond the recorded status. (source), confidence medium
• transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
• E3: Versioner archives are ordinary files using RenameOrCopy and timestamp handling, but full metadata fidelity, configuration/index migration and two-peer reconstruction were not established. Version retention is not proof of independent backup or recovered conflict/deletion history. (source), confidence medium
• E5: Trashcan retention uses policy-dependent cleanup and non-tagged names; synchronization can propagate destructive changes. Effective peer/folder authority, override/revert choices, conflict visibility and usable recovery remain insufficiently covered by the retention helper alone. (source), confidence medium

7. Migration and recovery

Native storage format: Direct Peer-to-Peer Block Exchange (BEP).

Synchronization or runtime model: End-to-End TLS over LAN / Relay.

Example export or inspection command (not verified against any particular version or data set): syncthing cli show system

8. Architectural strengths

Established strengths and their scope are recorded in the evidence and assessment findings on this page.

9. Architectural limitations

• Source/retained-input inspection only; no installation or application restore performed.
• Two-peer deletion/conflict propagation, manual metadata recovery, config/database migration, destructive override/revert behavior and network observations remain untested.

10. Assessment findings and remaining work

Verification scenario: Disconnect peers, delete files, simulate conflicting edits, test versioning, and restore from an independent backup.

What may invalidate an overconfident claim: Synchronisation propagates deletions; it does not replace a backup system.

Documentation starting point: https://docs.syncthing.net/users/faq.html

Evidence update: 23 October 2026

• Resolved: The versioner helper resolves .stversions by default or a configured versioning filesystem and archives/restores using filesystem RenameOrCopy with timestamp handling. Archived versions are files, not merely opaque index entries; full metadata fidelity is not established by that code. Source.
• Resolved: Trashcan archive uses the original filename rather than the Simple versioner’s timestamp-tagged name. Its cleanup returns without removal when cleanoutDays <= 0; otherwise files older than the computed cutoff are removed. This resolves a retention-policy boundary, not proof that synchronization itself is a backup. Source.
• Open: Two-peer deletion/conflict propagation, manual metadata recovery, config/database migration, destructive override/revert behavior and network observations remain untested. E5 needs peer/folder authorization, deletion/conflict and override/revert visibility, plus configured retention and recovery limits.

Assessment follow-up: These bounded findings are incorporated into the evidence above. Eligibility and principle ratings are deliberately unchanged; their reconciliation and any blank-status fixes are deferred to the next pass. Reproduction details and retained inputs are in evidence/third-pass/batch-9/.

Human-readable criteria: Can an administrator reproduce, inspect, recover, and operate the system from user-controlled configuration and packages without a vendor-controlled permission path?

Rating reconciliation: 24 October 2026

E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.

Remaining: Two-peer deletion/conflict propagation, manual metadata recovery, config/database migration, destructive override/revert behavior and network observations remain untested. E5 needs peer/folder authorization, deletion/conflict and override/revert visibility, plus configured retention and recovery limits.

Next without installing locally: Use a synthetic two-peer folder/config/version archive packet with expected conflicts/metadata and externally recorded propagation/revert/restore observations; inspect files and policies independently.

The individual decision and provenance are retained in evidence/rating-reconciliation/batch-9/. Overall: Insufficient evidence.

Individually reconciled in rating batch 9 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. Previously resolved questions are retained, not counted again. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.