chore: release

[github-actions]

🤖 New release

• pg-core: 0.6.3 -> 0.6.4 (✓ API compatible changes)
• pg-pkg: 0.6.1 -> 0.6.2
• cryptify: 0.1.29 -> 0.1.30
• pg-cli: 0.3.8 -> 0.3.9

Changelog

pg-core

0.6.4 - 2026-08-18

Added

• (pg-core) canonicalize identity attribute values before deriving (#335)

Fixed

• (pg-core) bind the public signing policy into the AEAD plaintext (#351)
• (pg-core) name the version constants after their wire values (#345)

Other

• assert main's ruleset still requires the gate build.yml produces (#333)

pg-pkg

0.6.2 - 2026-08-18

Added

• (pg-core) canonicalize identity attribute values before deriving (#335)

Fixed

• (cryptify) build dev.Dockerfile from the repo root, like its sibling (#329)

Other

• guard the Dockerfile/workspace-member invariant, scope the dev cook (#326)

cryptify

0.1.30 - 2026-08-18

Added

• (cryptify) serve the configured max upload-chunk size on init (#346)
• (cryptify) restore upload sessions on boot (#330)

Fixed

• (cryptify) build dev.Dockerfile from the repo root, like its sibling (#329)

pg-cli

0.3.9 - 2026-08-18

Other

• updated the following local packages: pg-core

---

This PR was generated with release-plz.

[dobby-coder]

Thanks for the heads up! I'm on it — taking a look at this pg-pkg 0.6.1 → 0.6.2 release PR now and will follow up with a review.

[dobby-coder]

Release PR looks correct — approving the change itself. One thing blocks the merge button and it needs a click from you, not an edit here.

⚠️ Merge is blocked on workflow approval, not on this diff

All four workflow runs on this branch were created but are held in action_required (awaiting approval, 0s duration):

Workflow	Status
Continuous integration	action_required
Delivery	action_required
API diff	action_required
PR Title	action_required

The main: required checks ruleset (id 20607291, active) requires exactly one context: Wire compat. That job lives in .github/workflows/build.yml — inside Continuous integration — so while that run is unapproved the required check never reports at all. The result is mergeStateStatus: BLOCKED with 0 checks on the head sha (e6d9e34), and no amount of waiting clears it.

Fix is one click: Approve and run workflows on the PR's checks tab. This is the same state PR #278 was in — its checks only started at 2026-08-10T12:25Z, long after it was opened on 2026-07-31, then it merged at 13:18Z.

Expect it on every release-plz PR. Note the mechanism precisely, because it is not the usual "a GITHUB_TOKEN push starts no workflows" case: the head branch is in this repo (isCrossRepository: false), the runs were created, and they are sitting behind an approval gate because the PR's author is github-actions[bot], which the gate does not treat as a collaborator. So a permanent fix is either running release-plz-pr under a PAT / app token whose identity is a collaborator, or relaxing the repo's require-approval-for-contributors setting — not just a token swap. I could not read /repos/.../actions/permissions to confirm which setting is in force (403 for my token), so please check that before changing anything.

What I verified on the release content

• Patch bump is right. The only commit on main since tag pg-pkg-v0.6.1 is fa4df1b (test: guard the Dockerfile/workspace-member invariant, scope the dev cook, #326). No ! in the title, no public-API change — 0.6.1 -> 0.6.2 is correct, and this repo reads a break off the PR title only, so nothing here should have cut a major.
• Changelog placement is right. The generated [0.6.2] section sits below ## [Unreleased] and above ## [0.6.1]; no already-released section was edited, and no hand-written bullet is stranded under [Unreleased].
• Lockfile is in sync. Cargo.lock moves pg-pkg to the same 0.6.2.
• The publish job exists. delivery.yml tags the image from needs.release-plz-release.outputs.pg_pkg_version, so unlike the cryptify-v0.1.28 case this version will not end up as a release with no artifact — worth checking GHCR for the 0.6.2 tag after merge anyway, since the release and the image push are separate events.

Note: the 0.6.2 image is behaviourally identical to 0.6.1

fa4df1b touched only pg-pkg/tests/dockerfile_workspace_members.rs (new), dev.Dockerfile and CLAUDE.md — nothing under pg-pkg/src/, and not the repo-root Dockerfile that builds the released image. So the changelog line describes a test and a dev-image change, and ghcr.io/encryption4all/postguard:0.6.2 will behave exactly like :0.6.1. Nothing wrong — release-plz generated the entry faithfully from the commit subject — just don't expect the new tag to change anything for a deployment, and no need to hurry the ops pin to it.

One carried-forward nit on pg-pkg/Cargo.toml inline below.

[dobby-coder]

Pre-existing (also on main, not introduced by this PR), but this bump is where it bites: pg-pkg/src/opts.rs:6-7 hardcodes name = "irmaseal-pkg", version = "0.2", so the binary this release ships still prints irmaseal-pkg 0.2 for --version while the crate moves to 0.6.2 — the pre-rename name and a version frozen nine minor releases back.

That is the crate's only version surface: there is no CARGO_PKG_VERSION anywhere in pg-pkg/src (verified — zero hits), and /health returns no version either. So once delivery tags the image 0.6.2 there is no way to confirm from inside a running container which build is actually deployed.

Fix is version = env!("CARGO_PKG_VERSION") (or clap's derive #[command(version)]) plus dropping the stale irmaseal-pkg name. Worth its own small PR rather than touching this auto-generated one.

[dobby-coder]

Reviewed and approved this one — the 0.6.2 patch bump is correct (only commit since 0.6.1 is a test: change), the changelog entry is placed right, and Cargo.lock is in sync: review.

One thing needs a human click, not a code change: all 4 workflow runs are stuck in action_required because the ruleset doesn't treat github-actions[bot] as a collaborator, so the PR shows 0 checks and stays blocked until someone hits Approve and run workflows on the runs. It won't clear on its own — PR #278 hit the same thing and sat for over a week until approved.

Two non-blocking notes left inline: pg-pkg still hardcodes irmaseal-pkg 0.2 in --version output (pre-existing, worth its own PR), and this release is behaviorally identical to 0.6.1 since the only change touched tests/Dockerfile, not pg-pkg/src/.

I also saved a rule so the next release-plz PR gets this diagnosed immediately instead of looking like a CI failure.