chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@e4a/pg-js@2.4.1

Patch Changes

• 9f61ed0: Stop presenting the pre-decryption sender on /download as verified.

  The Ready state (the screen with the Yivi QR on it, before any user secret key exists and before anything is decrypted) rendered a green tick, the copy "The files are from", and the signing attribute chips next to a sender address read straight off the sealed header via Opened.inspect(). That value carries a valid signature over the header bytes, but nothing binds it to the ciphertext (sender authenticity: the public signing identity is swappable, so any authenticated user can spoof the displayed sender postguard#338): any party the PKG will issue a signing key to can re-sign someone else's header with their own key and be shown in its place. The pg-core change that would detect that swap (pg-core: bind the public signing policy into the AEAD plaintext, so a swapped h_sig_ext is rejected postguard#347) works inside the AEAD, so even once it ships in a @e4a/pg-wasm release it can only run during decryption, and will never reach this screen.

  Ready now keeps the address, because it is what the user needs to decide whether to scan at all and withholding it would make them pay the Yivi cost before learning anything. What it drops is the tick and the chips. The label reads "These files claim to be from", with the caveat "We can confirm this only after decryption." The Confirm and Done states are unchanged; they render result.sender from decrypt(), and whether a post-decryption tick is warranted at all is sender authenticity: the public signing identity is swappable, so any authenticated user can spoof the displayed sender postguard#338's question rather than this change's.

  In @e4a/pg-js this is a documentation change only, with no identifier renames. The doc comments on InspectResult.sender, InspectSealedResult.sender, inspectSealed() and Opened.inspect() now state that the identity is claimed rather than verified. They stop short of promising that decrypt()'s sender is bound to the ciphertext, because it is not: the public signing policy travels outside the AEAD in the pinned @e4a/pg-wasm (0.6.1) and in every version published as of 2026-08-10 (0.6.3 is the newest), so the swap is reported after decryption too. postguard#347 adds an AEAD-protected copy of the public signing policy to pg-core, and the comments say what it will take for that copy to reach a consumer of this SDK.

postguard-outlook-addin@1.0.2

Patch Changes

• 7767706: Request ReadWriteItem in the manifest instead of ReadWriteMailbox.

  ReadWriteMailbox is the highest permission tier, and an add-in that asks for it can only be installed by an administrator. An individual user cannot sideload it. Nothing in the add-in needs that tier: Microsoft annotates every Office.js member with its minimum permission level, and across the members reachable from src/ the maximum is read/write item, from six compose writes (Body.setAsync, removeAttachmentAsync, addFileAttachmentFromBase64Async, saveAsync, InternetHeaders.setAsync and InternetHeaders.removeAsync). The mailbox-tier members an add-in can reach are all unused: makeEwsRequestAsync, getSelectedItemsAsync, loadItemByIdAsync, masterCategories and sendAsync. So are getCallbackTokenAsync, restUrl and ewsUrl; the read flow avoids EWS deliberately.

  test/manifest-permission.test.ts pins both halves: the tier the manifest declares, and the absence from src/ of any member that would need the wider one.

  A changed permission tier freezes existing installations until an administrator re-consents (Manifest format for the store: XML add-in manifest or unified Microsoft 365 manifest? #240), so this is much cheaper before the first AppSource submission than after.

• Updated dependencies [9f61ed0]

  • @e4a/pg-js@2.4.1

postguard-tb-addon@0.9.6

Patch Changes

• Updated dependencies [9f61ed0]
  • @e4a/pg-js@2.4.1

postguard-website@1.8.4

Patch Changes

• 9f61ed0: Stop presenting the pre-decryption sender on /download as verified.

  The Ready state (the screen with the Yivi QR on it, before any user secret key exists and before anything is decrypted) rendered a green tick, the copy "The files are from", and the signing attribute chips next to a sender address read straight off the sealed header via Opened.inspect(). That value carries a valid signature over the header bytes, but nothing binds it to the ciphertext (sender authenticity: the public signing identity is swappable, so any authenticated user can spoof the displayed sender postguard#338): any party the PKG will issue a signing key to can re-sign someone else's header with their own key and be shown in its place. The pg-core change that would detect that swap (pg-core: bind the public signing policy into the AEAD plaintext, so a swapped h_sig_ext is rejected postguard#347) works inside the AEAD, so even once it ships in a @e4a/pg-wasm release it can only run during decryption, and will never reach this screen.

  Ready now keeps the address, because it is what the user needs to decide whether to scan at all and withholding it would make them pay the Yivi cost before learning anything. What it drops is the tick and the chips. The label reads "These files claim to be from", with the caveat "We can confirm this only after decryption." The Confirm and Done states are unchanged; they render result.sender from decrypt(), and whether a post-decryption tick is warranted at all is sender authenticity: the public signing identity is swappable, so any authenticated user can spoof the displayed sender postguard#338's question rather than this change's.

  In @e4a/pg-js this is a documentation change only, with no identifier renames. The doc comments on InspectResult.sender, InspectSealedResult.sender, inspectSealed() and Opened.inspect() now state that the identity is claimed rather than verified. They stop short of promising that decrypt()'s sender is bound to the ciphertext, because it is not: the public signing policy travels outside the AEAD in the pinned @e4a/pg-wasm (0.6.1) and in every version published as of 2026-08-10 (0.6.3 is the newest), so the swap is reported after decryption too. postguard#347 adds an AEAD-protected copy of the public signing policy to pg-core, and the comments say what it will take for that copy to reach a consumer of this SDK.

• Updated dependencies [9f61ed0]

  • @e4a/pg-js@2.4.1