After Migrating to v5.3.2, creating Secrets results in "The metadata private key was already edited by the user."

[AlwinEgger]

We migrated a long existing instance to v5.3.2 (EE). We use a Docker installation.

After migrating the metadata we can't create new secrets. The following error is issued: "The metadata private key was already edited by the user."

The location this is happening:

passbolt_api/plugins/PassboltCe/Metadata/src/Service/MetadataPrivateKeysUpdateService.php

Line 69 in 8d7f8bd

throw new BadRequestException(__('The metadata private key was already edited by the user.'));

We would appreciate any hints to the cause of this.

[cedricalfonsi]

This appears to be an issue that was addressed in v5.1.0. Specifically, the created_by and modified_by properties in the metadata_private_keys table should have been set to null during the migration to allow users to update them after trusting the keys.

Could you confirm if the enablement of encrypted metadata was performed using a version later than v5.1.0? Additionally, could you specify whether the enablement was performed using the command-line tool or through the web application?

[AlwinEgger]

Hmm... very unsure about this. I guess we had enabled it as soon as it was available.

[cedricalfonsi]

If the issue persists after updating to the latest version, you can set the created_by and modified_by properties of the metadata_private_keys item corresponding to the faulty user, then retry the operation that was failing.

[AlwinEgger]

Thank you @cedricalfonsi for your help. I only had time today to get back to this issue.

I did have two users with a match on this query:

select k.user_id, k.modified, k.modified_by, k.created, k.created_by, u.username from metadata_private_keys k left join users u on u.id = k.user_id where k.user_id = k.modified_by;

Updating modified_by to another user_id fixed the issue:

update metadata_private_keys set modified_by = '[another_user_id]' where user_id = '[user_id_found_above]';

After the successful creation of a new secret the modified_by field switched back to the user_id of the owner. Other data must have changed since creation and modification of secrets is possible from this point on.

Fixed!

[AlwinEgger]

Although we know how to fix the immanent problem, this issue reoccurs after some time of passbolt usage. Any idea what could be the source of this problem?

Context:

• Passbolt 5.6.0 (Browser Plugin and Server)
• data-check: passed

[stripthis]

Closing as we are not able to reproduce and not getting further reports from other users.