Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up[Contribution] qubes-url-redirector #3152
Comments
andrewdavidwong
added
C: other
enhancement
labels
Oct 7, 2017
andrewdavidwong
added this to the Release 4.1 milestone
Oct 7, 2017
added a commit
that referenced
this issue
Oct 7, 2017
added a commit
that referenced
this issue
Oct 19, 2017
added a commit
that referenced
this issue
Feb 3, 2018
added a commit
that referenced
this issue
Feb 23, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 26, 2018
Member
First, sorry for extremely late reply @raffaeleflorio.
I'm looking how to package this. On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.
But I can't see much for Chrome/Chromium besides one setting user-agent. Anyway, it looks like for packaging Chrome extension I need to set its ID, which is based on public key used to sign it. Am I correct that extension signing applies only to chrome web store, but not local installation? If so, I could probably use any ID... But if you ever plan to upload this extension to web store (too?), better use the same ID for seamless updates. Is that key generated by the developer, or inside chrome web store? In other words: is it possible to get the public key / ID before uploading the extension to web store?
|
First, sorry for extremely late reply @raffaeleflorio. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
raffaeleflorio
May 30, 2018
First, sorry for extremely late reply @raffaeleflorio.
Don't worry @marmarek, you're very busy and thanks for all of your work!
On Fedora there are few Firefox extensions available directly from Fedora repositories (https everywhere, noscript, ublock origin etc), so can be used as an example.
The difference with Chrome is that the Firefox extension has to be signed by Mozilla in order to be installed by the browser. However the upload to the web store is optional.
But if you ever plan to upload this extension to web store
Unfortunately this isn't possible because the extension, in order to work, needs a simple host application that run "qvm-open-in-vm". Obviously the web store doesn't handle such type of installation.
Furthermore it will be available for every other Linux distro (at least).
In other words: is it possible to get the public key / ID before uploading the extension to web store?
Yeah, indeed the key/ID is generated offline during the packaging process. The upload to the web store is optional, like for Firefox.
The new version (tracked by the v2.1.1 branch) is more stable, with more feature and simpler. It's almost finished. For various reason I couldn't work on it in the past period.
There is only an issue with Firefox, due its APIs: the extension can only handle HTTP(S) URLs. Chrome APIs, instead, permit to handle every scheme (like data, ftp and so on). What do you think it's more appropriate to do? A big warning on the Firefox version?
There are some hacky way to bypass the Firefox limitation. But they aren't, by their nature, reliable or they're too invasive.
raffaeleflorio
commented
May 30, 2018
Don't worry @marmarek, you're very busy and thanks for all of your work!
The difference with Chrome is that the Firefox extension has to be signed by Mozilla in order to be installed by the browser. However the upload to the web store is optional.
Unfortunately this isn't possible because the extension, in order to work, needs a simple host application that run "qvm-open-in-vm". Obviously the web store doesn't handle such type of installation.
Yeah, indeed the key/ID is generated offline during the packaging process. The upload to the web store is optional, like for Firefox. The new version (tracked by the v2.1.1 branch) is more stable, with more feature and simpler. It's almost finished. For various reason I couldn't work on it in the past period. There is only an issue with Firefox, due its APIs: the extension can only handle HTTP(S) URLs. Chrome APIs, instead, permit to handle every scheme (like data, ftp and so on). What do you think it's more appropriate to do? A big warning on the Firefox version? |
raffaeleflorio commentedOct 7, 2017
qubes-url-redirector
Repo: https://github.com/raffaeleflorio/qubes-url-redirector
Discussion: https://groups.google.com/forum/#!topic/qubes-devel/fsIAQO1xFkU
Hi all,
I wrote a browser extension written using WebExtension standard API. So it's compatible with any browser that supports this API.
Essentially I implemented requested feature in https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions . Then I added some other features. Currently Thunderbird's counterpart is missing.
So qubes-url-redirector permits to manage which VM is responsible to open links, obviously redirection happens before any TCP connection is made. Furthermore, through context menu entries, you can open a specific link in a custom way. Currently you can open links in: DVM, a default-VM, a specific VM and in this VM. However I know the direction things about qvm-open-in-vm.
Then the extension has a settings page embedded in browser where you manage default behavior and it supports a whitelist based on Javascript's RegExp, in this way there is a lot of flexibility to define trustworthy URLs or domains. Settings page is also accessible through a button in browser's toolbar, besides the default way (e.g. Firefox's Add-Ons manager).
For UI I followed these guidelines (in the repo there are some screenshots):