Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Andrew Clausen]

On 22 February 2018 at 15:52, Jean-Philippe Ouellet  wrote:

> > One possible solution would be to add a new type of Qubes RPC rule:
> present
> > the user with the most recently opened DispVM to use as a default (that
> they
> > can change before clicking OK).  It might look something like this:
> >
> > /etc/qubes-rpc/policy/qubes.OpenURL:
> >
> > $anyvm $dispvm ask,reuse
> >
> > (I think this idea needs a bit more thought!)
>
> As to point 4 and the implementation of VM re-use, nothing additional
> is necessary from the current qubes-rpc plumbing.
>
> Returning a name would be undesirable since the source VM should not
> be able to specify a specific destination VM (indeed, ideally might
> not even know the names of any other VMs on the system). Increasing
> complexity of the policy evaluation logic is also undesirable, since
> this should ideally be kept as simple as possible.
>
> A solution today might include a service like:
> $ cat url-redirector.RemoteOpenSession
> #!/bin/sh
>
> while read -r url; do
> case "$url" in
> http://*|\
> https://*|\
> ftp://*)
> qubes-open "$url"
> ;;
> *)
> echo "Invalid URL" >&2
> ;;
> esac
> done
>
> and be invoked from another VM with:
> $ qrexec-client-vm '' url-redirector.RemoteOpenSession
>
> This allows the source VM to keep a handle to an anonymous destination
> VM to open arbitrary links in the future, without any cooperation or
> changes in dom0 or policy evaluation or anything.
>

This all looks sensible to me.  Thanks for thinking about it!

Cheers,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJAnDqdwMQ9tecqO_y_B2x5KMNEU9bUgvcpg4d8Vm78CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Jean-Philippe Ouellet]

On Sun, Feb 4, 2018 at 5:16 AM, Andrew Clausen
 wrote:
> On 3 February 2018 at 17:09, Raffaele Florio 
>> 4) This option adds a lot of complexity and "DispVM" automatically become
>> a sort of "SessionVM". Furthermore this option increase, greatly, the
>> complexity and there is the need to communicate with Dom0. It only knows
>> about which VM is alive.
>
>
> I agree, but I do think it's worthwhile.  It might need some minor changes
> to Qubes infrastructure.  For instance, qvm-run --dispvm could be amended to
> return the name of the new VM on stderr, which could be re-used down the
> track.
>
>> 4.1) Nonetheless I can add an option (in quick settings) to define a
>> handler VM associated with the current tab. However you can already open in
>> specific VM (also DispVM,) a link, through context menu entries. I don't
>> consider this a vital and very useful feature. I consider the currently
>> granularity, sufficient. However I'll wait for other opinions and Qubes 4.0,
>> because in the old post [0] I was warned about substantial change regarding
>> the privilege that permits a VM to choose which VM should handle an action.
>
>
> I do think it's valuable to make these easy (i.e. few clicks, and few
> choices during the normal course of things).  And I do think VM re-use is
> important, since VMs use so much resources.  Qubes 4.0 adds a new
> confirmation window by default, but the user can control its behaviour with
> Qubes RPC policy rules.
>
> One possible solution would be to add a new type of Qubes RPC rule: present
> the user with the most recently opened DispVM to use as a default (that they
> can change before clicking OK).  It might look something like this:
>
> /etc/qubes-rpc/policy/qubes.OpenURL:
>
> $anyvm $dispvm ask,reuse
>
> (I think this idea needs a bit more thought!)

As to point 4 and the implementation of VM re-use, nothing additional
is necessary from the current qubes-rpc plumbing.

Returning a name would be undesirable since the source VM should not
be able to specify a specific destination VM (indeed, ideally might
not even know the names of any other VMs on the system). Increasing
complexity of the policy evaluation logic is also undesirable, since
this should ideally be kept as simple as possible.

A solution today might include a service like:
$ cat url-redirector.RemoteOpenSession
#!/bin/sh

while read -r url; do
case "$url" in
http://*|\
https://*|\
ftp://*)
qubes-open "$url"
;;
*)
echo "Invalid URL" >&2
;;
esac
done

and be invoked from another VM with:
$ qrexec-client-vm '' url-redirector.RemoteOpenSession

This allows the source VM to keep a handle to an anonymous destination
VM to open arbitrary links in the future, without any cooperation or
changes in dom0 or policy evaluation or anything.

