Questions about change of plugin data storage in KeePassRPC2

1

First off, thank you @luckyrat for your fantastic work on Kee / KeePassRPC. You (and all involved) are amazing!

Our Entry configuration is now stored in a “Plugin Data” location rather than a String field.

  1. Can you expand upon this change? This seems like a pretty massive backend change.
    .
    I wasn’t aware that this might have some significant impacts when I was testing 2.0, but now find I (seemingly) can’t directly edit the KeePassRPC data the way I used to. This is quite annoying/troubling, (see this github thread for my rationale & use case)

  2. If one were to clear the plugin cache, is that a recoverable operation, or is my KeePassRPC data completely gone? (Tools>Database Tools>Database Maintenance> Plugin Data>Clear)
    image

  3. Can you point to any documentation on this change and the rational, Pros/Cons, etc? It seems kind of important to understand the implications as a power-user.

Thanks!

2

I’ll expand on it in point 3 later.

Regarding your use case: “In the past, I could update the Kee settings in one entry, get auto-fill working, then copy those settings to additional entries for the same website (when you might have multiple accounts on the same platform, ie work, personal, other users sharing PW database, etc).”

I think you can achieve the same by using the “Duplicate entry” feature of KeePass and editing the username/password rather than copy/pasting the KeePassRPC technical configuration.

While I wouldn’t recommend it, there are probably ways to manipulate this data in the new location - perhaps a KeePass plugin will offer such a feature or KeePass itself through the UI? (last time I looked it was a read-only interface within KeePass itself but that may change if there is demand for the feature). Such a feature would be out of scope of each specific plugin like KeePassRPC though. As a last resort you can export and manipulate the underlying XML of the KDBX file - again, I suspect this risk is not worth the saving of some repetitive steps across several similar entries.

That is the cache of compiled plugin code. If you clear it then KeePass will have to recompile all plugins when you start KeePass again. I’ve never heard of any use for this outside of plugin development workflows, nor any major disadvantage from using it but if you want to know more it would be best to ask on the KeePass forum since it’s not really specific to the KeePassRPC plugin.

In terms of KeePass documentation, when KDBX 4 was released one of the technical notes briefly summarised the rational:

“Up to now, plugins for instance have stored custom data in string fields of entries. This worked, but cluttered up the entry string list and wasn’t nice from a design point of view. As of KDBX 4, every entry and every group has a key-value dictionary, in which plugins can store their data.”
https://keepass.info/help/kb/kdbx_4.html#extobj

Essentially, a lot of people were/are unhappy about the strings part of their KeePass entry containing all the technical configuration of sometimes many different plugins. If one were creating a new plugin then the old strings approach would never be used since it was always known to be a hacky workaround. Since KeePassRPC already had a history of those strings though, we moved very slowly in making this change.

I suspect it would have been mentioned in the release notes for whatever version first enabled the feature (as I say, many years ago now). The recommendation to use the feature for storing data may or may not be directly documented somewhere, or perhaps by means of examples provided by KeePass. It is most certainly discussed at various points over the past decade on the KeePass discussion forum but again I’m afraid I don’t have easy access to any specific posts for you.

Our issue tracking the change is at Store KeePassRPC data in CustomData instead of an advanced string · Issue #24 · kee-org/keepassrpc · GitHub