verify what is here yourself
there are three ways to check what is here. v1 records are checked with minisign and the v1 key; the v2 register is checked whole with verify-v2 against the pinned v2 root; one v2 record is checked with verify-release, which also opens the record's own signature and fetches the files it names. each record's page says which chain it belongs to.
method 1: a v1 record, with minisign
every record on this site is signed, and you can check that signature yourself using the public key we publish alongside it. a valid signature tells you the record hasn't been altered since we signed it; it doesn't tell you anything about whether the software itself is safe or behaves as described.
from any release's raw-evidence table, download ledger-entry.json, ledger-entry.json.minisig, and the pinned key file named on /keys/. then run:
minisign -Vm ledger-entry.json -p solpbc-transparency-1.pub -x ledger-entry.json.minisig
reading the result
| outcome | what it means |
|---|---|
| signature verifies | the signature checks out. this exact record matches what we signed and hasn't been altered. |
| signature fails to verify | the signature doesn't check out. don't trust this copy, and let us know how you got it. |
| curl or fetch fails | we couldn't complete the check, usually a network or availability issue on our end; that's different from a failed check and isn't evidence the record is wrong. |
method 2: the v2 register, with verify-v2
v2 records are covered by verify-v2, which checks the whole register against a pinned copy of sol pbc's v2 signing root. a passing check tells you the register you fetched matches what was signed by the keys your pinned root authorizes, that every record's bytes match their signed description, and that none of sol pbc's signed validity windows had passed when you ran it. it does not open a record's own signature; that is method 3 below. it does not tell you the root you pinned is the right one; you compare that yourself against the witness log lines, listed on the keys page. and it speaks only to the register, not to the software the records name.
save the raw root file linked on /keys/ as tuf-root.json, byte for byte; that saved copy is your pin. before you use it, check it against the witness log: find the sha256 line naming your copy's signed.version and match its digest against the sha256 of your copy's bytes; match the key ids your copy lists for its root role against the nearest key id line above that; then confirm no higher version line appears, because the log keeps every earlier version's line while the pin holds only one. then run:
solstone-transparency verify-v2 --root tuf-root.json --metadata-base https://transparency.solstone.app/v2/metadata --targets-base https://transparency.solstone.app/v2/targets
reading the result
| outcome | what it means |
|---|---|
| ACCEPTED, exit 0 | the command printed ACCEPTED and exited 0: the register you fetched matches what was signed by the keys your pinned root authorizes, every record's bytes match their signed description, and no signed validity window had passed when you ran it. |
| REJECTED, exit 1 | the command printed REJECTED with a reason and exited 1; read the reason. "expired" means one of sol pbc's signed validity windows has passed (a fact about sol pbc's assertion, not about any record's signature). "unavailable" or "retrieval-failed" means an object couldn't be fetched and the check did not complete. "trust-store-corrupt" points at a file on your machine, not at the register; "malformed" means a file could not be read or did not parse; the detail line names the field, not always the file, so on a first run check the root file you saved first. any other reason means what transparency.solstone.app served did not check out. |
| could not run, exit 2 | the command exited 2 because the pinned root couldn't be read; the check didn't happen, which is different from a failed check and isn't evidence about the register. |
method 3: one v2 record, with verify-release
verify-release checks one v2 record. it walks from your pinned root to the record through the register, checks the record's own signature against the signing keys the register authorizes, and then fetches every file the record names from its recorded url and compares the bytes it receives against the recorded length and sha256. a passing check tells you those files, as served to you at that moment, are the bytes sol pbc recorded as that release. it does not tell you the software is safe, or that a build you already have is these bytes; compare your own copy's sha256 against the record's yourself.
with the same pinned tuf-root.json, name the record by its product id and version as they appear in the record's path, software/PRODUCT/VERSION, not by its display name, then run:
solstone-transparency verify-release --root tuf-root.json --product PRODUCT --version VERSION --metadata-base https://transparency.solstone.app/v2/metadata --targets-base https://transparency.solstone.app/v2/targets
reading the result
| outcome | what it means |
|---|---|
| accepted release record, exit 0 | the command printed accepted release record and exited 0: the record verified through your pinned root, its signature checked against an authorized key, and every file it names was fetched and matched its recorded length and sha256. |
| rejected:, exit 1 | the command printed rejected: with a reason and exited 1; read the reason. invalid-coordinate means the product id or version you typed isn't a valid name; record-missing means no record exists under that product id and version, which is a gap in the register, not evidence about a release. a trust-store reason points at a file on your machine. a reason about a fetch means a file couldn't be retrieved and the check did not complete. expired means what it means in method 2. any other reason, with the command as printed here, means the register, the record, or a file it names did not check out as served to you. |
| could not run, exit 2 | the command exited 2 because it couldn't read its inputs, most often the pinned root file; the check didn't happen, which is different from a failed check and isn't evidence about the record. |