dom0 update for ppc64le support

[Timothy Pearson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

We have been investigating the use of Qubes on our upcoming Talos™
workstation product [1], however it looks like there are a couple of
issues preventing a port from being built on the ppc64le architecture at
this time.

1. Most critically, the version of Fedora Core used for dom0 (FC20) does
not support the ppc64le architecture. We would like to see at least
FC22 used as the dom0 before working on a port. Is a dom0 version
update already planned, and if so is there an estimated time for
availability?

2. At this time POWER8 uses kvm, not Xen, as its hypervisor. From our
conversations with the Xen developers it would be at least a couple of
years (best case) before POWER8 support could be added to Xen. How
bound is the current versio of Qubes to Xen, and is there a general
process that should be followed to properly add kvm support to the Qubes
helper utilities?

Thanks!

[1] https://raptorengineeringinc.com/TALOS/prerelease.php

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWzJy6AAoJEK+E3vEXDOFbaGMIALa8ae4F9y1apB4s+61MXkVF
8CBgkPqh6g2RsF3t4J2+loMOwHBuPiZsmYGoSvSu3xdsmjhmvE2eXyT3Kuc05Ysw
kP6X9+iSifTOEYFQI9BDb28uNFNvnopu9nYQNt5A76f0kicoUfFVn7TXf1Qc+bkw
jQM4vZV/ehEyFtIFtJXFvif3A6/3YPVK9TxujH+DE5ctupQEV4tzZNBFmQiwzbfK
OUnT0P5uwuCMpMmfwYLMfYQAs9br2KGWewZ3uiEZlTVO87/UdBJWah/twtoPdB1x
2Jc8FrNZwmr/FOIRepRwVh8IyrdNj8GxzCM9bIWOkIr3Vxd0qGgztK1kMFA/lu8=
=sfvJ
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Tue, Feb 23, 2016 at 11:54:02AM -0600, Timothy Pearson wrote:
> Hi all,
>
> We have been investigating the use of Qubes on our upcoming Talos™
> workstation product [1], however it looks like there are a couple of
> issues preventing a port from being built on the ppc64le architecture at
> this time.
>
> 1. Most critically, the version of Fedora Core used for dom0 (FC20) does
> not support the ppc64le architecture. We would like to see at least
> FC22 used as the dom0 before working on a port. Is a dom0 version
> update already planned, and if so is there an estimated time for
> availability?

I think this problem is quite easy to solve compared to the other one.
Anyway there is (at least) one blocker for dom0 upgrade to newer Fedora:
KDE window decoration plugin. KDE 5 have different API for them and it
looks like the plugin needs to be rewritten from scratch. Details:
https://groups.google.com/d/msgid/qubes-devel/20150708225129.GN900%40mail-itl

We have some plans for adding Gnome 3 support, which should somehow
workaround this problem (but still some people prefer KDE).

> 2. At this time POWER8 uses kvm, not Xen, as its hypervisor. From our
> conversations with the Xen developers it would be at least a couple of
> years (best case) before POWER8 support could be added to Xen. How
> bound is the current versio of Qubes to Xen, and is there a general
> process that should be followed to properly add kvm support to the Qubes
> helper utilities?

Generally the architecture introduced in Qubes 3.0 makes it possible to
add such port. Which doesn't mean it's trivial... See this blog post
for details:
http://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html

> Thanks!
>
> [1] https://raptorengineeringinc.com/TALOS/prerelease.php
>

- --

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWzM01AAoJENuP0xzK19cstMEH/j40A6r6ATLEBSvyTen7U+EW
Sx6rY67nYy2MBnbn4IE6ZcEuar13aibicbFdVETBYLQ9764DyyJlFYB3eg/P+Z8i
pexlk8RxJCOq9j53RVV8SrFKoyxnM7GCDTy5coDFyTWzjR/XV6/SJrreg6fpryAR
t3EXUmvtzZHBsEjAnF1fyjB39XMDl7hzsu7q32FODQUQv2PSdVIaVn+ILE3qOepv
sTnGKcZAWY3YVf27LjKGOiu2uqbSdlURwX0EijlEXSZ3QOty3pRYtGeR1nLVX1Tl
QYSLuv9/debsNPlb2+z84ghPXt1tAlpJ3AsycDxrQWAIDzuhEJW5oBXKR+h9zJE=
=TPNK
-----END PGP SIGNATURE-----

[Thierry Laurion]

I'm not sure I follow.
Xen doesn't support Power architecture. Does it?
https://unix.stackexchange.com/questions/91368/xen-hw-virtualization-on-power-architecture

[Thierry Laurion]

No it doesn't. Is there a status update on the development of the abstraction layer?

Thanks,
Thierry

[awokd]

I'm curious about this as well. If one's end goal was Qubes running on
non-x86 arch., what would be the best approach to pursue?

A. Port Xen to Power, then Qubes (classic workstation with a handful of
high GHz threads)
B. Locate blob free ARM hardware, then port Qubes to ARM (Xen on ARM
already exists; Qubes Air on multiple ARMs?)
C. Add missing functionality/security to KVM, then port Qubes to a
supported platform on it (this sounds as hard as option A to me, but don't
have a good idea of the complexities)
D. Despair and stay on x86

Of course, Qubes on all the architectures/hypervisors would be ideal but
given limited resources, which makes the most sense over the next couple
years?

P.S. Thanks, Qubes team, for 4.0 final!

[Marek Marczykowski-Górecki]

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

IMO realistically options C or B are the best. Which one will happen
depends on multiple factors, including having a company willing to pay
for it...

> P.S. Thanks, Qubes team, for 4.0 final!

:)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqzbrQACgkQ24/THMrX
1yw3Agf/eoFIPe5r71NGTTySzasOdJomuyV9tChlTYUGUsKEwyW9TsU+zvIIkX8a
8YSXa8orjidGBbGKyggyYxzStIUPURRTgQbmeEyGH2QFW/2HbZ4iwTj7aTyE1VaS
kXCXELTmdmAiOU8jP6BNRvSqGriqt8QC8FzG3f5RKNLHVWS0iwTucV8UCUKf+AJ9
M4IY4h0GLABEJUSst7NA/y2VfpYYm3stAtNojkMV6feuVpgJIj5LC/hccdEiF/zg
uh21DsBmcA8b+2sfNHY19nYl7UbJqo90roaVbOKUUg292TZct9h1rlraHFukTeiW
hbl0eo8SSuUXtKsNMNgCXEJJK7kVHg==
=v2of
-----END PGP SIGNATURE-----

[Thierry Laurion]

Raptor would be willing for cooperation.

https://twitter.com/RaptorEng/status/980670947731689473?s=20

I think it would be nice for QubesOs and Raptor to talk and see what could be done.

Users need Talos. They just don't know it yet. And they won't know until its available. Who can invest?

[Thierry Laurion]

https://www.opentech.fund/

?

Need help writing a collaborative proposition? That might be fun.

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/IFLyyCUbLmQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-devel...@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/9fa27ef6-f95f-4034-83be-dda977be555a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Raptor Engineering Sales]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raptor Engineering can provide access the hardware needed to make this
happen at no cost, plus some degree of support for issues encountered.
We just need people willing to put in the time / work on the Xen port to
ppc64el.

None of the ARM server / workstation platforms in existence with modern
performance are open -- even the ThunderX2 relies on an AMI firmware
stack with an AMI BMC, plus we normally see ME-type blobs in other parts
of modern ARM systems. Building something like Qubes on top of such a
shaky foundation is something that has always concerned us, and one of
the primary reasons why we want to see it fully support POWER systems as
a first-class citizen.

What do we need to make this happen?

On 04/02/2018 12:21 AM, Thierry Laurion wrote:
> https://www.opentech.fund/
>
> ?
>
> Need help writing a collaborative proposition? That might be fun.
>
> Le lun. 2 avr. 2018 01:11, Thierry Laurion <thierry...@gmail.com

> <mailto:thierry...@gmail.com>> a écrit :

>
> Raptor would be willing for cooperation.
>
> https://twitter.com/RaptorEng/status/980670947731689473?s=20
>
> I think it would be nice for QubesOs and Raptor to talk and see what
> could be done.
>
> Users need Talos. They just don't know it yet. And they won't know
> until its available. Who can invest?
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "qubes-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-devel/IFLyyCUbLmQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> qubes-devel...@googlegroups.com

> <mailto:qubes-devel%2Bunsu...@googlegroups.com>.

> To post to this group, send email to qubes...@googlegroups.com

> <mailto:qubes...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/9fa27ef6-f95f-4034-83be-dda977be555a%40googlegroups.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...@googlegroups.com
> <mailto:qubes-devel...@googlegroups.com>.

> To post to this group, send email to qubes...@googlegroups.com

> <mailto:qubes...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/qubes-devel/CAAzJznzsZ5QCow53WTVRNgV0XFGK5YL9HJLhCiZ0deULFnev2g%40mail.gmail.com
> <https://groups.google.com/d/msgid/qubes-devel/CAAzJznzsZ5QCow53WTVRNgV0XFGK5YL9HJLhCiZ0deULFnev2g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

- --
Raptor Engineering Sales
Phone: +1 (512) 690-0200
https://www.raptorengineering.com

Follow us on Twitter:
https://twitter.com/RaptorEng

Follow us on GNU Social:
https://social.raptorengineering.io/raptoreng

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJawcQ4AAoJEJcY8NXk1BLEWKkP/3fuoqvjWKmACx/AC9Zt0Dv6
dZ9h69RLlHGbCmkIhVkEvO/iSod9qcif1594z/P7m51+RWa7ES6NPG7tequMIjm7
irRBbz3+iNSBdEgGsuCwXCPaAg2aFoVjxGo7uAbggDmmNZycq66SsqrrYJ5GsjPu
NIrnf+smeDp9t/1UjTnd14C2R350FyFJm0xk/GLzMybhCWEvYGiRY0i0IGkPYKT8
spLpRo0wIQGaFvBOY0PV6BuyTHtRP2YA0e6rdAy/M9sWQlgPIDKwLVxcc2f4Zy1D
AmKiEv1e8yFKcUQQ2JZbaWsu8teDL10Kplj4mua8i0tHfiLHKDxG2+s+HtdbRqCb
ZExxeuKISy3ro/7OBrncsECBDm/55ECU4akafz2s7SyWM2tp8XAuYeTK6S2qrUwF
I/QpHjIG4HIh2AqCuXOvYgH8MneUdNlztj4KtJWSDoNUIOJ3kze17jMr3ZDwWuVE
d+CVWLcYiYj5+ib0VyId0Fqf8Dw5Q2ssTb5xhvhLtc3k6iN11tFshaa1ZPUIV4EX
E45/lP6TaSLjO5b6S/yCPX3eXd7s4OKkIK5IPSBJHRht6asNutYaCQIN2dfOkFpf
pFF4sAFQzDU+1dqw8mYmSaoe1NdDqkzxGy0fkI9hgK40MGc151OYmlDSImokrCXo
HhAQdr3hj4/HZLjWHPS2
=5Coz
-----END PGP SIGNATURE-----

[awokd]

On Mon, April 2, 2018 5:48 am, Raptor Engineering Sales wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Raptor Engineering can provide access the hardware needed to make this
> happen at no cost, plus some degree of support for issues encountered. We
> just need people willing to put in the time / work on the Xen port to
> ppc64el.
>
> None of the ARM server / workstation platforms in existence with modern
> performance are open -- even the ThunderX2 relies on an AMI firmware stack
> with an AMI BMC, plus we normally see ME-type blobs in other parts of
> modern ARM systems. Building something like Qubes on top of such a shaky
> foundation is something that has always concerned us, and one of the
> primary reasons why we want to see it fully support POWER systems as a
> first-class citizen.
>
> What do we need to make this happen?

From upthread, sounds like Qubes on KVM on Power might be most realistic.
Have there been any improvements to KVM since
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf
was written?
Specifically, this conclusion:

"We believe that the Xen hypervisor architecture better suits the needs of
our project. Xen hypervisor is very small comparing to Linux kernel, which
makes it substantially easier to audit for security problems. Xen allows
to move most of the “world-facing” code out of Dom0, including the I/O
emulator, networking code and many drivers, leaving very slim interface
between other VMs and Dom0. Xenʼs support for driver domain is crucial in
Qubes OS architecture.
KVM relies on the Linux kernel to provide isolation, e.g. for the I/O
emulator process, which we believe is not as secure as Xenʼs isolation
based on virtualization enforced by thin hypervisor. KVM also doesnʼt
support driver domains."

Eight years later, what would need to be done in KVM to close the gap with
Xen? All of the above?

[roberta...@gmail.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Restarting this thread from the Github issue.

I too am a fan of the KVM approach.

I strongly support applying for the Open Tech Fund. The next deadline is November 1st, 2018. Personally, I think this is an incredibly high priority project. It is near impossible to keep systems secure without running Qubes OS, yet there is no secure platform you can yet run it on. TalosII, on the open Power Architecture, is the answer to this, as it is the only system with open and auditable schematics and firmware. Currently, we have to choose between running Qubes on backdoored systems, or running open systems with operating systems that can be taken down by a single vulnerability in the browser.

I am more than glad to help start writing this. Does anyone have previous experience with this?

Robert

PGP Key Fingerprint:
0x0748CDCC2CFC85A8F782420E9F9A647732B465ED
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEB0jNzCz8haj3gkIOn5pkdzK0Ze0FAluoakMACgkQn5pkdzK0
Ze07LA//fmi5zFVixwm/JO5IQYDci+mSDXzEnLaS/3OsczsZyy6rmniSwh6uTpvn
t/ichVHg3wFuSQAPmO0G9+JdTZ4uQfcwp+6RaaCjpJHPpX3t5sSMpOsus4xsiH6o
tNGIoOnYXA6oYarcamKdukqahxQIib2IRmobXEg1fom2d1NvPxSzCOUpq5RS2e8y
TTRhVBS4ruCs5QmzbQH0u8SGanklcLytS1jdKxVLDvhsoNRRZyi7G3Qc73+cQAIa
y++TYMkaM3PtxIhvIFW0vZIdC1voWrAqfaYJ1ndumxuoQDeXs6oQA2utTVslZaPj
7oCPJvgsxDzeseWFckqD8H3cCjOhALhAcz4zOR/B7EI1qtuASCx6qHju6kWUibet
XIXPHHdvInJBS/CPjmNMpjkRJ9Byx/qggd8+e5cNaotW17cNO6ZU9TBGL4X3V4gR
AYTkFpwX/ZQ7G/8HoNX/qclx2p9iKj/QMR6Y5a5Rgikf+D7kX2JXXZyfNHebVt6m
Jir8Fr2OqqCZTg3RsZTZT2pAbqDP4OxfhmO2i/0ENyM7MydCDxz8pMNBWgZ4Lm4S
AkRH8fUYxBwu4l/9PLXzW41P9/vOWYSGk6rz6auU7531oLqAGZpJIvxSQKJFU5Y0
4tTqimGkxGVNTS5DWGWGCvdriCQl1wyWBIJuPQFuhkkbi4hHzTM=
=R21y
-----END PGP SIGNATURE-----

[awokd]

roberta...@gmail.com:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Restarting this thread from the Github issue.
>
> I too am a fan of the KVM approach.
>
> I strongly support applying for the Open Tech Fund. The next deadline is November 1st, 2018. Personally, I think this is an incredibly high priority project. It is near impossible to keep systems secure without running Qubes OS, yet there is no secure platform you can yet run it on. TalosII, on the open Power Architecture, is the answer to this, as it is the only system with open and auditable schematics and firmware. Currently, we have to choose between running Qubes on backdoored systems, or running open systems with operating systems that can be taken down by a single vulnerability in the browser.
>
> I am more than glad to help start writing this. Does anyone have previous experience with this?

The thread I linked in
https://github.com/QubesOS/qubes-issues/issues/4318
(https://groups.google.com/d/msg/qubes-devel/IFLyyCUbLmQ/_HtgOJK4AQAJ)
has Marek also mention KVM. No experience here, but adding the missing
pieces to KVM seemed the hardest step. I'd like to see Qubes running on
an open architecture as well, and am willing to help.

[roberta...@gmail.com]

I meant experience in regards to applying to the OTF fund actually.

Since we are already on the Google platform, would a google doc be a good place to start this for collaborative work?

[Thierry Laurion]

Here, the general form of an OTF application. I propose the use of Riseup as a hoster of EtherPad for collaboration, on which I copy pasted the required content to fill up.

https://pad.riseup.net/p/S4I1r4HOyIqEsncxqxnisdx-keep

Time for collaboration guys! This means involving people that could help (Xen, QubesOS, RaptorEngineering, grant, financial previsions etc). Gather them here!

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 9/24/18 5:21 PM, roberta...@gmail.com wrote:
> [...]

>
> Since we are already on the Google platform, would a google doc be a good place to start this for collaborative work?
>

We're just using Google Groups as distrusted infrastructure for the
mailing lists, and many people use the mailing lists without having
Google accounts:

https://www.qubes-os.org/support/#mailing-lists-vs-forums

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

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

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlusGqIACgkQ203TvDlQ
MDC8aw//SyE+/z8oNL2D6tSxkoCEurb99cwjNDzlNb9yPcKJylZquuodoDWDhHe6
am+c63qvUBs8rndyFgSf2emBRbEjIAIZDGJG8EvTbrwL1qWZbCYmjBRnLx6vipqQ
sgKwdLBvykLqqsty/BXSK7+ZXGcAR8W/3D56PS4O3uvLfs59A3MYV2KOYv+rJjjL
y5OWxPt3RXdWj534n639IsCxqQ9I8kSsDiUOzfF6oMJohReKiU9sQu6/2+sox0e1
fSsiC9vqinptx1ofo7aEoySleWR5QsICAudKOmmZFUMa5ZXZyscIhg+d/+JRXbZY
momTwmS2A4PjRwfKgRWurnoVUreEWn0Ay9HCxLbx6+OeAfLBKldK3QtxKEW0kOC3
YYnyFgfBh0PzYNcJyZxDaEyfyRtWr7ffaqmvlhCto3TYLN5mT81ZpzMiR/LSGcQt
/T91XsnYK0VyVtiiQbDnBlgFbzkWPFOhVgeGfHpUzw7wGgap3zF6qg0tlVw1DsfQ
vOFOzfWy1a86OT6eA3F+TYCHVFPON5L3rsIfhmgPrX/dDjmynineoKzWJTRAX9AY
j0sqra7ZbNFN2FJsZJyMwozDqsu6Y6nal5F+LnnaE13rY09psrGJXFnXGudZb/9T
/1CHVwJo3dW7L5tAQO5oe7tdAGKdLnXwaotQE7xg4nyDt+/UtBM=
=bniK
-----END PGP SIGNATURE-----

[Tai...@gmx.com]

On 09/24/2018 06:21 PM, roberta...@gmail.com wrote:
>
> Since we are already on the Google platform, would a google doc be a good place to start this for collaborative work?
>

Absolutely not - especially for such a project.

Google is a terrible company in regards to computing freedom and freedom
in general.

Hell they even recently removed their "dont be evil" slogan, and are now
being evil with a variety of projects even fully automatic killer drones
and tracking people everywhere by ignoring the location data setting and
putting cameras and microphones everywhere.

People should not be forced to have gmail accounts nor have to complete
their re-captchas[1] or enable javascript.

[1]They use browser fingerprinting and every time you complete a
re-captcha you help their AI research which will put people out of work
and assist the development of killer drones (like project maven)


In regards to qubes for POWER I really hope it happens, it simply NEEDS
to happen - building a distro such as qubes on such as shaky blobbed
non-free x86 foundation is really silly.

[Marek Marczykowski-Górecki]

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

While in principle this (or RISC-V) looks like a good way to go, in
practice it is unrealistic. We want to make something useably for more
than very few people around the world. We want Qubes OS to be something
that user can get and install on broadly available hardware. Until
Qubes OS will be used on >50% computers around the world (ok, much lower
number, say 10%), we are not in position to dictate what hardware is
available in local stores. And the unfortunate truth is that most
hardware available for consumers is x86 today.

Adding ppc64le support will require a lot of effort and without a clear
business use no business entity (including ITL) will fund this. And as
Michael already said, OTF even more focus on something broadly
available rather than raising the barrier even higher.

So, lets first dominate the world, then make it a better place! ;)

Just to be clear - if someone will find/provide funding enough to work
on this, without sacrificing x86 support, we'll be very happy to help
with building a team to make it happen. But until that happen, that's not
something on our roadmap.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlutTK0ACgkQ24/THMrX
1yxDNwgAkY4xVuysD+aWRorbk16BZhb7Jn7UcGcpzMFa+LzTg5IW2JN73iAePJX8
A1rAEzGIv1kHvEwbfGb0Vw1ncCMVMy7iV/cqZCS3k+88tMz345sNSMASgNb7P8N9
9jG35R4UoqZTzf6vDeIrLboxhMW6L2naESJ+AJBUEHdNSsKT532h8Tz88QfYgL8h
KsOlqdpavJ4SVYRvT3C8Ha76J1AYCUdV7siiN5efSZhT+xGq8qc6K8mvM2rN2IUn
2Phz1+J6rQ4d/58C5d7NTWDtiRaEuIT6JBURHZV7cn+XqJmWZlpOYeBosozUIY8p
z8WcoOZVc3zKLE6qYRAcga8mC/Dh4Q==
=QBF+
-----END PGP SIGNATURE-----