Using kv-v2 gets either "unsupported operation" or stacktrace and empty secrets

[dietmarb01]

The kv-v2 supports the LIST operation only on mount/metadata/, while retrieval of secrets is limited to mount/data/
(see https://www.vaultproject.io/api/secret/kv/kv-v2#list-secrets)

I am using Vault-1.8.1 (latest as of today)

As there is only a single "path" field to be specified in the sync-entry, which one to use?

Using .../metadata seems to synchronize entries (i.e. it re-creates the tree and adds entries), but none of the entries has any fields.

Using .../data tells me it has fetched some keys, but hickups on the return value from Vault (also note the doubled '/' on the path). The structure is not re-created within KeePass.

Exception for e2/metadata/path/to//my//secret: Unexpected character encountered while parsing value: {. Path 'data.versions', line 1, position 325.
   at Newtonsoft.Json.JsonTextReader.ReadStringValue(ReadType readType)
   at Newtonsoft.Json.JsonTextReader.ReadAsString()
   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateDictionary(IDictionary dictionary, JsonReader reader, JsonDictionaryContract contract, JsonProperty containerProperty, String id)

[dietmarb01]

additional question: Is there a way (and a need) to explicitly specify the mountpoint of the secrets engine?

[Karreg]

Hi,

Sorry but I won't have all answers, only guesses.

I don't know about vault 2.0 yet, but from what you are saying, this will probably be more a matter on the vault.net library than on this plugin. Though the project was active when the plugin was developped, it looks like it is now in a stale state. And I don't have (for now) time to work on it, or switch to an internal, more specific, implementation. However, it should not be that hard, so I'll keep that in mind. The library already prevents us from fetching secrets in complex JSON format. Only dictionaries are accepted.

And here we are with your second point. This is the behavior with complex JSON secrets. These secrets can't be created in KeePass due to the issue above.

For example :

{
  "key1": "value1",
  "key2": "value2",
  ...
}

will work fine. Some fields will be stored in username, password and URL, all other fields will be stored in the advanced fields.

However, this won't work, since it can't be deserialized as a dictionary.

{
  "key1": {
                "subkey1": "value1"
              },
  {
    "subkey2" : "value2"
  }
}

Can you check the content of your secrets? Maybe paste an (anonymized) sample here?

[dietmarb01]

Hi,
thanks for coming back to me.

I continued to experiment, and I can now confirm that

• it works with Vaults "legacy" kv-secrets engine (version 1)
• it does NOT work with the newer kv-v2 secrets engine (https://www.vaultproject.io/docs/secrets/kv/kv-v2)

My secrets are all "flat" (plain dict, no multi-level nesting), so not an issue there.
Kv-v2 splits between data and metadata (additional path element!) and those two support different types of operations.

It would be great to support kv-v2 as well;-)
Does anyone have a "dev-container" with a development environment inside it to build the plugin?

[dietmarb01]

BTW, I should add that the plugin does a nice case-insensitive, ~fuzzy matching from the fields in the Vault secret and KeePass's native User/Password/Url/Notes fields :-) (e.g. /username|user|User/ --> "User")

The Advanced tab appears to contain all fields with names that are NOT an exact match of whatever the internal field name of a KeePass field is, e.g. "Notes" or "Password" are not shown there "url" (lowercase) is there, and "User" is show both in the "Entry" and the "Advanced" tab.

[mendhak]

Yes please, v2 support would be great. My workplace is using a v2 backend, it'd be great to be able to use this plugin with that setup.

[Karreg]

Sorry guys for the lack of activity of this projects, I'm absolutely out of time to work on it... :(
I already had a come back after 2 years of inactivity, I hope it will be less long next time...

[mendhak]

Hey no worries at all, I totally understand about lack of time. Stuff happens.

[seyfbarhoumi]

kv-v2 support would be a great improvement