Mark some features as deprecated

[dominikschulz]

Signed-off-by: Dominik Schulz dominik.schulz@gauner.org

[jjthiessen]

Do we know when TOTP support is slated for removal?

Also, are there any recommendations for a tool that can take an otpauth:// URI via stdin (or arbitrary fd), and output a code? It'd be easy enough to write something, but if there's a good solution out there already — why re-invent the wheel.

[dominikschulz]

That depends if someone steps up to maintain it.
I never liked the idea of having OTP support in gopass because it encourages questionable behaviour (i.e. storing two factors in the same place). I did only add it because a colleague asked for it. I've never used this feature so I won't notice if it's broken and I also don't have any incentive to fix it.

We're planning for several breaking changes in a 2.0 release anyway and that's the point when we need to have a decision on OTP support. If nobody has stepped up by then it will be dropped.

[nokernel]

I am using Gopass mainly for OTP ;). It is soo usefull, no need to move OTP secrets between phones and devices.

Sadly I can't step in to maintain that. Lacking time and golang knowledge...

That is a very useful feature for me :). Mostly I set it up with yaml entries

---
totp: secret_token

I have 2 gopass repo on different git hosts. One git for the passwords, and another git repo for OTP.

[avanier]

I'm going to step up as well. I use gopass with OTP every day, it's one of gopass's best features.

While I do agree about the whole totp alongside secrets is not best practice, there are certainly ways to mitigate that.

I'm not savvy enough on this codebase to understand the challenges brought by the 2.0 release. May I ask you to point me to some information or detail the challenge in a separate issue? I might be able to find a friend or two to help me with this.

[dominikschulz]

Thanks for speaking up. Good to know it's considered useful.
Given the support I think we can argue that we should keep OTP in.

However HOTP seems to be broken and unless someone steps up to fix it I'll drop it from the documentation and close any bugs about HOTP as wont fix.

TOTP will remain as is and we'll try to fix it if it breaks.

[avanier]

w00t! That's a more than acceptable outcome! Thank you! 🙏 🙏

[nokernel]

Very nice :) thank you @dominikschulz. I really should get into golang to help in this project.

[devhell]

Yes, thank you! I and a number of my colleagues use totp as well quite a lot. :)

[tetrodoxin]

Or better here, the short question:
What what the actual reason to deprecate the feature of handling binary files?

[dominikschulz]

Binary support in it's current form is hacky and relies on some heuristics. And in the end it's just wrapper around base64. Even if we kill it, you can still handle binary data by pipeing through base64.

We have some ideas how considerably improve this without the use of error prone heuristics.

[fgarcia]

May I ask why yaml is deprecated? Without that every entry is just a password and plain text, but with a yaml frontmatter one gets structured data. To me it looks like the basics to enable third party scripts/plugins.

Should I assume that dropping yaml also means that the concept of structured data and custom fields will be gone too?

Right now I have my own set of conventions around some custom fields like:

• tags
• project name
• phone number (in case the recovery codes are linked to an outdated number)
• allocated security keys (to track I do not have sites with just one yubikey)
• keyfile locations for an encrypted drive

[dominikschulz]

The current YAML implementation is relying on broken heuristics to somehow ensure compatability with other password store implementations. Also YAML is not intutive for most users (e.g. try to add an unquoted phone number as a YAML value - it will drop the leading zeros).

The current plan is to stop using these heuristics and support proper content types (e.g. MIME or simliar). That way we could properly support YAML or other kinds of structured data.

We don't want to drop the concept of structured data and custom fields without offering a replacement.

But we also don't want to encourage people to start using the current implementation if they don't do already.

[ndarilek]

Sorry to revive this, but how is gopass-git-credentials supposed to be used? It is still in the repo and README, but this issue claims that it is deprecated. Building it manually doesn't work and claims my store isn't initialized though it definitely is, but the logs show changes as recently as yesterday.

Thanks.

[tmccombs]

The current plan is to stop using these heuristics and support proper content types (e.g. MIME or simliar). That way we could properly support YAML or other kinds of structured data.

If you do that, please make it as easy to edit fields as it currently is. And is there a discussion of this migration somewhere?

[dominikschulz]

You can still edit existing files. They wont be converted unless you run gopass fsck --decrypt.

[KlavsKlavsen]

I LOVE the OTP feature as well - with browser plugin its a fantastic way to fill out OTP secrets for websites.
I store my GPG key on a yubikey with touch enabled (the entire company does this :) - so that way it just blinks if I need to insert an TOTP key or userpassword or HOTP. Works really well and ensures backup of my TOTP secrets in an easy and shareable way (as our passwordstore manages which keys can decrypt which secrets)

[AnomalRoil]

@dominikschulz Should we consider adding OTP back as a fully supported feature?

I don't mind maintaining it, I don't use it a lot, but I use it enough for caring.

[dominikschulz]

Sounds good. Feel free to send a PR.