Il 11/03/2018 01:56, Kevin Kofler ha scritto: > The upstream makefile hardcodes /usr/lib here: > https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/chrome-token-signing.pro#L22 > The easiest fix is probably to just change: > ffconf.path = /usr/lib/mozilla/native-messaging-hosts > to: > ffconf.path = $$LIBDIR/mozilla/native-messaging-hosts > with a patch and pass LIBDIR=%{_libdir} on the command line (in the > specfile, along with all the other command line arguments you are passing). Thank you, I will proceed in such way ** UPDATE ** I let upstream read your message and I think the following pull request has been made based on your suggestions https://github.com/open-eid/chrome-token-signing/pull/100 > But I see a bigger issue here: THIS PACKAGE BUNDLES A PREBUILT BINARY XPI > with the Firefox extension > (https://github.com/open-eid/chrome-token-signing/blob/master/%7B443830f0-1fff-4f9a-aa1e-444bafbc7319%7D.xpi). > This is NOT allowed in Fedora and should never have passed review. The > package should instead rebuild the XPI from source. It will not be signed, > but the Fedora Firefox accepts unsigned extensions if they are installed in > system-wide directories. Ok I will compile the extension from sources. > By the way, Fedora ships the chromium browser which should be able to load > the Chrome extension. You may have to change /etc/opt/chrome to > /etc/chromium in hostconf.path, not sure whether Chromium checks both. And > then there is that /opt/google/chrome/ckjefchnfjhjfedoccjbhjpbncimppeg.json > that is apparently setting up auto-downloading the prebuilt extension from > upstream (or really, from Google's store). (Just like the Firefox one, it is > NOT built with the source code.) This file is NOT shippable as is, also > because: > 1. Fedora packages MUST NOT install to /opt. I am not sure what the correct > directory actually is for Chromium, and > 2. that file sets up auto-updating the extension from upstream. But we do > NOT want to have packaged extensions updated directly from upstream. > But > 1. https://github.com/open-eid/chrome-token-signing/blob/master/host-linux/ee.ria.esteid.json > references that ckjefchnfjhjfedoccjbhjpbncimppeg extension as the only > allowed origin, so that would need updating too if the ID changes. > 2. I have no idea in what paths Chromium looks for systemwide extensions. If > it's only /opt, we are stuck and need Chromium patched first. > 3. Last I checked, Chromium did not require signed extensions (only Chrome > did, and only on some platforms), but this may have changed, in which > case Chromium would have to be patched, too. Once I the work on the extension will be finished, if I will have some free time I will try patching the package to work on Chromium too > PS: I see one similar package in Fedora: > https://src.fedoraproject.org/cgit/rpms/chrome-gnome-shell.git/tree/chrome-gnome-shell.spec > but they chickened out of shipping the browser extensions entirely and ship > only the native-messaging-host part. So you have to install the package AND > install the extension from the browser's extension installation mechanism. > > This would be a solution if you cannot package the extensions in a way > compliant with Fedora policies, but it is not very user-friendly. I don't know if such approach would work on Firefox. For example, the most important part of chrome-token-signing package is the JSON file and I have been told that purpose of the extension is only to let Firefox use the related JSON file. In a few words, you can't have such kind JSON file without a related extension. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
