Using caps in Keys causes issues

[AnomalRoil]

Summary

It used to work.

Steps To Reproduce

Create a new secret t1 containing:

secret
User: test

Display it (with safecontent set to true):

$ gopass show t1
Secret: t1

User:

with safecontent set to false it works (but adds a trailing newline):

Secret: t1

secret
User: test

Furthermore the key User is not recognized:

$ gopass show t1 user

Error: key not found in entry

Both with User and with user as the queried keys and both with and without safecontent enabled

Expected behavior

It should just not display the "secret" if safecontent is set (and the unsafe keys, if these are used)

[aivarsV]

Is pr #1778 really the best solution for this? I mean, If I store key/value pairs with keys in CamelCase, I exepect them to show up in CamelCase with gopass show. But now gopass show has unpredictible behavior (at least with my password store), where keys for some secrets are printed in lower case, while, for others case is preserved. However, when I use gpg edit secret, keys show up in my editor in expected case. Also, gpg --decrypt /path/to/secret.gpg shows me keys in correct case.

gopass 1.12.1 (2021-02-25 17:21:56) go1.16 linux amd64 on Arch Linux.

[AnomalRoil]

Well, here is the logic behind it:

• we do not change the content people are typing / saving in their secrets
• we only support parsing of the said secrets and we display an "interpreted" version of these secrets
• using mixed case to distinguish between secrets seems like something people are unlikely to do

So we are storing everything "as is", which you can check using the gopass show -n <entry> flag to disable parsing on that show call.

So not sure what's best, but currently to not complicate things too much we just handle all keys as lowercase during parsing. By chance, are the keys where case is preserved in the now deprecated "Mime" format? You can run gopass fsck --decrypt to check all your secrets to spot remaining Mime secrets.

That being said, the unpredictable behaviour should not be. Do you have a minimal example to reproduce the issue?

[aivarsV]

Ok, finally got some time to work on this. As always, reading the docs is correct solution - Adding parsing: false in config.yaml solved my issue. I must note here, that man pages would improve situation, since reading docs in github is cumbersome.

Here is showcase of what caused me to write my previous message. Remember, that this was with parsing: true in config.yaml . As I later found out, adding line with three dashes, causes rest of file being interpreted as yaml (whatever that means). This means, that keys are not lowercased and. The fact, that gopass fsck --decrypt didn't complain about those secrets (it did complain about others) made me even more confused. And, as I didn't change any gopass settings, my only conclusion was bug in gopass.

 N  ~ $ gopass show test-store/misc/secret1
Secret: test-store/misc/secret1

some
anotherkey: anotherValue
somekey: some value
thirdkey: val
 I  ~ $ gopass show test-store/Account/example.com 
Secret: test-store/Account/example.com

*LBW^WkEqO;3u^wkVh}H}dks
---
someKey: some val
user: someUser

 N  ~ $ gopass show -n test-store/misc/secret1
Secret: test-store/misc/secret1

some
anotherKey: anotherValue
someKey: some value
thirdkey: val

 N  ~ $ gopass grep someKey
test-store/Account/example.com matches

Scanned 54 secrets. 0 matches, 0 errors
 N  ~ $ gopass grep somekey
test-store/misc/secret1 matches

Scanned 54 secrets. 0 matches, 0 errors

Anyways, Gopass IS A GREAT SOFTWARE. As I mentioned, man page would be great, and, since "YAML support is deprecated.", cosider adding warning about this in gopass fsck.

[dominikschulz]

Thank you for sharing your findings with us.

A man page is a very good idea, and I don't know why we don't have one already. Do you happen to know what the best way to write and ship a man page these days?

[aivarsV]

Just updated my system and noticed, that parsing: false in config.yml is ignored and only gopass show -n <secret> saves the day. I'm using gopass 1.12.8 (2021-08-28 14:31:40) go1.17 linux amd64 from ArchLinux package repository. With gopass 1.12.7 (2021-07-03 10:24:41) go1.16.5 linux amd64 everything works as expected.

[AnomalRoil]

This is probably related to #1991 which is fixed by #1997

[fredleger]

Hit this issue too. The use case is as following:

• we use terraform to provision secrets in a k8s cluster
• we used https://github.com/mecodia/terraform-provider-pass that itself is using gopass internaly to provide password store and terraform integration
• needed to provision a secret from a a field named apiKey in password store
• took one hour to figure i should use apiKey = data.pass_password.my_secret.data.apikey (without capital K)

Seems like a wrong way to do it and i wouldn't expect this until i read this issue

[dominikschulz]

This sounds less then optimal, indeed. However we currently only store lower-case keys.

But I don't remember why we chose to do that. Let me see if we can lift that limitation.