Support Chromium snap package

[SnijderC]

General information

• Operating system + version: Ubuntu 19.10
• Browser + version: chromium-browser 77.0.3865.120-0ubuntu1~snap1
• Information about the host app:
  • How did you install it?
    Downloaded and installed the most recent release (3.0.6)
  • If installed an official release, put a version ($ browserpass --version):
    Browserpass host app version: 3.0.6
  • If built from sources, put a commit id ($ git describe --always):
• Information about the browser extension:
  • How did you install it? Installed from the Chrome store.
  • Browserpass extension version as reported by your browser: 3.4.1

---

If you are getting an error immediately after opening popup, have you followed the Configure browsers documentation section?

Yes, and it worked in previous Chromium versions.

---

Exact steps to reproduce the problem

1. I used the extension with browserpass-native just fine on the most recent Chromium installed through the debian universe repository.

2. I updated to Ubuntu 19.10, Canonical is pushing snap packages increasingly hard. They have good reason not to want to support all the Chromium versions for all the supported Ubuntu versions, Chromium just has a lot of updates. So in 19.10, the chromium-browser debian package is a wrapper that downloads the snap package instead. Canonical is phasing out the regular debian package for all recent versions of Ubuntu soon. So bottom line the real debian package is removed and a snap is installed.

Links for reference:

• https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179
• https://www.mariomedina.net/2019/10/10/chromium-in-ubuntu-deb-to-snap-transition/

1. Now when I use browserpass I get

   Error: Error: Specified native messaging host not found.

2. I reinstalled all the components: extension, browserpass-native and configured the extension again (linked the JSON files etc.).

3. The same error occurs.

4. I tried linking the file in the snap's .config dir, because it seems obvious that the user .config doesn't work for a snap.. Even tried the global setting, none of that worked. I suspect the extension is limited too much by the sandbox of the snap. If I had time, I would investigate more and perhaps make a PR, but I don't. But I thought reporting the issue is the least I can do.

5. I checked if I could find a trustworthy repository for debian packages but didn't find any, I can only manually install deb packages, don't really want to be responsible for never forgetting to update it though.

What should happen?

Please make the extension work with browserpass-native, or the other way around, from within a snap. It's only a matter of time before more people will upgrade and be stuck with a snap. I would really like this to be working again, I use it a lot, it saves me tons of time copying pasting from the terminal.

What happened instead?

Well, nothing yet.. ;)

[maximbaz]

Thanks for the report!

I've tried to google around, and found this (see post 5): https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074

It seems you were on the right track trying to use snap's .config dir, but also the browserpass binary needs to be somewhere within snap's binary file.

For a start you can try to put the binary in the same place as the json file (and update full path to it), but would be nice to figure out what is the proper location for the binary that would satisfy snap.

I wonder if browserpass has to be distributed as a snap package? If there is anyone interested to maintain it, speak up, I'll help you compose the pkg!

[maximbaz]

cc @meskes, have you had some experience with snap packages already, or you focus on Debian and not so much on Ubuntu?

[meskes]

Personally I have not much experience with snap packages, sorry. My system is Debian and I mostly only use that.

[tagru]

For a start you can try to put the binary in the same place as the json file (and update full path to it), but would be nice to figure out what is the proper location for the binary that would satisfy snap.

I copied the binary to the snap config folder ~/snap/chromium/current/.config/chromium/NativeMessagingHosts and then the extension loads correctly. Also the error message is gone.

Another problem now seems to be to get the passwords from the store. My store looks empty for chromium. Setting the custom store location in the extension options does not help. Maybe there are some additional permission issues. Either it cannot access the store location or the binary or both.

[maximbaz]

Nice! Judging by these posts, you should create an interface to give access to your home directory. I think this access should be given to chromium, since it's the one initiating the request to browserpass to read your file system. Untested guess, maybe this will work? snap connect chromium:home :home

And make sure the path to your password store starts with /home/..., just in case.

[tagru]

Untested guess, maybe this will work? snap connect chromium:home :home

Well it did not solve the problem, but it seems to be a guess in the right direction. Store is still empty, but I think the access to the home folder is indeed needed.

Does the extension need access to the /usr/bin/pass as well?

Offtopic: The snap connect chromium:home :home solved the permission problem with downloads in chromium. So the access to the home directory is pretty important. Will probably add to the chromium issue list for ubuntu, so they implement it in the snap package.

