browserpass 2.0.8 (new formula)

[zsau]

This is the native messaging component of browserpass, a password management
WebExtension for browsers like Chrome & Firefox. It uses password stores
created by pass (https://www.passwordstore.org/).

[maximbaz]

you can combine all 3 goals in one system call, "make deps js browserpass-darwinx64"

[zsau]

Doesn't compile when I combine them. Go complains about not being able to find some packages (twofactor and go-zglob).

[maximbaz]

Good point, actually I forgot to tell you, you should download archive from a different link (click), that one already contains all the dependencies so that you don't need to do make deps and make js at all. Then you only need to do make browserpass-darwinx64. That will also allow you to remove dependencies on "dep", "yarn" and "node".

I made this custom tarball specifically for other package managers, to reduce dependencies and to simplify build instructions.

[maximbaz]

install.sh places the chrome-policy.json, which in turn forces Chrome to automatically download the browser extension. However I noticed that on linux this works only if you run install.sh as root.

No action needed, just wanted to let you know this, maybe check how install.sh behaves on Mac, if it automatically installs Chrome extension you can reduce the manual steps.

[zsau]

Doesn't seem to happen in Chrome. Are there any docs about this behavior?

[maximbaz]

The feature is called ExtensionInstallForcelist, I think it is usually used by companies to enforce installation of a certain extension. When I have the chrome-policy.json stored in the following location on Linux, Chrome automatically installs the extension:

/etc/opt/chrome/policies/managed/com.dannyvankooten.browserpass.json

[maximbaz]

If this is supported in homebrew, I would also highly recommend to check PGP signature of the source tarball that you are downloading in the formula. I'm providing .sig files for every released file, and I know the AUR package for ArchLinux does this today.

While sha256 provides you an integrity check (the file is not corrupted), pgp provides you authenticity check (the file comes from the author of the app).

Since browserpass is dealing with very sensitive data by its nature, it is a good idea to give users of your formula a safe-check that they are not being victims of a MitM attack.

[ilovezfs]

Browser extensions are a bit outside of Homebrew's scope. This may be a better fit for Homebrew Cask. Thanks for the pull request, nonetheless, @zsau!

[zsau]

This formula is not actually a browser extension. It is a binary that implements the Native Messaging protocol used by browser extensions to communicate with native software (GPG in this case). Both the extension and this native component must be installed for the extension to work, but for obvious security reasons there is no mechanism for browser extensions to install native binaries. It makes perfect sense IMO for a package manager like Homebrew to manage this native component.

[ilovezfs]

I'd recommend a signed binary and a cask.

[zsau]

AFAIK casks can't do things like installing a browser extension either, so why would a cask be more appropriate?

[ilovezfs]

They can. See raindropio for example.

[zsau]

Isn't that raindrop cask just installing a native app that installs a browser extension when run? That's at least at awkward as this approach, and doesn't give users any reassurance about what the software is actually doing (important for software like this that deals with sensitive data). We'd have to update the native binary automagically, for example, which security-minded users will definitely not like.

Whereas with this formula, all we're doing is installing a small, open-source native binary (and a simple helper script, which I could remove if desired). Much easier for technically-minded users to audit, and upgrades are under the user's control. And although the native binary isn't much use without a browser extension, it's possible other extensions would want to interface with this same native messaging host, making the cask approach even more awkward.

[ilovezfs]

As I said, this is outside the scope of homebrew/core so you'll need to distribute it via Cask or outside the Homebrew organization.

[zsau]

Could you point me to documentation about what is within Homebrew's scope?

[ilovezfs]

https://docs.brew.sh/Acceptable-Formulae.html

[zsau]

Thanks. If the issue is "Stuff that requires heavy manual pre/post-install intervention", would it be more acceptable if the installed binary automatically completed its own installation (by copying files from /usr/local/share/browserpass, i.e. not by downloading anything)?

[ilovezfs]

For a formula, that would result in a sandbox violation. But a cask could do that.

We'd have to update the native binary automagically

Note that is not the case. See Homebrew/brew#3396

[zsau]

I'm aware of the sandbox in which formulae are executed, but are you saying binaries installed by Homebrew are also sandboxed when run? I didn't think that was possible.

[ilovezfs]

Right, the software is on its own after installation. However, things where brew install and brew upgrade don't actually themselves install or upgrade the functional bits until the user takes subsequent action don't really make sense for formulae.

Your best bet is going to be a signed binary and a cask that can actually install it.

[zsau]

Understood. I wish that had been made clear to me here, though.

[ilovezfs]

@zsau that approach will "work" but your users are going to have a better and safer experience if they can brew cask install browserpass and end up with a signed binary fully installed with the browser extension set up. If you disagree, you can always set up your own tap