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.. ;)

[max-baz]

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!

[max-baz]

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.

[max-baz]

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.

[max-baz]

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"

[max-baz]

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.