Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Updating OS packages for v3 #31

Closed
5 of 6 tasks
maximbaz opened this issue Mar 30, 2019 · 26 comments
Closed
5 of 6 tasks

Updating OS packages for v3 #31

maximbaz opened this issue Mar 30, 2019 · 26 comments

Comments

@maximbaz
Copy link
Member

maximbaz commented Mar 30, 2019 •
edited
Loading

There will be a new major release of Browserpass soon, so I want to ping OS package maintainers to give you time to prepare for the release.

I've created a Makefile, so the build & packaging should be really simple now. For Arch Linux, all I do now is:

make configure
make browserpass
make test
make install

For reference: PKGBUILD

To configure browsers, Makefile is also being installed to /usr/lib/browserpass/, so if you guys implemented some wrappers (like I know @dustinwilson implemented browserpass-setup), that shouldn't be necessary anymore - users can just do:

cd /usr/lib/browserpass
make hosts-chromium-user

For full reference, see Configure browsers

For Nix / NixOS, a special request if someone could review this section of the documentation, I ported it from the old Browserpass repo but I'm not entirely sure it's correct: https://github.com/browserpass/browserpass-native#install-on-nix--nixos

ping @meskes, @dustinwilson, @infinisil, @fpletz, @dermetfan, @pajowu

Completed distro packages:

  • Arch Linux
  • NixOS
  • macOS (homebrew tap)
  • Gentoo Linux
  • Ubuntu
  • Debian
@infinisil
Copy link
Contributor

The Makefile currently assumes that browserpass is installed in /usr/lib. Can you make this configurable with a variable? The user won't be able to change the Makefile easily on Nix/NixOS, so we'd have to patch it.

@maximbaz
Copy link
Member Author

Yes we can do anything you need 👍 The install target is respecting DESTDIR variable, I needed that for Arch Linux package, are you referring that all those hosts-* and policies-* targets must also respect this variable, or what do you have in mind?

@infinisil
Copy link
Contributor

@maximbaz Something like that yes, specifically in these places it assumes browserpass was installed /usr/lib:

browserpass-native/Makefile

Line 100 in 8411954

ln -sf "/usr/lib/browserpass/hosts/chromium/$(APP_ID).json" "${HOME}/.config/chromium/NativeMessagingHosts/" \

In addition, I think it's common to allow configuration through both DESTDIR and PREFIX, DESTDIR being empty by default, and PREFIX being something like /usr or /usr/local. In Nix specifically, we'll set PREFIX to be empty.

@maximbaz maximbaz mentioned this issue Mar 30, 2019
Merged
@maximbaz
Copy link
Member Author

@infinisil may I ask you for a review in #32?

@maximbaz maximbaz mentioned this issue Mar 30, 2019
Closed
@maximbaz
Copy link
Member Author

I will release v3 to webstores on Saturday, April 13th; would be really awesome if you guys get ready for this date as browser extension is not backwards compatible and will not work after auto-update with the old native host.

@infinisil
Copy link
Contributor

Is the new native host compatible with the old browser extension?

@maximbaz
Copy link
Member Author

No, the communication protocol has changed completely, and it was too much work to make them compatible, therefore the bump in major version.

@infinisil
Copy link
Contributor

Huh, but that makes it nearly impossible to not break anything at some point. The only way it won't break is if the user gets the native host update exactly at the same time as when the browser extension auto-updates. And because the native host isn't in any way tied to the browser extension, but provided by the package managers/installed manually, this inevitably leads to a version mismatch.

The only way I can see this working is if you rename the binary to browserpass3, then the old browser extension can use browserpass as its binary, and the new one can use browserpass3. As a package maintainer I can then provide both versions in the same package for a while. Some time before the browser extension release, so the native host update can go through all the build pipelines for package managers and gotten via a system upgrade, and some time after the release, so people who didn't get the browser extension update yet (if you don't restart your browser for days at a time like me) can still use the old native host.

@maximbaz
Copy link
Member Author