Regards,
Jean-Philippe

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CABQWM_BLL-o%3DReW0a8vb1jDNRS7vj%2BMaeQiLXWz%2BMwJa%2BeUVXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

['Raffaele Florio' via qubes-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Andrew,
I'm implementing these features. I'll release the v2.1.1 soon.

The extension itself could be automatically updated. However I'll not enable 
this feature because:
1. There isn't any way to verify updated extension in Chrome/Chromium. Instead 
Mozilla, in theory, should validate the extension **before** signing. 
Furthermore Firefox supports SHA verification.
2. It could break everything because the extension needs some files in the host 
VM.

Obviously, when there will be a native package, the extension will be updated 
correctly. Nonetheless I could add a popup that warns the user when there is an 
update.

Best Regards,
Raffaele.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlqOregACgkQjTxG+6f1
ce6BABAAiotCLwxZLGmJTNMu7RuwJG86vX03L7vDxJ3QO0mDxPHIxKjLxQRlpJD8
AyZrd7TfDO8QbaIvltfLW6YBUhMpO7xC+NekYy8wtu/XUpQEQrM1TOSN4Oh4qU1/
sMFp/U2vBNzfqI7NqpV684H+HmTIVDqN0OsvKJsjG0CF/VMIn0hQd4Q4+sXY3iJB
hu3y3MWUm+KPia1Umxsi7c9C0kvLOa/lAEgERPyY30GmD7rsPimY6+iZykvvmHwH
BTmtomQ9GvQVu8Q6AB4q75SGAnP6zn/uckCGTJV479HYMpD8/utVJ854fvU6/9Ke
HCJwPhaC1MZtnFYayWG/3/thC3ZbmsOWCOVjhUkxGMx3wZy/ztC3/9wfl12hlsqC
v7snxbgzQMLf5FQkN/4eaAAwRuymefBLyFz+6cboBz8PaUCJWYxxb2TK1VF463xf
2PjRRZqW9edcN+qxUPaSqzVruaniijjTU0XJ8uJ8p0TExXz7kKLUwjOTfFC7HrzS
fJQUddOB+byfCm313Hf3kUn5C7lK9A4owWmfbqL/xi1NURIWX0Mh51vU6m+q03pv
PABSu45Ds2PJBvaKw2f/tHzmbAuZx2osTF5xaCcC//s32KHwbRP0pUcdA8o1LG06
LXSJ6SGyHfP/S753qJy5lLgJuI6kSvCmg88CjTgKBBSsBDeJHvM=
=eB2G
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/eo7G_0p3h11s3nnrlGB0nJiFHJ7EFQY_9Wc_wCGahezQHQobof6m3G9JqHqffhuN4c2ix2MkYlFVSz2otD8TDhTf3mCLQsqOPCxcguNPIGk%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Andrew Clausen]

Hi Raffaele,

On 5 February 2018 at 08:10, Raffaele Florio 
wrote:

> > Yes, a lower number would be better.  I used 20 for dramatic effect,
> because this is enough to crash a computer.
> Maybe 10 is enough. I think to add this value as parameter in the settings.
>

I would default to 3 (not that it matters much).

> My computer crashed before I had a chance to whitelist anything.  I would
> actually rather open them inside a "session VM", but it isn't obvious how
> to do it.
> Now I really understand what happened. I'll add this feature: after the
> installation a HTML page will be displayed. It will contains the
> instructions and eventually the setup page. In this way the user could
> customize and understand what the extension does, *before*  any other
> interactions with the browser.
>

Sounds good.

Cheers,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWKOS4gfOopPW-TgCyavcZDYeiLGpNSd52L6sHy1tVKRVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