[maximbaz]

Does the extension need access to the /usr/bin/pass as well?

No, but it needs access to gpg binary, which by default is being searched in $PATH and then additionally in the following locations, and you can provide custom full path to it via browserpass options. But if you don't see any errors about it, your gpg binary is probably accessible by browserpass.

browserpass-native/request/fetch.go

Lines 130 to 134 in 45d63b9

	gpgBinaryPriorityList := []string{
	"gpg2", "gpg",
	"/bin/gpg2", "/usr/bin/gpg2", "/usr/local/bin/gpg2",
	"/bin/gpg", "/usr/bin/gpg", "/usr/local/bin/gpg",
	}

[tagru]

Yeah, I also think that if there would be an error in finding the gpg binary, I would see some error.

Maybe chromium needs access to the interfaces gpg-keys or gpg-public-keys?

Unfortunately the chromium snap packaged does not support these interfaces (yet?).

snap connect chromium:gpg-keys :gpg-keys
Fehler: snap "chromium" has no plug named "gpg-keys"

snap connect chromium:gpg-public-keys :gpg-public-keys
Fehler: snap "chromium" has no plug named "gpg-public-keys"

[maximbaz]

Maybe chromium needs access to the interfaces gpg-keys or gpg-public-keys?

Not at the time of building the list of passwords, we don't invoke gpg until you select a specific password entry.

Can you please show me a screenshot, how your popup looks like?

I am surprised that you see an empty popup with no errors, we designed the native host to choke on anything and be very verbose about any error it sees.

If you see no error, that means browserpass has access to gpg binary, it has access to the folder that you specified as password store, it can walk it, but it simply finds no .gpg files.

So I wonder if access policy of snap somehow allows the process to see the folder, but prevents it from seeing any files inside of it, without throwing any errors about this... 🤔

Could you please also confirm that you see a successful response with 0 files when debugging the background script of our extension in chromium?

Go to chrome://extensions/, find browserpass, click Inspect views background page, go to Sources tab and find background.dist.js:

[tillkrischer]

I ran into this also.

Fwiw i got my logins to show up by putting the binary and a separate clone of my password repo into ~/snap/chromium/common.
But then it failed at the gpg decryption.

[erayd]

@tillkrischer

But then it failed at the gpg decryption.

That will be because there isn't a usable gpg setup inside the snap container, and it has no way of talking to your usual setup.

[tillkrischer]

@tillkrischer

But then it failed at the gpg decryption.

That will be because there isn't a usable gpg setup inside the snap container, and it has no way of talking to your usual setup.

Yeah makes sense,

I was thinking: would it be possible to do the decryption directly in go instead of relying on an external binary?
Maybe not make it the default but an option.

That would also be nice on windows since gpg4windows is kind of a pain.

[erayd]

@tillkrischer

would it be possible to do the decryption directly in go instead of relying on an external binary?

Technically possible, but would require re-implementing much of gpg, including smartcard support - which rather defeats the point, and duplicates a ton of effort (along with additional risk of bugs in important places). Makes far more sense to simply fix the issues with using gpg from a snap-packaged browser, so that the normal gpg workflow can be followed.

Re-implementing gpg in go is outside the scope of this project, and is not something we are ever likely to do.

[tillkrischer]

I don't really know anything about go or gpg, but wouldn't this do the trick? https://godoc.org/golang.org/x/crypto/openpgp
Also I'm just saying it would be a nice (non-default) option, if you have an obscure setup you can still use the system gpg.

But it's a fair point, that you don't want add all that complexity.
And Ubuntu 20.04 is coming up maybe this behavior is getting changed and this won't be an issue anymore.

[erayd]

I don't really know anything about go or gpg, but wouldn't this do the trick?

It would do part of the job, but only part, and seems to lack all the smartcard operations.

...that you don't want add all that complexity.

Indeed. Better IMO to simply get gpg working, rather than trying to cram all that additional complexity and functionality into the native binary.

One of our biggest considerations when designing the v3 native component was to go with something that was as simple as possible, in order to avoid needing users to upgrade it - because user upgrades of the native component are the most frustrating part of installation. Almost all of the app logic lives in the browser extension; the native bit mostly just lists files and calls gpg to decrypt them.

[SnijderC]

