Skip to content
Lacre

Alterations and verification

A seal says what the issue was like when it was sealed. If someone edits it afterwards, the seal does not change (it is a record that is never touched again), but the panel warns that the issue is no longer the one that was sealed.

What counts as an alteration

Any change, after the seal, to one of the fields stored by the current check: key, project, type, summary, description, status, assignee, reporter, priority, resolution, labels, components, fix versions and the custom fields the project has chosen for the seal.

Comments, attachments, links, work logs and fields that are not sealed do not count, even if Jira updates the issue's last-updated date with them.

What it looks like

The panel changes to "Altered after sealing", with the fields that changed ("Changed after sealing:") and the date of the first change recorded by Lacre. In the history, the seal is shown as "Altered".

Lacre records the alteration as soon as Jira reports the change, and the panel recomputes it every time it is opened, in case the notification did not arrive. Once recorded, it stays even if the field later goes back to its value: what was sealed is no longer what there was. Lacre stores which fields changed and when, never who changed them; the issue history in Jira says that.

To have a current check again, seal another one ("Seal check"). The altered one becomes "Superseded" and is kept with its alteration. The approval goes with its check: a new check needs another approval.

Alterations are also recorded in a project where Lacre is turned off, because its seals are still shown. On a site without an active subscription, Lacre does not watch in the background, but the panel still recomputes the alteration when it is opened.

The seal history

Below the latest seal, the "Seal history" lists the twenty most recent seals of the issue, checks and approvals, with their status:

For each seal you can see who signed it, when (in UTC), its identifier, its hash, the hash of the previous seal and the issue property that keeps its copy. "Show the canonical record" shows the exact JSON whose hash is the seal's.

Verify

"Verify" recomputes the hash of each stored seal of the issue and checks that each one chains to the previous one. For each seal it says "Matches" or "Does not match" and, if it does not match, why:

If all of them match, Lacre writes again into the issue the copies of the seals that are missing (for example, if someone deleted a property), twenty per verification: if more are left, the panel says so and you just verify again. It also warns about copies in the issue of seals that are not stored in this installation, which is expected after uninstalling and reinstalling the app. If any seal does not match, no copy is written again: contact support with the identifiers the panel gives.

"Verify" always works, also with Lacre turned off in the project or without an active subscription.

Checking it without Lacre

The hash does not depend on Lacre: anyone can recompute it from the seal's record. In the panel, "Show the canonical record" shows the record; save it to a file and run the Lacre verifier, which has no dependencies:

node verify-seal.mjs <file> <hash>

For an auditor, the convenient options are the project's JSON export or the seal's evidence sheet, prepared by a project administrator (Administration). What goes into the hash and how to recompute it with other tools: How a seal is verified.

A seal that matches shows that the record has not changed since it was stored and what the state of the issue was when it was sealed. It does not prove the identity of the signer beyond the Atlassian account they were signed in with, and it adds no third-party timestamp.