['Raffaele Florio' via qubes-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Andrew,
> It introduces an extra point of failure. I could owned by a corrupted "git 
> clone" operation.  I could also get cloned by a corrupted wget operation.  
> It's one extra thing to audit (if I want to be careful).
Yeah, as I wrote the clone method is the default. I've just removed wget. ;)

> Yes, a lower number would be better.  I used 20 for dramatic effect, because 
> this is enough to crash a computer.
Maybe 10 is enough. I think to add this value as parameter in the settings.

> My computer crashed before I had a chance to whitelist anything.  I would 
> actually rather open them inside a "session VM", but it isn't obvious how to 
> do it.
Now I really understand what happened. I'll add this feature: after the 
installation a HTML page will be displayed. It will contains the instructions 
and eventually the setup page. In this way the user could customize and 
understand what the extension does, *before*  any other interactions with the 
browser.

> It is a great use case though, which is very helpful when designing things.
Yeah, it could be useful. However, currently, it always requires Dom0 
interaction. I think that with that Qubes 4.0 dialog the reuse feature could be 
implemented easily. With this way there isn't the need to interact with Dom0, 
excluding the RPC.

Best Regards,
Raffaele.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp4EUsACgkQjTxG+6f1
ce6e+A/8CgYTtjj+WzHWIhToev9WNOGEf3T6obZRhbxv+w0OzbluojaU24bUUx8D
mCaebqF5DqzzdT3SkXkmcTiRjvIqgWbx8y8BLy275eP/CXJbNSGawkVpqEMBSRVA
IibNhU9YDjzXlJN6Hs5DGYIF1Srt+ltOov/Tsvox3qaVqlXKvIUHYY2F+aMeLZ4b
S66Hnox11fWzGZ9BebgpVJVE6VEkGj7Q2xFSzd1Mh7TB0oiieq5PzZ+xd80sMBLw
b9RBsLI1dmLH/yCe5OAZktKYCy8HZkyXirk6Ff74BDtEyaQN906UEq318Og344rs
+05vzfL1bThV0W+LHywOoj25H6/n0AsrDWFWm9gMMBP664hTAuql5R4Iq6EaB8gN
q911dUc5oWimOxt1U1QeEYy8HUU2EvYAdHzoOsBu8chYTu/m84ohw99nkpvL+k3Z
ekDhC+00Kit2+khYyW0TTBzK8mtM8O4YCUhECj7tKS7+XTGWupJ0DZoyo9vNqjEp
Z1jEqhWAOAfeSO+hvC9/Jgs+cgurB3AfwyyBXlVWrKu8Kw/FKGIrBtYUh0gF6hWd
q8RuY+Q5yd67ev2ItGXcEj5jv6dTdDqSEcz34C6Ovw9SxW+pb8v5sbbR5GQpCFlv
D5IytwAA56zR1ESm07UUMEHYg71Svrizuh9rYqYm37T5D5yjIpY=
=t6kT
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/SW0bxiyswcFpXjNDq_nhpjNGDhHykCpo44cyl8NZjkKT-rt0dHQMGJ36q6bJGLeT4MeYwUtSbeDmDPpGN0MFzMHHyvKQ_R6UG-D8ZgmPZ6A%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Andrew Clausen]

Hi Raffaele,

On 4 February 2018 at 17:25, Raffaele Florio 
wrote:

> > The "make firefox" rule uses wget to get a few files.  Is this because
> you don't want to distribute signatures on Github?  Ideally, it would use
> local files only.
> I was referring to the HTTPS statement. I'd like to deepen this statement.
> There are signatures and I also think that the GitHub clone reduce the
> complexity. I agree that the latter will be the default. However HTTPS is
> used both in the clone and in the process to get my public key.
>

It introduces an extra point of failure. I could owned by a corrupted "git
clone" operation.  I could also get cloned by a corrupted wget operation.
It's one extra thing to audit (if I want to be careful).


> >  Well, it crashed my machine... I had to reboot the whole thing.  It
> would be nice if it did something more graceful when presented with 20
> links at the same time, even if it is just asking for confirmation.
> Why 20? Why not 10, 30 or other numbers? However to avoid DOS attacks,
> very plausible, is useful to have a maximum requests per second. When this
> limit is reached the extension blocks other request and warns the user.
> This is a vital feature.. ;)
>

Yes, a lower number would be better.  I used 20 for dramatic effect,
because this is enough to crash a computer.


> > Also, I think your tool could be quite useful for several different use
> cases.  Perhaps it's better to have the default configuration being
> unobtrusive, but allow the user to switch on more defenses if they like.
> I think that the opposite is better.  *The user* sets as default "Open
> here mode" (not secure), and then, trough Quick Settings, it could switch
> to "redirection mode". Quick Settings has to be very flexible.
> More secure default, is better.. I repeat: the extension did its job.
> However why do you not whitelist these (20+) URLs (or related domains), if
> you consider them trustworthy?
>

