Skip to content

0.9.63

Choose a tag to compare

View all tags
@cevheri cevheri released this 31 Jul 07:32
Immutable release. Only release title and notes can be modified.
0.9.63
87888ae
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Every download in this release is signed, and the launcher checks it

0.9.63 is the first release where every published artifact carries a SLSA build provenance attestation: the standalone archives, the Debian and RPM packages, the Windows zip, the snap, the desktop AppImage and GUI .deb, the npm tarball, and the GHCR container image. Each attestation is signed through Sigstore and names the repository, workflow and commit that produced the file.

Verify any release asset yourself:

gh attestation verify libredb-studio-standalone-0.9.63-linux-x64.tar.gz \
  --repo libredb/libredb-studio \
  --signer-workflow libredb/libredb-studio/.github/workflows/release-artifacts.yml

The container image and the npm package have their own trust roots:

gh attestation verify oci://ghcr.io/libredb/libredb-studio:0.9.63 --repo libredb/libredb-studio
npm i @libredb/studio && npm audit signatures

The npx launcher enforces it

npx @libredb/studio already verified the archive's SHA256 against the release's SHA256SUMS. That check has a gap: an attacker who can replace a release asset can replace its checksum line too. So after the checksum passes, the launcher now also runs gh attestation verify on the downloaded archive, pinned to the workflow that signs releases - an attestation from any other workflow, or from a branch build, fails the policy.

The outcome is deliberately tri-state:

Outcome Launcher
Verified prints Provenance verified and starts
Cannot verify - no gh, not authenticated, no network, API rate limit, or a release older than 0.9.63 warns, naming the reason, and starts on checksum alone
Rejected - the attestation fails the signer policy, or a release from 0.9.63 on has no attestation for the archive's digest refuses to start

The last row is what the feature exists for: for a release that must carry an attestation, "GitHub holds no attestation for this digest" is a tampering signal, not missing information. gh stays optional - the package keeps its zero-runtime-dependency contract, so everything that merely prevents verification warns and continues. To start anyway after a rejection (for example during a GitHub attestation outage): LIBREDB_STUDIO_SKIP_PROVENANCE=1.

The check runs where checksum verification runs: on a fresh download and on --verify-cache, never on a plain cache hit, and never for a locally built --archive.

The SQL editor works air-gapped

Monaco is now served from the app's own origin instead of a CDN, so the workspace opens on a machine with no internet access - a deployment inside a closed network no longer lands on an editor that never finishes loading. The Explain action also stays in step with the active connection's provider, so switching from, say, PostgreSQL to SQLite no longer leaves the previous provider's plan behaviour in place.

Fixes

  • SQLite is now offered in the connection form's type picker. It was supported everywhere else, but could not be selected when creating a connection.
  • An already-released Helm chart version can no longer be re-published. A charts/** change that did not bump the chart version used to rewrite that version's repository index digest and its OCI copy while the release asset kept the original bytes; both publish surfaces are now gated, and the same rule is enforced at PR time.

Distribution

The Flatpak channel moved: FlatPark is live and is now the Flatpak route for LibreDB Studio, while the Flathub submission is marked deprecated in-repo. Every Flatpak instruction in the docs points at FlatPark.

Chart 0.1.24 tracks this release; no chart template changed, so its rendered manifests are identical to 0.1.23.

Full changelog: 0.9.62...0.9.63

Assets 27
Loading