Gopass: JSON API wrapper assumes `bash` path

[mkaito]

I know, right? What messed up distro doesn't have bash in /bin? Well, NixOS does. In fact, you shouldn't assume to know the path of anything. That's just good practice in general, but is basically enforced on NixOS.

The shebang in the wrapper script doesn't work, because bash on NixOS is actually at /run/current-system/sw/bin/bash. Which is a symlink to the currently system-wide activated bash version. But I digress.

You should either call $(which bash) to get the correct path (for any executable, in fact), or use /usr/bin/env bash.

[falschparker82]

https://xkcd.com/1172/

Seriously though, that shebang is so incredibly standard, I'd rather risk hurting the feelings of the 0,03% obscure operating system users than making the build scripts look like the linux kernel Makefiles.

[dominikschulz]

/usr/bin/env bash is probably the way to go. Or maybe we can just use /bin/sh.

[mkaito]

The Linux kernel makefiles are beautiful!

/bin/sh is actually a standard, unlike /bin/bash, which is just a (very widely spread) convention. Not even the rather esoteric NixOS dares to mess with that.

Bear in mind that sh is (obviously) not bash, even though some distributions arbitrarily decide to have it run by bash anyway (often with stupid consequences).

[dominikschulz]

In general I'd like to try to avoid bash as long as possible and only use bash if it's strictly necessary.
In case we need bash (or some other shell), we should invoke it through /usr/bin/env.

[martinhoefling]

So the default script shipped / installed by gopass is posix compliant (checked by running through posh). Therefore I would not require running it via bash but instead use #!/bin/sh as shebang. /bin/sh should be available on all posix compliant systems while /usr/bin/env is not mandatory.

[mkaito]

Another thing to consider:

Seeing that the wrapper is literally just a string that is piped straight into a file, how about making it an actual file? I think the correct way to handle this would be to put it on the $PATH, and let the OS handle it from there.

Esoteric distributions like NixOS have tooling to allow fixing executable according to their infrastructure.Virtually everything packaged for NixOS gets their interpreter fixed in some fashion. I can't do that if the script is a string inside the compiled binary.

If this was just another file, I could handle it correctly in the packaging process, fix it up as necessary, and put it on the $PATH.

I'm not familiar with the necessary extensions that need to be installed for browsers to access the native API, but if those can be put in a global runtime folder instead of my browser profile, I'd much rather give them the same treatment: let me handle them as part of the OS package.

[martinhoefling]

So if I understand you correctly, this would require to ship a separate executable, right? So far, the wrapper is intentionally generated per user, as different users might have a different setup requiring a different wrapper script. May people just download the gopass binary and use gopass jsonapi configure once to set up their browser per user. Since you typically also install the plugin as user and not globally for all users it sounds reasonable to set it up per user. Does this differ from the common pattern on NixOS?

[mkaito]

Well, NixOS might be the only distro where the system package manager allows users to install things just for themselves. So yes, making all of that part of the package is perfectly reasonable.

Alternatively, it would be nice if I could generate those files at build time, like is done for shell completion.

[martinhoefling]

So you just wanna generate the wrapper alone? Or wrapper and manifest? The latter case should work by specifying all params. This should non interactively output the files. If you need this separate from each other, one could also provide a split up version like:

gopass jsonapi configure
gopass jsonapi configure-wrapper
gopass jsonapi configure-manifest

[dominikschulz]

We can certainly generate the system scope files at build time if that helps.

[mkaito]

I'm not really familiar with how the manifests work. Can they be put in a system-level folder?

The wrapper can almost certainly just be part of the gopass package, and the manifest can expect it to be on $PATH.

[martinhoefling]

@mkaito both methods are possible. They can be installed system level but it's probably more common to install them per user as with browser plugins.

[mkaito]

The way I see it, a user installs a system package for gopass, then the browser extension, and no further steps are necessary, because the manifest is installed for everyone, and the wrapper is on $PATH. If the user doesn't install the extension, the manifest should be harmless.

[martinhoefling]

Yes, this is possible. However the installation paths (locally and globally) differ from browser to browser.

[mkaito]

That's fine. It's no different from what I'm already doing to install shell completion for gopass. If you can provide me a list of locations, or at least something to start looking into, that'd be great.

[martinhoefling]

Like to MDN and Chrome documentation can be found here: https://github.com/justwatchcom/gopass/blob/master/docs/jsonapi.md

[mkaito]

I've put it on my TODO list. In the meantime, any chance gopass can generate the necessary files on-demand, or just include them in the release if they're static? Same for the wrapper, actually.

[dominikschulz]

Yes, I think we can generate and include them in the release.