.. include:: /Includes.rst.txt .. _opentimestamps-manual: ================================================== Manual verification with the OpenTimestamps client ================================================== You can check :file:`integrity.json.ots` **independently** of T3Vault using the official OpenTimestamps command-line client. Combined with a hash check of the backup artefacts, this answers: *has anything in this backup been changed since it was sealed?* Upstream project: `opentimestamps-client `__. For the recommended overall flow, see :ref:`integrity-how-to-verify`. .. _opentimestamps-install: Install the client ================== Python package (typical on Debian/Ubuntu): .. code-block:: bash sudo apt install pipx pipx install opentimestamps-client # or: pip install opentimestamps-client Confirm the binary: .. code-block:: bash ots --help .. _opentimestamps-what-is-stamped: What was stamped? ================= T3Vault stamps **only** :file:`integrity.json` (not the ZIP files themselves). The ZIP digests are listed *inside* :file:`integrity.json`. Therefore: 1. Confirm artefact hashes still match :file:`integrity.json` (re-hash yourself or use :ref:`verify-cli`). 2. Confirm :file:`integrity.json.ots` is a valid OpenTimestamps proof for that exact :file:`integrity.json` file. Always keep :file:`integrity.json` and :file:`integrity.json.ots` side by side in the same directory (the ``ots`` client assumes the target file name by stripping ``.ots``). .. _opentimestamps-manual-hash-check: Check that files were not modified ================================== Independently of ``ots``, confirm that backup artefacts match the seal: .. code-block:: bash cd /path/to/backup_YYYYMMDD_HHMMSS_ sha256sum integrity.json # Compare with digests listed under "files" in integrity.json, e.g.: sha256sum database.zip MANIFEST.json *_part_*.zip If any artefact hash differs from :file:`integrity.json`, the archive was modified after sealing — do **not** restore it, regardless of OTS status. Prefer the bundled verifier for the same check: .. code-block:: bash php t3vault-verify.phar /path/to/backup_YYYYMMDD_HHMMSS_ .. _opentimestamps-verify: Verify the OpenTimestamps proof =============================== ``ots verify`` checks that :file:`integrity.json` still matches the proof and (when Bitcoin Core RPC is available) that the attestation is anchored in a Bitcoin block: .. code-block:: bash cd /path/to/backup_YYYYMMDD_HHMMSS_ ots verify integrity.json.ots Expected success: .. code-block:: text Assuming target filename is 'integrity.json' Success! Bitcoin block attests existence as of Pass the target explicitly if needed: .. code-block:: bash ots verify -f integrity.json integrity.json.ots Inspect the proof without a Bitcoin node: .. code-block:: bash ots info integrity.json.ots Without installing ``ots``, you can also use the browser verifier — see :ref:`opentimestamps-web`. .. _opentimestamps-web: Verify in the browser (opentimestamps.org) ========================================== The official site `opentimestamps.org `_ can verify an ``.ots`` proof without Bitcoin Core or the ``ots`` CLI. Hashing runs in your browser (the stamped file content is not uploaded for hashing beyond what the page needs locally). Steps: 1. Open the backup directory and keep both files ready: :file:`integrity.json` and :file:`integrity.json.ots`. 2. Open https://opentimestamps.org/ and use **Stamp & Verify**. 3. Drop (or select) :file:`integrity.json.ots` as the **proof** (``.ots``). 4. Drop (or select) :file:`integrity.json` as the **stamped file** when the page asks for it. A successful chain confirmation shows the OpenTimestamps UI label **Bitcoin Attestation** (block / time). Pending calendars may still show **Pending/Other Attestation** until the proof is confirmed on the Bitcoin blockchain. What to watch out for --------------------- * **Only** :file:`integrity.json` was stamped — never drop a ZIP, :file:`MANIFEST.json`, or the whole ``.t3vault.tar`` as the stamped file. Those will not match the proof. * Use the **exact** :file:`integrity.json` from the same backup as the ``.ots`` file. Any edit (whitespace, re-save) changes the digest and verification fails. * The website checks the **seal** (:file:`integrity.json` ↔ ``.ots``). It does **not** re-hash ``*_part_*.zip`` / :file:`database.zip`. Always run :ref:`verify-cli` (or the manual hash check above) as well if you need to know the archive contents were not modified. * Right after backup creation the proof may still be **pending**. That is not the same as “tampered”; wait for calendar → Bitcoin confirmation and try again, or rely on the hash check in the meantime. * Do not use the site’s **stamp** action on backup files — T3Vault already created the proof. You only need **verify**. .. _opentimestamps-bitcoin-node: Bitcoin node for ``ots verify`` =============================== Full CLI ``ots verify`` needs Bitcoin Core RPC (local node or remote URL). Without it you typically see: .. code-block:: text Could not connect to Bitcoin node: Cookie file unusable ([Errno 2] No such file or directory: '/home/…/.bitcoin/.cookie') and rpcpassword not specified in the configuration file: '…/bitcoin.conf' That error means the Bitcoin-blockchain time stamp was not checked — it does **not** mean the backup files were modified. For the “unchanged files” question, rely on the hash check / :ref:`verify-cli`. For the seal without a local node, use :ref:`opentimestamps-web`. **Local Bitcoin Core** (default cookie auth under ``~/.bitcoin/``): .. code-block:: bash # bitcoind must be running and synced far enough for the attested height ots verify integrity.json.ots **Explicit RPC URL** (local or remote): .. code-block:: bash ots --bitcoin-node http://USER:PASS@127.0.0.1:8332/ verify integrity.json.ots .. _opentimestamps-workflow: Recommended independent workflow ================================ 1. Open the backup directory (from :file:`.t3vault.tar` if needed). 2. Confirm artefact SHA-256 digests match :file:`integrity.json` (``php t3vault-verify.phar .`` or manual ``sha256sum``). 3. Optionally confirm the seal: :ref:`opentimestamps-web`, or ``ots verify`` with Bitcoin Core RPC. This proves **content integrity** (hashes). The OTS step additionally proves the seal existed at a point in Bitcoin-blockchain time, without trusting the original TYPO3 server. .. _opentimestamps-troubleshooting: Troubleshooting =============== ======================================================= ===================== Symptom Meaning / next step ======================================================= ===================== Hash mismatch vs. :file:`integrity.json` Archive altered — do not restore Web verifier: stamped file does not match Wrong file dropped — use :file:`integrity.json` from the same backup Web verifier: pending / no chain time stamp yet Proof not on-chain yet; hashes may still be OK ``Could not connect to Bitcoin node`` / missing Use ``.cookie`` :ref:`opentimestamps-web` or configure RPC ``ots`` not found under ``sudo`` ``pipx`` installs for your user only — run without ``sudo`` ======================================================= =====================