Symlink points to a non-existent location
krossgear opened this issue · comments
General information
- Operating system + version: Debian 11 (QubesOS AppVM)
- Browser + version: Brave Browser (104.1.42.86)
- Information about the host app:
- How did you install it? Installed via a package manager
- If installed an official release, put a version (
$ browserpass --version): 3.7.2-1+b4
- Information about the browser extension:
- How did you install it? webstore
- Browserpass extension version as reported by your browser: 3.7.2
If you are getting an error immediately after opening popup, have you followed the Configure browsers documentation section? N/A
Exact steps to reproduce the problem
-
install webext-browserpass package from the Debian stable repository via
sudo apt install -
install extension on Brave Browser from the chrome store
-
cd /usr/lib/browserpass -
sudo make hosts-brave-userORsudo make hosts-brave
What should happen?
/home/user/.config/BraveSoftware/Brave-Browser/NativeMessagingHosts/com.github.browserpass.native.json should successfully link to /usr/lib/browserpass/hosts/chromium/com.github.browserpass.native.json
What happened instead?
Error: the symlink points to a non-existent location
/usr/lib/browser/hosts...does not exist
decided not to use extension
To be honest hard to say, almost all browsers were contributed by community, we haven't tested them, so either package installs something in a wrong place, or browser changed location, or it was contributed incorrectly...
If they aren't tested, then I wonder if it might be worthwhile for us to add a "does this file / directory exist" sanity check to our host recipes. That wouldn't actually fix anything, but we could at least inform the user that our recipe doesn't match their system, and hopefully prompt a bug report so that we can address it.
Ah sorry I may have read the issue incorrectly - we do expect the json files to be present at a certain location, so if they are truly missing, most probably it's the package issue (or maybe in reality, a matter of using the same PREFIX when calling make hosts-* as was used by the package). In any case, the default Makefile installs them to /usr/lib/browserpass/hosts, not /usr/lib/browser/hosts - but that might have been a typo on OP's side. PREFIX can adjust that location.
What's contributed by community is location of symlinks for a given browser on a given OS. We can't realistically test or warn users whether these locations are correct, and even if they aren't, it would take another friendly community person to actually find out what's the correct location for that particular OS+browser 🙂
I have the same issue. When I install the host app using sudo apt install webext-browserpass, ls /usr/lib/browserpass only return browserpass-native Makefile. No hosts folder
I have the same issue. When I install the host app using
sudo apt install webext-browserpass,ls /usr/lib/browserpassonly returnbrowserpass-native Makefile. Nohostsfolder
Same for me as well.
Hello, we are not in control of Debian's package, so we cannot unfortunately help investigating and fixing this issue. Would some of you report this on Debian's bugtracker?
An alternative to unblock you guys might be to uninstall webext-browserpass and install the app manually by following our installation instructions.
I'll add to README that Debian's pkg cannot be used for anything except Chromium and Firefox, but other than that I'm afraid this issue is not really actionable for us...
FWIW, this fixes the issue for the google-provided google-chrome-stable in Debian Bookworm (12):
ln -s /etc/chromium/native-messaging-hosts/com.github.browserpass.native.json /etc/opt/chrome/native-messaging-hosts/com.github.browserpass.native.json
Google has explained where chrome looks for the manifest json file, so you can symlink depending on system wide or user specific installation: https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging
And those paths are already reflected in the Makefile, so simply finding your browser in Configuring browsers section and executing the corresponding make target should be sufficient 😉 (and if you find a discrepancy, please file a PR!)