Proposal: fixed uuid in overview
Hi,
My test have pointed that uuid of items change when we move them from one vault to another.
We use UUID extensively in our scripts and this may become an issue if we decide to reorganize our vaults.
Could it be possible to introduce a true UUID that will not change when moving an item to one vault to another ?
Thanks,
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @mickael,
Good question!
Technically, yes. I doubt that it's something we'll change though. Let me elaborate on why, since I was the one who changed how this works in 1Password.
Historically, 1Password used to retain item UUIDs when you moved an item across vaults. It would even retain the UUID if you exported an item to something like 1pif, and the re-imported it. This was super nice as it meant that you could perform the copy multiple times and the same item would get overwritten as opposed to a "duplicate" item being created.
The downside here was that there was an element of trust that we didn't feel comfortable with. For example if a friend sends me a 1pif file with items they'd like me to import, if that friend knows of UUIDs of my items then they could craft the file such that my items are overwritten. This could be done maliciously, or accidentally. In both cases the result is pretty bad.
That doesn't mean that the current state of things is great though. Not trusting any UUIDs an always creating a new one has its benefits, but there are pretty harsh downsides too. Copy the same item to the same vault twice... get two items. Gross. I'm not happy with that, and nor is anyone else here. So we've got some work to do there. I think we can achieve what most people are looking for without actually needing to retain the exact same UUID. We have some ideas there, we just need to find the time to implement them. For one of the features we want to build, having a solution to that problem is a pre-requisite, so hopefully we can get around to that sooner rather than later.
Rick
0 -
Het @rickfillion Thanks for the details.
I understand the reasons and I doubted it was a security-related problem.
My vision would be to introduce a "fixedUUID" alongside UUID.
This fixedUUID would get maintained over move actions only, but on copy it will get the UUID of the copied item.
This fixed would be exposed in the overview details and queryable through the cli with a special argument.
What do you think about that?
Another more generic solution could be to allow the creation of custom fields in the overview part and make them queryable through CLI.
Mickaël
0 -
That solution looks similar to one that I proposed, @mickael.
Rick
0 -
:+1:
0 -
Thanks for bringing it up! :chuffed:
0
