1.10 breaks `pass` cross-utility.

[dg01d]

Summary

One of the primary motivating factors for using gopass was the promised:-

100% API-compatible to pass Every other app will work with the basics of gopass, too. Just jump in with your existing setup!

With the latest update, this is Not the case, resulting in broken workflows and implementation.

Steps To Reproduce

1. Add a new password using gopass create
2. Call for the password using pass -c /websites/example.org/user
3. Paste the result, or use it in a script
4. Password fails, because the password has been set as GOPASS-SECRET-1.0, and not as the password

Expected behavior

1. Add a new password using gopass create
2. Call for the password using pass -c /websites/example.org/user
3. Paste the result, or use it in a script
4. Password succeeds, because gopass correctly set the first line of the secret as the password

Environment

Mac OS X Mojave 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64 gopass 1.10.1 go1.15 darwin amd64 homebrew installation

[dg01d]

@dominikschulz added the wont-fix label

That's... disappointing.

[dominikschulz]

Making this feature the default in 1.10 was a mistake we're currently trying to fix. Dropping the aspirational pass compatability goal from the docs was not a mistake.

So part of this might get fixed, but not all of it.

[ckolumbus]

@dg01d as a side note: i've implemented the gopass-summon-provider which implements a fixed 'stdout interface' for usage with summon. With this we're reusing all the business logic, but decouple the 'stdout interface'. Maybe this could be a solution to support workflows that are dropped by vanilla gopass?

[AnomalRoil]

Notice that pass compatibility is kept if you set the mime config to false.

We will disable Mime by default in 1.10.2, and we are studying how to reintroduce it in a smoother way in 1.11.

[AnomalRoil]

This was solved in #1665