My computer crashed before I had a chance to whitelist anything.  I would
actually rather open them inside a "session VM", but it isn't obvious how
to do it.

> (I think this idea needs a bit more thought!)
> I agree. It's something not, principally, related to this extension. I'm
> also waiting to try the stable 4.0.
>

It is a great use case though, which is very helpful when designing things.

Kind regards,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJWaJM4SNArR_dLfX%2BgjWi_r3%2BUehJ1KyN75Nc--Qug%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Andrew Clausen]

Hi Raffaele,

On 3 February 2018 at 17:09, Raffaele Florio 
wrote:

> 1) I partially agree. Can you explain better please?
>

The "make firefox" rule uses wget to get a few files.  Is this because you
don't want to distribute signatures on Github?  Ideally, it would use local
files only.

2) I don't consider this case an issue. This extension is designed to block
> and redirect non whitelisted URLs, that is opened through the browser (e.g.
> with the shell, interactively, etc..). Evidently you restored non
> whitelisted URLs. So qubes-url-redirector did its job.
>

Well, it crashed my machine... I had to reboot the whole thing.  It would
be nice if it did something more graceful when presented with 20 links at
the same time, even if it is just asking for confirmation.

Also, I think your tool could be quite useful for several different use
cases.  Perhaps it's better to have the default configuration being
unobtrusive, but allow the user to switch on more defenses if they like.


> 3) In the plan there is a quick settings feature (there is a GitHub issue)
> to handle such type of scenario.
>

Great.


> 4) This option adds a lot of complexity and "DispVM" automatically become
> a sort of "SessionVM". Furthermore this option increase, greatly, the
> complexity and there is the need to communicate with Dom0. It only knows
> about which VM is alive.
>

I agree, but I do think it's worthwhile.  It might need some minor changes
to Qubes infrastructure.  For instance, qvm-run --dispvm could be amended
to return the name of the new VM on stderr, which could be re-used down the
track.


> 4.1) Nonetheless I can add an option (in quick settings) to define a
> handler VM associated with the current tab. However you can already open in
> specific VM (also DispVM,) a link, through context menu entries. I don't
> consider this a vital and very useful feature. I consider the currently
> granularity, sufficient. However I'll wait for other opinions and Qubes
> 4.0, because in the old post [0] I was warned about substantial change
> regarding the privilege that permits a VM to choose which VM should handle
> an action.
>

I do think it's valuable to make these easy (i.e. few clicks, and few
choices during the normal course of things).  And I do think VM re-use is
important, since VMs use so much resources.  Qubes 4.0 adds a new
confirmation window by default, but the user can control its behaviour with
Qubes RPC policy rules.

One possible solution would be to add a new type of Qubes RPC rule: present
the user with the most recently opened DispVM to use as a default (that
they can change before clicking OK).  It might look something like this:

/etc/qubes-rpc/policy/qubes.OpenURL:

$anyvm $dispvm ask,reuse

(I think this idea needs a bit more thought!)

Kind regards,
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWLbQ%2B4ogPUcc-Q-8GBuYUQOUbpy4bHvFBjBU93bat_5dQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

['Raffaele Florio' via qubes-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Andrew,
Thanks for the comments!
1) I partially agree. Can you explain better please?
2) I don't consider this case an issue. This extension is designed to block and 
redirect non whitelisted URLs, that is opened through the browser (e.g. with 
the shell, interactively, etc..). Evidently you restored non whitelisted URLs. 
So qubes-url-redirector did its job.
3) In the plan there is a quick settings feature (there is a GitHub issue) to 
handle such type of scenario.
4) This option adds a lot of complexity and "DispVM" automatically become a 
sort of "SessionVM". Furthermore this option increase, greatly, the complexity 
and there is the need to communicate with Dom0. It only knows about which VM is 
alive.
4.1) Nonetheless I can add an option (in quick settings) to define a handler VM 
associated with the current tab. However you can already open in specific VM 
(also DispVM,) a link, through context menu entries. I don't consider this a 
vital and very useful feature. I consider the currently granularity, 
sufficient. However I'll wait for other opinions and Qubes 4.0, because in the 
old post [0] I was warned about substantial change regarding the privilege that 
permits a VM to choose which VM should handle an action.

