Germano Massullo wrote: > Package webextension-token-signing[2] is affected by the same problem, > but it uses QMake rather than CMake, so I am investing on how to > implement the same instruction. I also think that a brand new *make file > could be the better solution, but I did not yet have the time to fully > study QMake [3]. 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). 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. 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. So to sum this up: This package needs work. A LOT of work. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
