"Error: Native host has exited" on macOS with Chrome

[raxod502]

General information

• Operating system + version: macOS 10.11.6 El Capitan
• Browser + version: Google Chrome 63.0.3239.84 (Official Build) (64-bit)
• If installed an official release, put a release version: 2.0.8
• Browserpass extension version as reported by your browser: 2.0.8 (browserpass-ce)

---

Exact steps to reproduce the problem

1. Download and extract browserpass-darwinx64.zip from the v2.0.8 release on GitHub.
2. Run install.sh and select 1) Chrome.
3. Install browserpass-ce from Chrome Web Store, version 2.0.8
4. Click on lock icon and select a password (the list is displayed correctly, and search functionality is working).

What should happen?

I should be prompted for my passphrase via gpg-agent.

What happened instead?

The error message Error: Native host has exited is displayed immediately.

[maximbaz]

Hey, there are two common reasons on why this can happen on Mac, let's try them first:

1. Do you use GPGTools? Does not work on macOS (unless browser is started from terminal) #13 (comment)
2. Does extension work if you open the browser from terminal instead of using an application launcher?

[raxod502]

1. I don't use GPGTools; I use [email protected] version 2.0.30 with gpg-agent version 2.0.30 installed via Homebrew.
2. Unfortunately, when I try to open Chrome from the terminal (it worked the last time I had to test browserpass, but apparently an update broke it):

[63763:46339:1220/134456.851401:ERROR:browser_gpu_channel_host_factory.cc(107)] Failed to launch GPU process.

I do get a new Chrome window (though not a new entry in the App Switcher), and the problem can be reproduced with no differences in that window.

[maximbaz]

OK, do you have pinentry-mac installed? Also, what is the output of $ which gpg and $ which gpg2 ?

[raxod502]

Yes, I have pinentry-mac version 0.9.4 installed via Homebrew.

% which gpg
/usr/local/opt/[email protected]/bin/gpg
% which gpg2
/usr/local/opt/[email protected]/bin/gpg2

My ~/.gnupg/gpg.conf is:

no-greeting
keyserver hkp://keys.gnupg.net
use-agent

My ~/.gnupg/gpg-agent.conf is:

default-cache-ttl 300
max-cache-ttl 3600
pinentry-program /usr/local/bin/pinentry-mac

pinentry-mac works as expected for other GPG operations, from the terminal and from within Emacs using EPG.

[maximbaz]

Try to make a symlink /usr/bin/gpg2 -> /usr/local/opt/[email protected]/bin/gpg2 and see if it suddenly starts to work. There is an issue on Mac that it doesn't propagate $PATH to desktop applications, so browserpass host app (when started by Chrome) cannot find your gpg2 binary.

I hardcoded a few common paths which are checked even if $PATH is not set, /usr/bin/gpg2 is just one of them.

https://github.com/dannyvankooten/browserpass/blob/1e464970a3a3b00a5679482177db7b3d5fe98a95/browserpass.go#L96-L100

[raxod502]

This is almost certainly the problem. I had entirely forgotten that I had injected some custom code to fix the PATH into the old version of Browserpass, and didn't re-inject when I updated to the release version. Thanks.

Would it be easy, do you think, to add a configuration file for Browserpass in ~/.config which would allow the user to customize the list shown above?

[maximbaz]

I guess, but it feels like a terrible hack and is not simpler than making a symlink...

Maybe as an alternative we could add a note to the README.md, saying that if it doesn't work on macOS and if running $ which gpg2 shows a path that is not in the list, run such and such command to create a symlink /usr/bin/gpg2 -> /current/location/of/gpg2?

[raxod502]

Just so you know, editing the contents of /usr/bin in any way is forbidden by System Integrity Protection on macOS.

In my case, it would be possible for me to create a symlink into /usr/local/bin. However, in the future I might want to also install GPG 2.1, and Homebrew would put that in /usr/local/bin, creating a conflict. If I then wanted to continue using GPG 2.0 with Browserpass, it would be impossible.

The whole idea of the PATH is that it's customizable. "Put all binaries into the same directory", to me, seems like a much worse hack than allowing a way to customize the PATH for a specific application. Ideally, we'd say that you should set up your PATH in the environment before launching the browser, but unfortunately macOS does not provide any way to do this.

It's an unfortunate situation all around, but without the operating system providing a good system for handling the issue, I think it has to be handled at the application level.

[maximbaz]

But if you have any version of GPG in /usr/local/bin, browserpass will work, we aren't really dependent on a specific version - or you have some particular use case where it has to be GPG 2.0 and not GPG 2.1, even though 2.1 is installed?

The PATH issue can also be handled at the launcher level, for example I use Cerebro and I had someone confirm that on macOS it fixes PATH, i.e. if you launch a browser from it, it will get PATH propagated.

[zsau]

Why not a configuration option to specify the actual path to the GPG binary? That seems more consistent with how other things handle external binary dependencies. It could be set in a .config file, but it could also be a setting in the browserpass addon itself as long as there's a way to send that path to the browserpass binary. #20 suggests one way to do that, but it could also be done by just adding a field to the existing Native Messaging JSON commands.

[maximbaz]

Because I don't know yet reasons against having a symlink to gpg binary in /usr/local/bin 🙂 I'd like to hear more about the example above, when someone would want to upgrade GPG to a never version, but keep old version around and make browserpass explicitly the old one.

[raxod502]

What if I do not have administrator access to the system and GPG is only installed in ~/bin?

In any case, thanks for the pointer to Cerebro. I will check it out, since it sounds like the correct solution to PATH difficulties (although given that it's not a solution officially supported by the operating system, unlike on Linux where fixing this is more standard, it may or may not be reasonable to require people to install it for Browserpass).

[maximbaz]

Valid idea about the lack of admin rights, I would however recommend anyone thinking about working on a PR to wait until we know of at least one person who is unable to create a symlink in /usr/local/bin.

Also, I've just realized that yet another workaround is to change the manifest file, and put here not path to the browserpass binary, but to a wrapper script browserpass.sh shown below:

https://github.com/dannyvankooten/browserpass/blob/master/chrome/host.json#L4

browserpass.sh:

#!/bin/env bash

PATH=/path/to/folder/with/gpg:$PATH /path/to/browserpass

[raxod502]

Changing the manifest file is what I did last time, and it works. The downside is that it breaks and has to be fixed again when I update Browserpass. In this case I had forgotten about the workaround, since it had been a few months, and filed a spurious bug report ;)

[raxod502]

I have solved this problem to my satisfaction by using my patch-macos-app.zsh script to patch Google Chrome so that it sources ~/.profile (which sets up my $PATH and configures gpg-agent) whenever it starts.

For people who would prefer not to do this, I still think an $XDG_CONFIG_HOME/browserpass/browserpass.toml configuration file for things like the path to GPG would not be out of line.