[0] = https://groups.google.com/forum/#!topic/qubes-devel/fsIAQO1xFkU

Best Regards,
Raffaele.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp17MsACgkQjTxG+6f1
ce4hxg//SROBl5uwyxhSVZo4A8f6rvphS0DyEkIqbfrsuWXgWxpO+hAWbyDkkqVJ
0lgbRP9rQHO65vz8Egveklsa6cBJtYIYf6UBvNv5A16b66jBz370VIq/1eVJDbuQ
/EmJ/1fuX4TUrA5EKVpv/+YJU9+4J23micGCmP8+AckoApw2emtwHw2FI//2VtMF
kNv7Ur00sig2lR9jC0N/RnShOdv/0Z7SQ7pnxQk40RJ62gs3zHzJ6APT8Cs7/HFH
tiVw0XnQAWiBgvbjyAGcliIEYzhvE+lYJfFRu5bLT8fAlNJb1uHhY+LoTRt5YQLP
0kk/WLiAQz/TUGfiIanzV43XKFLzaeXUVZv/qpOULQ5w6J9k5+HRn2LfRBh/3F5c
kxeYQJXRigO5D8r7PNVmeeS5D3j6EWho+AFE4TyP0F6TGcImZhHQEEoefnWXbPDF
Tiy3zDKeudP24ZDm1UrT43pz8RwQ2fnsCO0tkaZKEbHDCVpJhEfSu0mq6SJSeMOz
4n2NGStWwv/uJGORDMmGgmudQgiEceWLVvzSdgzm3z6RT0ZmzHicoiQQrsZJrIB+
jOJVALF/QuQRatZV3JLTNad3htg5rmKQNLbICAm9vsokOW3VV14lYz7FyDgrX/VD
XPEWOcvNvVyuyQrryBE0LzuHlUYg6YkuoaAhRNMKb8c6kV4LWLA=
=YTal
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/d_Nzv35xxqjrIZCeHtxu7nUjxR7v18v3TMvwhHxlwHdscXkmoW8X4Qro46k1IiOll0wuC84E8DH_jZuDszKsTLfXb0rx_QWFTwLEBBoijz4%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] qubes-url-redirector v2.1 released!

[Andrew Clausen]

Hi Raffaele,

I just tried it.  A few comments:

(1) I'm not thrilled about using wget to install things.  (I don't trust
https very much.)  What's wrong with using the locally distributed copies
of files from git?

(2) It wreaks havoc!  When I restarted Firefox, and did "restore old tabs",
it tried to open them all in disposable VMs.  Please start with a
non-disruptive default, or issue big warnings.

(3) Suggestion: have a "paranoid" mode that can be enabled easily on the
toolbar to switch the default to disposable VMs.

(4) Suggestion: you could perhaps re-use disposable VMs, since they are
quite costly to create.  There could be a button to create a fresh
disposable VM.

Kind regards,
Andrew