The binary name is configurable with BIN variable in Makefile, so you as a package maintainer are free to name the binary how ever you want. I don't plan for a non-breaking update, it was a conscious decision given the amount of time I have, I only want to decrease the time things are in a broken state - therefore an early ping for you guys 🙂

By the way, I believe it isn't required to restart browser to receive auto-update, at least not in Chromium.

I'm also planning to push a new version of v2 to web stores a week before v3 release, which will show a notification about the upcoming breaking update, and that folks need to plan for a time to update native host app to make the extension work properly again.

@infinisil
Copy link
Contributor

Ohh right, the browser extension uses com.github.browserpass.native.json to determine which binary to use, which can coexist with com.dannyvankooten.browserpass.json, yeah that works then, I can make it install both of those.

@infinisil infinisil mentioned this issue Mar 31, 2019
Merged
8 tasks
infinisil added a commit to infinisil/nixpkgs that referenced this issue Mar 31, 2019
@infinisil
browserpass: 2.0.22 -> 3.0.1
6104fba 
See browserpass/browserpass-native#31

This is fully backwards compatible.
infinisil added a commit to infinisil/nixpkgs that referenced this issue Mar 31, 2019
@infinisil
nixos/browserpass: update for v3
e98ee8d 
See browserpass/browserpass-native#31

Additionally browserpass was removed from systemPackages, because it
doesn't need to be installed, browsers will get the path to the binary
from the native messaging host JSON.
infinisil added a commit to NixOS/nixpkgs that referenced this issue Apr 1, 2019
@infinisil
browserpass: 2.0.22 -> 3.0.1
fcb8738 
See browserpass/browserpass-native#31

This is fully backwards compatible.

(cherry picked from commit 6104fba)
infinisil added a commit to NixOS/nixpkgs that referenced this issue Apr 1, 2019
@infinisil
nixos/browserpass: update for v3
7e889fe 
See browserpass/browserpass-native#31

Additionally browserpass was removed from systemPackages, because it
doesn't need to be installed, browsers will get the path to the binary
from the native messaging host JSON.

(cherry picked from commit e98ee8d)
infinisil added a commit to NixOS/nixpkgs that referenced this issue Apr 1, 2019
@infinisil
browserpass: 2.0.22 -> 3.0.1
d22d43a 
See browserpass/browserpass-native#31

This is fully backwards compatible.

(cherry picked from commit 6104fba)
infinisil added a commit to NixOS/nixpkgs that referenced this issue Apr 1, 2019
@infinisil
nixos/browserpass: update for v3
b791044 
See browserpass/browserpass-native#31

Additionally browserpass was removed from systemPackages, because it
doesn't need to be installed, browsers will get the path to the binary
from the native messaging host JSON.

(cherry picked from commit e98ee8d)
@meskes
Copy link

meskes commented Apr 2, 2019 via email

@maximbaz
Copy link
Member Author

maximbaz commented Apr 2, 2019

I'm not sure yet, whether I really want to have two packages or combine both to one. Is there a particular reason why you did that Maxim?

Sorry I think I lost context, what are you asking about exactly? 🙂 Why is v3 incompatible with v2? It was rewritten from scratch, and it was a great opportunity to redesign the communication protocol and the native host in general. Or why we now have split repos for native app and browser extension? This is because in practice these are different projects, with different codebase, when it was a single project it didn't make sense for users for example to update their native host if only browser extension changed. I think distro packages should only provide native host app, and leave installing extension to the user. Or do you have some particular reasons to provide browser extension as well via a OS package, and if so, how do users install it in the browser?

Assuming that you don't need to handle browser extension part in the distro package at all, you don't need to worry about browserify anymore 🙂

For the issues where Browserpass is not able to fill login form, please post the link here and I'll investigate: browserpass/browserpass-extension#62

@meskes
Copy link

meskes commented Apr 2, 2019 via email

@maximbaz
Copy link
Member Author

maximbaz commented Apr 2, 2019

Users don't have to install it. As soon as the package is installed the extension is enabled in each browser automatically.

