Cipher update time is modified on folder change #1789

New Issue

OVERLORD · 2025-10-09T17:30:13+03:00

OVERLORD commented

2025-10-09 17:30:13 +03:00

Originally created by @jjlin on GitHub.

When changing the folder that a cipher/entry belongs to, the cipher update time is modified, even if the actual contents of the entry were not modified. This is arguably acceptable behavior for an entry owned by a single user, but for an org-owned entry, it has some unintuitive consequences. That is, if someone you've shared the entry with decides to organize it into a folder on their side, that shouldn't be shown as an update to all other users the entry is shared with, because

It can be confusing/concerning to see an unexpected change to the update timestamp.
The "updated" entry is synced to all users who have read access, even though nothing has actually changed.

Originally created by @jjlin on GitHub. When changing the folder that a cipher/entry belongs to, the cipher update time is modified, even if the actual contents of the entry were not modified. This is arguably acceptable behavior for an entry owned by a single user, but for an org-owned entry, it has some unintuitive consequences. That is, if someone you've shared the entry with decides to organize it into a folder on their side, that shouldn't be shown as an update to all other users the entry is shared with, because * It can be confusing/concerning to see an unexpected change to the update timestamp. * The "updated" entry is synced to all users who have read access, even though nothing has actually changed.

OVERLORD added the low priority enhancement labels 2025-10-09 17:30:13 +03:00

OVERLORD closed this issue

2025-10-09 17:30:14 +03:00

OVERLORD commented

2025-10-09 17:30:15 +03:00

@BlackDex commented on GitHub:

Since this is just how Bitwarden works. And it still works the same 5 years after. I'm going to close this one as it is just how it is. As mentioned there is a partial fix by using a different way of adjusting the folder.

And, since updating a single cipher always re-encrypts the values, we are not able to detect nothing else has changed either.

@BlackDex commented on GitHub: Since this is just how Bitwarden works. And it still works the same 5 years after. I'm going to close this one as it is just how it is. As mentioned there is a partial fix by using a different way of adjusting the folder. And, since updating a single cipher always re-encrypts the values, we are not able to detect nothing else has changed either.

OVERLORD commented

2025-10-09 17:30:15 +03:00

@BlackDex commented on GitHub:

This also happens during key-rotation when changing the password and checking the Also rotate my account's encryption key.
I think that should not be the case, since it will mess-up the users whole vault because every cipher is being saved again.

@BlackDex commented on GitHub: This also happens during key-rotation when changing the password and checking the `Also rotate my account's encryption key`. I think that should not be the case, since it will mess-up the users whole vault because every cipher is being saved again.

OVERLORD commented

2025-10-09 17:30:15 +03:00

@BlackDex commented on GitHub:

This is something which also happens upstream if i'm correct.
Also, if a cipher is not writeable by a user, they can't even put it in a folder at all using upstream, in my opinion that isn't good logic, so i think how bitwarden_rs has it is better.

@BlackDex commented on GitHub: This is something which also happens upstream if i'm correct. Also, if a cipher is not writeable by a user, they can't even put it in a folder at all using upstream, in my opinion that isn't good logic, so i think how bitwarden_rs has it is better.

OVERLORD commented

2025-10-09 17:30:16 +03:00

@jjlin commented on GitHub:

Yeah, that's correct. It stems from how per-cipher and per-user data is mixed together, which requires extra unmixing work to get the right behavior. Neither upstream nor bitwarden_rs are doing the unmixing currently, as I noted here:

4628e4519d/src/api/core/ciphers.rs (L499-L506)

@jjlin commented on GitHub: Yeah, that's correct. It stems from how per-cipher and per-user data is mixed together, which requires extra unmixing work to get the right behavior. Neither upstream nor bitwarden_rs are doing the unmixing currently, as I noted here: https://github.com/dani-garcia/bitwarden_rs/blob/4628e4519de043aae343b4d0a1e2f110bd40aa8a/src/api/core/ciphers.rs#L499-L506

OVERLORD commented

2025-10-09 17:30:16 +03:00

@BlackDex commented on GitHub:

This is btw partially fixed when moving ciphers via the multiple-select flow. Doesn't matter if you tick one or multiple boxes.
But for all the ciphers ticked, and then using the 3dot main menu and select Move selected, they will be moved, but without updating the cipher update time.

@BlackDex commented on GitHub: This is btw partially fixed when moving ciphers via the _multiple-select_ flow. Doesn't matter if you tick one or multiple boxes. But for all the ciphers ticked, and then using the 3dot main menu and select `Move selected`, they will be moved, but without updating the cipher update time.

OVERLORD referenced this issue

2025-10-09 18:22:05 +03:00

[PR #1789] [CLOSED] Only create private key in pem format if it doesn't already exist #3365

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1789