gopass
gopass copied to clipboard
Using caps in Keys causes issues
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)
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.
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?
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
.
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?
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.
This is probably related to #1991 which is fixed by #1997
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
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.