I think the way it was designed to work is that the native messaging host is supposed to do all the "out of browser" work and talk to the browser extension, so we should find a way for the extension to be allowed to "talk" to the native messaging host.

When that is fixed, whatever the host does should be of no concern to chromium/snap, thus access to files in the home dir (~/.password-store) and /usr/bin/gpg should then not be a problem any more.

@maximbaz mentioned this bug report which I think needs to be fixed first.

It seems you were on the right track trying to use snap's .config dir, but also the browserpass binary needs to be somewhere within snap's binary file.

For a start you can try to put the binary in the same place as the json file (and update full path to it), but would be nice to figure out what is the proper location for the binary that would satisfy snap.

Actually I think the binary should be outside, or it will be in the same sandbox as chromium, not allowing it access to the home dir, or to run gpg.

I wonder if browserpass has to be distributed as a snap package? If there is anyone interested to maintain it, speak up, I'll help you compose the pkg!

Snaps can talk to each other but I think that doesn't fix native messaging, instead an interface might work, but I don't understand snaps enough to be sure, but that would just fix this project, not keepassx and other similar affected projects.

[raxod502]

Has anybody found a workaround? Apart from finding a sketchy PPA that allows installing Chromium as a .deb?

[Kharonus]

Currently looking for a solution, too. So, can anyone figure a fix to support native messaging for the chromium snap package? Or do we need to build chromium from source or, like raxod502 said, find someone else who did it for us?

[raxod502]

Chromium stopped working across the board for me, possibly related to that drama where Google revoked Chromium's API keys a few months back. I switched to standard Chrome and it works fine for me. Google has an official .deb download, and Pop!_OS at least offers google-chrome-stable in its official repositories.

[xxuejie]

Just run into similar issue, not sure what's the latest progress here, but just want to share a workaround I use inspired by trezord, which also suffers snap issues but from a different reason(udev rules instead of gpg).

It seems that even though chromium extensions inside snap cannot run gpg outside of the sandbox, it can indeed issue TCP connections to localhost (and possibly to other addresses as well). So I've quickly hacked together a golang relayer that does the following job:

• A client binary that runs inside of chromium's snap based sandbox, and relay all native messages received from chromium to a TCP connection(for safety reason, you would want this TCP connection to live on 127.0.0.1 or localhost)
• A server binary that runs outside of snap sandbox, it accepts TCP connection from the client binary, then relays the native messages from chromium to browserpass-native binary

The prototype code lives in this repository, you can build it using the following steps with golang, git installed on your machine:

$ git clone https://github.com/xxuejie/chrome-in-snap-messaging-relayer
$ cd chrome-in-snap-messaging-relayer
$ go build ./cmd/server
$ go build ./cmd/client

Now you need to copy client binary to a place where snap chromium can access(the above comments has information on this, on my machine, I simply put it at ~/snap/chromium/current/.config/chromium/NativeMessagingHosts/

Modify com.github.browserpass.native.json so the path field references the client binary. Even though it is expected to use ~/snap/chromium/current/.config/chromium/NativeMessagingHosts/com.github.browserpass.native.json, for some weird reason, I have to modify /etc/chromium/native-messaging-hosts/com.github.browserpass.native.json for chromium to pick up the changes.

Now in a terminal window, launch the server binary:

$ ./server -program /usr/lib/browserpass/browserpass-native

For persistent solution, one can introduce a systemd script to run the server part as a daemon. I personally use such a systemd script:

[Unit]
Description=Browserpass Relay Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/browserpass-relay-server -program /usr/lib/browserpass/browserpass-native
User=ubuntu
MemoryLimit=10M

[Install]
WantedBy=multi-user.target

Note that I put the server binary at /usr/local/bin/browserpass-relay-server, the memory limit for this binary is also capped at 10M since it is merely a prototype now(which might contain memory leaks), you might also want to tweak the User part here.

Browserpass extension now works in chromium in a snap sandbox. I've tested this on Ubuntu 22.04, some particular steps might vary in different environments.

Notice I've just spent an hour or two on this particular prototype, chances are it is not as robust as expected. Some might also consider this as insecure since a TCP connection must be established. So if you really want to use, do be as cautious as you can. But it does provide a viable way for browserpass to work in chromium under snap sandbox. We can discuss if it makes sense to proceed in this path here. I do suggest looking into the possibility, if browserpass-native can accept TCP connections as well in addition to current stdio interface. But that might be something which requires careful consideration.