I'm really curious how you achieved that! For Chromium-based browsers there's something called "policy", which can force browser to install an extension from Web store (not from local file as far as I know), but I'm not aware of any such possibility for Firefox...

@maximbaz
Copy link
Member Author

maximbaz commented Apr 3, 2019

I tracked this down to https://wiki.debian.org/onlyjob/WebExtensions%20packaging, astonishing! I will do the same for Arch Linux 🙂

Nevertheless, I think it's still reasonable to split the packages, let "browserpass" provide only native host and create two new packages "browserpass-chromium" and "browserpass-firefox", which would be based on "chromium.zip" and "firefox.zip" from browserpass-extension releases respectfully. Not only we will have cleaner separation, but also users aren't forced to e.g. install Chromium extension if they only use Firefox.

@infinisil make sure to check this out as well, not only it is cool because you will provide users with an extension that is built from sources that are verified with PGP signature instead of trusting whatever is on webstore, but also you will be in complete control of when their extension upgrades.

@meskes
Copy link

meskes commented Apr 3, 2019 via email

@maximbaz
Copy link
Member Author

maximbaz commented Apr 3, 2019

Based on the docs I found I understood you will still create for example symlinks in /usr/share/chromium/extensions/ folder even if a user doesn't really use Chromium; but of course it's up to you how you want to package, you can create a combined browserpass-webextension, or even create a single browserpass package as you have now, which would be based on several source archives 😉

I must also say you are lucky, I couldn't convince Chromium's maintainer on Arch to support loading unpacked extensions from /usr/share/chromium/extensions/* folders; I had to use browserpass/browserpass-extension#68, which means on Arch Linux packages browserpass-chromium and browserpass-firefox would be completely different, one based on unpacked zip archive, another based on packed crx file.

@maximbaz
Copy link
Member Author

maximbaz commented Apr 3, 2019

By the way, when packaging remember that the extensions are not exactly identical: manifests are slightly different for Chromium and Firefox.

@maximbaz
Copy link
Member Author

maximbaz commented Apr 3, 2019 •
edited
Loading

My preliminary packages for Arch Linux, in case anyone needs for reference: browserpass, browserpass-chromium and browserpass-firefox

@maximbaz maximbaz mentioned this issue Apr 9, 2019
Closed
@stefanct
Copy link

As of now the firefox extension has been auto-updated in Debian (stable) and leaves the user with Error: Error: Attempt to postMessage on disconnected port when clicking on the new browserpass icon. Does building from source work or would that run in the same problems you saw, @meskes?

@maximbaz
Copy link
Member Author

maximbaz commented Apr 15, 2019 •
edited
Loading

Building from sources (or using pre-built archives from Github releases) should work @stefanct, especially if you already have the extension and only need the native host part, give it a try and ping me if you need help 👍 (maybe create a new thread)

@meskes
Copy link

meskes commented Apr 15, 2019

@stefanct with auto-update you mean from the extension store right? There is no Debian package for browserpass in Debian stable. Did you use a precompiled native host binary or did you build that yourself? The issues I ran into were solely with the browserified javascript and were solved by the precompiled files. I still have some buildsystem issues, which is why there are no new packages for unstable yet.

@stefanct
Copy link

@meskes Yes, I was referring to the browser-part. I have apparently installed the webext-browserpass package version 2.0.22-1 from testing/unstable (but FF is from stable security). Sorry for the confusion. I have not tried (and would like to avoid) building it myself (too much other stuff on the plate ;) unless you struggle with something specifically where I could help (I am not a debian dev though).

@meskes
Copy link

meskes commented Apr 17, 2019 via email

@stefanct
Copy link

stefanct commented Apr 17, 2019 via email

@maximbaz
Copy link
Member Author

maximbaz commented May 8, 2019

Every distro has updated the package, except Ubuntu, but that should propagate automatically from Debian. Thanks everyone, closing this now!

@maximbaz maximbaz closed this as completed May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@stefanct @maximbaz @meskes @infinisil