Allow otp: field prefix for yaml compatability

[ecoutu]

It would be nice if pass files were yaml compliant.

Allowing otp uri's to be prefixed with otp: otpauth://* follows a standard convention and allows for parsing pass file contents as yaml.

[tadfisher]

pass doesn't mandate this, and the default behavior is not YAML-compliant (bare password is expected on the first line). Do you have an example of a tool that parses pass files as YAML?

[ecoutu]

Yes, you are absolutely correct that pass does not mandate this. It is coincidental that pass file "conventions" happen to loosely mimick yaml (aside from the unprefixed password on line one). I have my own pass extension that allows querying pass formatted files for keys and values, eg:

$ echo 'abc\nRecoveryToken: abcdef\nOTP: otpauth://' | pass insert -m yaml-test
Enter contents of yaml-test and press Ctrl+D when finished:

[master d2eafdb] Add given password for yaml-test to store.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 yaml-test.gpg
$ pass yaml-test
abc
RecoveryToken: abcdef
OTP: otpauth://
$ pass yaml yaml-test
RecoveryToken: abcdef
OTP: otpauth://
$ pass yaml keys yaml-test
RecoveryToken
OTP
$ pass yaml values yaml-test RecoveryToken
abcdef

It would be a boon being able to use a standardized syntax for pass formatted files to allow integration with other tooling. The pass file "convention" does not mandate yaml interoperability as a requirement. If this extension optionally allowed a prefix, would that be something you would accept a P/R for?

eg:

abc
RecoveryToken: abcdef
OTP: otpauth://...

[marcthe12]

Well there is no need for pure yaml, but its definitely a convention that all non password fields have a key: value convention. So doing could allow tools to parse it better. I believe some guis like qtpass can allow to use this convention for non password fields.