Skip to content

Add metadataKeyFingerprint and trustNewMetadataKey - #141

Open
juanjorosendo wants to merge 1 commit into
passbolt:mainfrom
juanjorosendo:fix/metadata-key-trust
Open

juanjorosendo wants to merge 1 commit into
passbolt:mainfrom
juanjorosendo:fix/metadata-key-trust

Conversation

@juanjorosendo

Copy link
Copy Markdown

The SDK only trusts a Shared Metadata Key whose private key copy is signed by the user's own key. A copy shared by an administrator is signed by theirs, so those users cannot write v5 metadata and every share fails with "metadata Key has changed, The Callback is nil, There is a Key Pinned but the new one is not trusted", with no key pinned.

The CLI set neither a fingerprint nor MetadataKeyUpdatedCallback, so there was no way past it. metadataKeyFingerprint pins the expected key, and trustNewMetadataKey accepts the one the server offers when the fingerprint is unknown. Both default to off.

Tested against Passbolt 5.16.0 CE with a regular and an administrator account: share fails without either and succeeds with each.

28_resource_share_locked.txtar keeps its negative assertion. Its environment produces the other state it describes, where the user has no private key copy at all, and neither flag applies there.

The SDK only trusts a Shared Metadata Key whose private key copy is signed by
the user's own key. A copy shared by an administrator is signed by theirs, so
those users cannot write v5 metadata and every share fails with "metadata Key
has changed, The Callback is nil, There is a Key Pinned but the new one is not
trusted", with no key pinned.

The CLI set neither a fingerprint nor MetadataKeyUpdatedCallback, so there was
no way past it. metadataKeyFingerprint pins the expected key, and
trustNewMetadataKey accepts the one the server offers when the fingerprint is
unknown. Both default to off.

Tested against Passbolt 5.16.0 CE with a regular and an administrator account:
share fails without either and succeeds with each.

28_resource_share_locked.txtar keeps its negative assertion. Its environment
produces the other state it describes, where the user has no private key copy
at all, and neither flag applies there.
@CLAassistant

CLAassistant commented Oct 13, 2026 •

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@cedricherzog-passbolt

Copy link
Copy Markdown
Contributor

Hi @juanjorosendo,

Thank you for reporting this issue.
I will investigate it and come back to you.

@cedricherzog-passbolt

Copy link
Copy Markdown
Contributor

Ticket associated: PB-55536

@cedricherzog-passbolt cedricherzog-passbolt self-assigned this Oct 15, 2026
@cedricherzog-passbolt cedricherzog-passbolt added the bug Something isn't working label Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants