qubes-url-redirector v2.1 released!

[Raffaele Florio]

-----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-----

[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

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@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.

[Raffaele Florio]

-----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-----

[Andrew Clausen]

Hi Raffaele,

On 3 February 2018 at 17:09, Raffaele Florio <raffael...@protonmail.com> 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

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

> 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.

>  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.. ;)

> 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?

> (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.

Best Regards,

Raffaele.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlp3Qf4ACgkQjTxG+6f1

ce7BnhAAwF/AY+45vN0w7bnRTv2Db5p6sHwDphKJ0zodyHOdvVb6oUyt6JFkHvbA

u/xsZflBRhZr82u2B+17//lyazXjBN3JiZkDPhKyDie0frlS/4YtTu8W2hNorzOu

lW3QFvie9qsPyPjSqtgUijS7nkPguXCDnbPmYPnnYQLyubI7MOVKD8E+ePW5WAdj

E1lMZvSRot47oB7I7RvCzo1tqSDj6pb72JlTFL1OARYQqyKV5kMOnDOFi4mONCat

tt+u3dMgEm4eQ7k+Y3PEVLmLcw9p2RYawRsF8n+8RZHdCHc1UTpL2hwvii+Um0jW

kggj5GA83wTn6q+4xf4TkVulPMZX9lYagp4Lv3KvQjAxL+Gw+HFhOY9ryREKLcSs

O8hX1VbZBDIk2y2A76+x3AhGPqlpoAzDAKcti9au9ftUw7lbTpZMDTp79DqJiHLD

TAcNmk5xvzzj9yJiswSVff5ykf51ogFVndQpzKxfgwGOqoZtx7w69v46nCp9dnjx

qVD193N5MAlm9ewvGAwYReepcNW0rpBhP69dTzuYFGQzQ5t72ip6Jr7YWa9ReYf2

e3eBzs4jyx9Bsm6IzP0kphcWwp4goxlymnm/Bwa1Knx9RdpZzekVo46ujiC6SZI6

Npbmf5EYLtYqFLXdujuva8CBg1jbBfUSpvBP0KQMov8E9RiEk+s=

=lITa

-----END PGP SIGNATURE-----

[Andrew Clausen]

Hi Raffaele,

On 4 February 2018 at 17:25, Raffaele Florio <raffael...@protonmail.com> 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

 

[Raffaele Florio]

-----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-----

[Andrew Clausen]

Hi Raffaele,

On 5 February 2018 at 08:10, Raffaele Florio <raffael...@protonmail.com> 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

[Raffaele Florio]

-----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-----

[Jean-Philippe Ouellet]

On Sun, Feb 4, 2018 at 5:16 AM, Andrew Clausen
<andrew.p...@gmail.com> wrote:
> On 3 February 2018 at 17:09, Raffaele Florio <raffael...@protonmail.com>

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

[joev...@gmail.com]

Version 2.1 is not working on my Chrome 66.0.3350.0 (Official Build) dev (64-bit)
It blocks URLs properly. It allows those matching the whitelist properly.
But nothing is run on the Default VM specified.

Also, I still need to add polyfill.js to the package prior to Chrome accepting the unpacked extension. The commenting out in the manifest.json doesn't work.
https://github.com/raffaeleflorio/qubes-url-redirector/blob/master/chrome/manifest.json#L41

[Andrew Clausen]

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

Cheers,

Andrew

[Raffaele Florio]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Version 2.1 is not working on my Chrome 66.0.3350.0 (Official Build) dev (64-bit)
>
> It blocks URLs properly. It allows those matching the whitelist properly.
>
> But nothing is run on the Default VM specified.

Did you follow installation instruction correctly?
Did you activate redirection to the default VM?

> Also, I still need to add polyfill.js to the package prior to Chrome accepting the unpacked extension. The commenting out in the manifest.json doesn't work.
>
> https://github.com/raffaeleflorio/qubes-url-redirector/blob/master/chrome/manifest.json#L41

Yeah, the polyfill is needed in Chrome/Chromium due the API's differences.
I have to remove that comment. It's unrelevant.

Best Regards,
Raffaele.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE9bU8N8AgwMcjiC1xjTxG+6f1ce4FAlqUFvYACgkQjTxG+6f1
ce5QlBAAqCdrSlZzHDgXNbipzRMc0DMyCE64SoukrdI4X9vHyrqkiuggOLqUaIfh
jeA/KPBSPJIqrkJ7AygZbtXJvHFe6Mde0qgYLdsDZSWoM5LJR4WU70IeEuoynRRi
yrFLdOvH3E3Du1wDRNDl/o4+fbYOvlpY5tp5QrHBAE0bIb3A2mvENcvT/LT691XU
mgYtUTiVvRwnzvRdzrNQ3TP9K1MLcaIOviuVycwmBB4lB/J2T/itoNISbiSPzHtK
k/xFTudt5drG+A8L7HC3mwUDVmV07UJhF4pTYvjF6X/YiDpwRIaOVvi2VnyM7Qps
c0gR334E1OItYPXK+vRmuemMHkjdRbvZqhDzsMb624IPXGxU8Yi8CAWxvA00Iabz
+rbVNvDpMl5tSXCbajw1jDxNZhI8nNUfdVdmZ8vT0bN5mI97TBgfvkThFrAieARy
W31EBQQXwbqYNKOVeCEB8kViwXAIkhaR188oACLaXFWOTZYRzJt5tqj79MIpDw3k
kcSlpCQlSXJRAa5GWmGfoae5YSqYzluO4xw/k4TNm9bfXoGgdgMv0Sn+HRUekSp6
W1nOIMglooiu8Jm79lPsKOkaP/FtANS8MTWBxawEiuAruuEsJxNE6kNP5o9A8pHR
LiI88JsrCRqPggmQ0n9V/tSDN9rv4UVkKve6L0GgQSzZtbEwQzE=
=ZkPO
-----END PGP SIGNATURE-----