Releases: lambdasistemi/cardano-keri
Release list
ckeri 0.4.0 [latest]
ckeri 0.3.0 [latest]
ckeri 0.3.0
Maintenance
- Merge pull request #230 from lambdasistemi/release/cabal-release
Erratum — added 2026-08-04
ckeri manifest verify did not rebuild from source in this release.
The command printed manifest verify: OK — rebuilt from source; all hashes and on-chain references are live. The on-chain half was true: hashes and transaction
references were checked against the live chain. The "rebuilt from source" half
was not. The binary shipped with a compiled Plutus blueprint baked in as a
default, frozen at an earlier commit rather than rebuilt from the onchain/
sources in the release. So OK meant the manifest agreed with the baked
blueprint, not with the source you were verifying against.
The deployed preprod validators are unaffected. Their identities were
established by deploy-day records independently of this command, and hands-on
lifecycle runs against the live deployment behaved correctly. What was weakened
is the independent check, not the deployment. No action is required of you.
The fix ships in v0.4.0, which builds the blueprint from the release's own
sources. From that release the line names its toolchain — rebuilt from source under aiken 1.1.23 — because "rebuilt from source" only means something if you
can tell which toolchain rebuilt it. Tracked as issue #235.
ckeri 0.2.0 [latest]
ckeri 0.2.0
Maintenance
- Merge pull request #217 from lambdasistemi/release/cabal-release
Erratum — added 2026-08-04
ckeri manifest verify did not rebuild from source in this release.
The command printed manifest verify: OK — rebuilt from source; all hashes and on-chain references are live. The on-chain half was true: hashes and transaction
references were checked against the live chain. The "rebuilt from source" half
was not. The binary shipped with a compiled Plutus blueprint baked in as a
default, frozen at an earlier commit rather than rebuilt from the onchain/
sources in the release. So OK meant the manifest agreed with the baked
blueprint, not with the source you were verifying against.
The deployed preprod validators are unaffected. Their identities were
established by deploy-day records independently of this command, and hands-on
lifecycle runs against the live deployment behaved correctly. What was weakened
is the independent check, not the deployment. No action is required of you.
The fix ships in v0.4.0, which builds the blueprint from the release's own
sources. From that release the line names its toolchain — rebuilt from source under aiken 1.1.23 — because "rebuilt from source" only means something if you
can tell which toolchain rebuilt it. Tracked as issue #235.
ckeri 0.1.1 [latest]
ckeri 0.1.1
Maintenance
- Merge pull request #211 from lambdasistemi/release/cabal-release
Erratum — added 2026-08-04
ckeri manifest verify did not rebuild from source in this release.
The command printed manifest verify: OK — rebuilt from source; all hashes and on-chain references are live. The on-chain half was true: hashes and transaction
references were checked against the live chain. The "rebuilt from source" half
was not. The binary shipped with a compiled Plutus blueprint baked in as a
default, frozen at an earlier commit rather than rebuilt from the onchain/
sources in the release. So OK meant the manifest agreed with the baked
blueprint, not with the source you were verifying against.
The deployed preprod validators are unaffected. Their identities were
established by deploy-day records independently of this command, and hands-on
lifecycle runs against the live deployment behaved correctly. What was weakened
is the independent check, not the deployment. No action is required of you.
The fix ships in v0.4.0, which builds the blueprint from the release's own
sources. From that release the line names its toolchain — rebuilt from source under aiken 1.1.23 — because "rebuilt from source" only means something if you
can tell which toolchain rebuilt it. Tracked as issue #235.
ckeri 0.1.0 [latest]
ckeri 0.1.0
Maintenance
- Merge pull request #203 from lambdasistemi/release/cabal-release
Known issue: DEB and RPM withdrawn
The DEB and RPM assets originally attached to this release reported package
version 1.0 instead of 0.1.0, due to a bug in how the Linux packaging
step derived the version (see
lambdasistemi/cardano-keri#207
for the root cause and fix). Neither asset had been downloaded
(downloads=0 on both at the time of withdrawal), so they have been
removed from this release rather than left in place with a wrong version
that would also have blocked future upgrades in apt/dnf.
The AppImage above is unaffected — it was always version-correct and is
independently verified in the attached clean-environment transcript
(T196-A-4-clean-download-transcript.log).
Corrected DEB and RPM packages (and a fresh AppImage) will ship in
v0.1.1, produced by the same pipeline with the fix applied.
Erratum — added 2026-08-04
ckeri manifest verify did not rebuild from source in this release.
The command printed manifest verify: OK — rebuilt from source; all hashes and on-chain references are live. The on-chain half was true: hashes and transaction
references were checked against the live chain. The "rebuilt from source" half
was not. The binary shipped with a compiled Plutus blueprint baked in as a
default, frozen at an earlier commit rather than rebuilt from the onchain/
sources in the release. So OK meant the manifest agreed with the baked
blueprint, not with the source you were verifying against.
The deployed preprod validators are unaffected. Their identities were
established by deploy-day records independently of this command, and hands-on
lifecycle runs against the live deployment behaved correctly. What was weakened
is the independent check, not the deployment. No action is required of you.
The fix ships in v0.4.0, which builds the blueprint from the release's own
sources. From that release the line names its toolchain — rebuilt from source under aiken 1.1.23 — because "rebuilt from source" only means something if you
can tell which toolchain rebuilt it. Tracked as issue #235.