On 2 February 2018 at 18:38, 'Raffaele Florio' via qubes-devel <
qubes-devel@googlegroups.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi all :),
> I've just released the qubes-url-redirector extension. The GitHub repo is
> at [0] and the issue on QubesOS's repo is at [2].
> The extension is based on the gsoc idea [1]. Soon I'll work on the
> Thunderbird one :).
>
>
> Here a brief description:
> 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.
> Before this release, the installation process was a pain, now it's very
> simplified. I hope that you enjoy it! :D
>
>
> [0] = https://github.com/raffaeleflorio/qubes-url-redirector
> [1] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-
> chrome-extensions
> [2] = https://github.com/QubesOS/qubes-issues/issues/3152
>
>
> Best Regards,
> Raffaele.
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp0sCMACgkQjTxG+6f1
> ce4eKxAAkSxYKxp8e1gvTmiG2douRvicYm+U5HSeRQ/ORikjVf796TDmWhAAplYB
> WNC8y6Hyy9PfRMS/ySY5qs1IguK6XlLa/+2zCZv5UGl7R8n0GeLmnxVRgSMStIRz
> rZk68tAxOpConrvLx5JJPL2og2ZKPfjVjXRWGmHwhPkCOM/Bn6drAgJm2W3NLjhZ
> Cp8Hwqzi3Kd8+K7y/nvkBcA/FUJe/y8Ctdf8KDRtKcO83fQKQDDGLjoeQAb89zTj
> w4BEvMa2UTfEtY1POugAL73UDf/mRj8Y4K0IMlPRC8G619OminnyIIAdVaVcc4cg
> Jzg0qmYMJ+ZSNGZXqVmaminoLQzf9ds2w+VTh9AlkrXCVckAagcSXCwsh/X7XYAc
> TsK5rAqzuvTb79uj+h9a3RAwtpwnawY0famhLCL/YDZaKPcF/saGkwZefDksAI4R
> S0fKsJZkXT9SkwpQOeV9wSlIwm7p1IkSsGCKDm6HOtolOO0AUEejFg4af8hVWAl2
> gHTvjN4+qZbFgstbNbTaJ7Bh6WKlDa3HcrJk11x/S29QeQ08W1qeTuasYl/Yr+Zi
> fKAwfhqjFa/N8qBtInogoyzqxk5BPeikOFnedz1P+Afxe/jfuUnrleChqwKvSc89
> jSLmqKi+lrT97EgMVrQm6dXJaLZGZNhMF4GooRSYd3gZPKzXgTE=
> =Bco5
> -END PGP SIGNATURE-
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-devel@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/qubes-devel/PhffsPxhxd-8U28yQLW4CBpOqiZwqOmno2DyWNftwMIxzyKowatO2K_
> 8qluvPyhkt1kBBNKIc2XqD_60Ur-qm5QKvTjaC0qba7OKEORAles%3D%40protonmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJBNrM9ffbg6yDgFCN0eGQa6RsMFPOFR%3D_Gh0qJFe5J4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] qubes-url-redirector v2.1 released!

['Raffaele Florio' via qubes-devel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all :),
I've just released the qubes-url-redirector extension. The GitHub repo is at 
[0] and the issue on QubesOS's repo is at [2].
The extension is based on the gsoc idea [1]. Soon I'll work on the Thunderbird 
one :).

Here a brief description:
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.
Before this release, the installation process was a pain, now it's very 
simplified. I hope that you enjoy it! :D

[0] = https://github.com/raffaeleflorio/qubes-url-redirector
[1] = https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
[2] = https://github.com/QubesOS/qubes-issues/issues/3152

Best Regards,
Raffaele.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp0sCMACgkQjTxG+6f1
ce4eKxAAkSxYKxp8e1gvTmiG2douRvicYm+U5HSeRQ/ORikjVf796TDmWhAAplYB
WNC8y6Hyy9PfRMS/ySY5qs1IguK6XlLa/+2zCZv5UGl7R8n0GeLmnxVRgSMStIRz
rZk68tAxOpConrvLx5JJPL2og2ZKPfjVjXRWGmHwhPkCOM/Bn6drAgJm2W3NLjhZ
Cp8Hwqzi3Kd8+K7y/nvkBcA/FUJe/y8Ctdf8KDRtKcO83fQKQDDGLjoeQAb89zTj
w4BEvMa2UTfEtY1POugAL73UDf/mRj8Y4K0IMlPRC8G619OminnyIIAdVaVcc4cg
Jzg0qmYMJ+ZSNGZXqVmaminoLQzf9ds2w+VTh9AlkrXCVckAagcSXCwsh/X7XYAc
TsK5rAqzuvTb79uj+h9a3RAwtpwnawY0famhLCL/YDZaKPcF/saGkwZefDksAI4R
S0fKsJZkXT9SkwpQOeV9wSlIwm7p1IkSsGCKDm6HOtolOO0AUEejFg4af8hVWAl2
gHTvjN4+qZbFgstbNbTaJ7Bh6WKlDa3HcrJk11x/S29QeQ08W1qeTuasYl/Yr+Zi
fKAwfhqjFa/N8qBtInogoyzqxk5BPeikOFnedz1P+Afxe/jfuUnrleChqwKvSc89
jSLmqKi+lrT97EgMVrQm6dXJaLZGZNhMF4GooRSYd3gZPKzXgTE=
=Bco5
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/PhffsPxhxd-8U28yQLW4CBpOqiZwqOmno2DyWNftwMIxzyKowatO2K_8qluvPyhkt1kBBNKIc2XqD_60Ur-qm5QKvTjaC0qba7OKEORAles%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.