dom0 environment lost on restore
141 views
Skip to first unread message
Ryan Tate
Apr 1, 2019, 2:26:26 PM4/1/19
to qubes-users
I recently had to wipe my Qubes machine, resinstall, and do a full restore of my VMs from a very recent backup (three days old).
Although the backup included dom0, and the restore as well, I have lost various key settings. My xfce panel shrank and moved to the top and the button size changed, for example. My desktop icons for launching applications are all gone. Caps lock no longer mapped to Control. My command history is gone in dom0 terminal. Clock is wrong format. Etc etc.
Is it possible to get any of these back? Were they backed up anywhere and are hidden for security reasons or something? And if not, what is actually, like, backed up when I back up dom0?
Thanks for any pointers.
Although the backup included dom0, and the restore as well, I have lost various key settings. My xfce panel shrank and moved to the top and the button size changed, for example. My desktop icons for launching applications are all gone. Caps lock no longer mapped to Control. My command history is gone in dom0 terminal. Clock is wrong format. Etc etc.
Is it possible to get any of these back? Were they backed up anywhere and are hidden for security reasons or something? And if not, what is actually, like, backed up when I back up dom0?
Thanks for any pointers.
Ryan Tate
Apr 1, 2019, 2:33:37 PM4/1/19
to qubes-users
> On Apr 1, 2019, at 2:26 PM, Ryan Tate <ryan...@ryantate.com> wrote:
>
> Although the backup included dom0, and the restore as well, I have lost various key settings. My xfce panel shrank and moved to the top and the button size changed, for example. My desktop icons for launching applications are all gone. Caps lock no longer mapped to Control. My command history is gone in dom0 terminal. Clock is wrong format. Etc etc.
>
But what do I do with this? I just have to manually figure out what files are important? :-\
Ryan Tate
Apr 1, 2019, 3:54:44 PM4/1/19
to qubes-users
> On Apr 1, 2019, at 2:33 PM, Ryan Tate <ryan...@ryantate.com> wrote:
>
> Now I see there is a folder in my dom0 home dir called ‘home-restore-2019-04-01-etcetc’.
>
> But what do I do with this? I just have to manually figure out what files are important? :-\
I would like to say, I really think the wrong decision was made here:
https://github.com/QubesOS/qubes-issues/issues/2271
https://github.com/QubesOS/qubes-issues/issues/1106
The rationale for not actually restoring dom0 when dom0 is requested to be restored seems to be:
1.User may be restoring to a different machine from the original, which could obviate e.g. monitor settings. User can’t simply avoid restoring dom0 in this situation "because it contains some files and scripts that I need” (quote from issue 2271).
OR
2. user may only restore some VMs and then the dom0 restore will create false menus (issue 1106)
I would argue, if you ask to restore dom0, then dom0 should be restored (truly, not by copying over a directory, which is not a “restore”). Any glitches due to, for example, restoring dom0 to a different machine, are the responsibility of the user. User may also need to handle restoring dom0 with only partial vm restore, for example by purging appmenus (although ideally the restore process or architecture of Qubes would make partial restores happen more smoothly).
If the wish is not “restore” but rather to copy some files — “some files and scripts that I need” — then it is up to the user to transfer these files by the usual mechanism.
IMO Qubes has allowed the definition of “restore” to become a bit corrupted. To restore is not just to copy a directory and let the user fend for themselves. When I “restore”, the original state should largely come back. e.g. app menus in vms, xfce panel particulars, desktop particulars, etc. If I want something different, for example only to copy some settings over, it should be up to me as a user to make that happen. If the restore is imperfect, that is OK — it would be better to have an imperfect restore (with, for example, some phantom menus) than to have no restore at all, from the standpoint of user expectations, judging purely from myself.
Just my $.02.
awokd
Apr 1, 2019, 6:37:34 PM4/1/19
to qubes...@googlegroups.com
Ryan Tate wrote on 4/1/19 7:54 PM:
These seem like reasonable points though for visibility & tracking, it
might be better to paste them directly into one of those issues.
might be better to paste them directly into one of those issues.
Andrew David Wong
Apr 1, 2019, 10:02:09 PM4/1/19
to Ryan Tate, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
What is "the usual mechanism"? The main problem with the old behavior
was that there was no reasonable way to get the dom0 home files out of
the backup without clobbering the current dom0 home files that you
want to keep.
> IMO Qubes has allowed the definition of “restore” to become a bit
> corrupted. To restore is not just to copy a directory and let the
> user fend for themselves. When I “restore”, the original state
> should largely come back. e.g. app menus in vms, xfce panel
> particulars, desktop particulars, etc. If I want something
> different, for example only to copy some settings over, it should
> be up to me as a user to make that happen. If the restore is
> imperfect, that is OK — it would be better to have an imperfect
> restore (with, for example, some phantom menus) than to have no
> restore at all, from the standpoint of user expectations, judging
> purely from myself.
>
> Just my $.02.
>
Clearly the best thing would be the ability to choose either option. I
suggest filing an enhancement request for this.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlyiwpIACgkQ203TvDlQ
MDApJhAAkoud/M1YUwLmHR9myZ5QJGK5nviHJRx4oTVTss+z3QfPRWe3SDQRRtO4
TsBNzeP/BZ3+Elhqvt2KvTJ+f2Ej5Ingb66Cm/HmDwjBHkR5av02d0/WCoz/d3Q7
FXlQgcbFJlqaebTVk/LiLA+6s+RPINd693/fK9h0bgVALInEWTqkxOwKsC/n5kID
L0byqJVcZN06OKSQH+8zTTM4G+O20tMUJGFfBEAosyUpMVAejG0ar7UBh9peEoin
YCReg9REuMlMNqViWG2g0MKnzH/2/WPN+2U2k8atfFdSKvCASL5HztCLPjOryWNH
QWZrtrvYgA2Wju5B5LsroqesaNq2cd0yUBSetXkvfA0rONSW6E3DM5rZ1DOSgEfV
TID8+HEZVWZlxT6ahLqyglkWLbXauOyJ+vnIBh29SO0vnL4Nl3GTsyIfClWG9pxv
+DCw6OxDMjuIurZypGA+eWu4bAKiGPMlsxYfTqARWVz/nsC2YkE1bpGXcZr8RvD6
oOsTDqHUiu/GpcB8+UNfyIASg8861PXOn/zmz/XEWs0ZM1PfD7+uU2XQlPqfRJdN
UdYi6Eza6camvurVFKMnoMYqooOSS6E2nDaRjy5Qnvrp4doZmzCe7fwryuiOLLGJ
5xWUTPt3/5rU6hPN+foY91AazQvFg01Jepre16M/8mJON0sTcWc=
=l5r0
-----END PGP SIGNATURE-----
Hash: SHA512
was that there was no reasonable way to get the dom0 home files out of
the backup without clobbering the current dom0 home files that you
want to keep.
> IMO Qubes has allowed the definition of “restore” to become a bit
> corrupted. To restore is not just to copy a directory and let the
> user fend for themselves. When I “restore”, the original state
> should largely come back. e.g. app menus in vms, xfce panel
> particulars, desktop particulars, etc. If I want something
> different, for example only to copy some settings over, it should
> be up to me as a user to make that happen. If the restore is
> imperfect, that is OK — it would be better to have an imperfect
> restore (with, for example, some phantom menus) than to have no
> restore at all, from the standpoint of user expectations, judging
> purely from myself.
>
> Just my $.02.
>
suggest filing an enhancement request for this.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlyiwpIACgkQ203TvDlQ
MDApJhAAkoud/M1YUwLmHR9myZ5QJGK5nviHJRx4oTVTss+z3QfPRWe3SDQRRtO4
TsBNzeP/BZ3+Elhqvt2KvTJ+f2Ej5Ingb66Cm/HmDwjBHkR5av02d0/WCoz/d3Q7
FXlQgcbFJlqaebTVk/LiLA+6s+RPINd693/fK9h0bgVALInEWTqkxOwKsC/n5kID
L0byqJVcZN06OKSQH+8zTTM4G+O20tMUJGFfBEAosyUpMVAejG0ar7UBh9peEoin
YCReg9REuMlMNqViWG2g0MKnzH/2/WPN+2U2k8atfFdSKvCASL5HztCLPjOryWNH
QWZrtrvYgA2Wju5B5LsroqesaNq2cd0yUBSetXkvfA0rONSW6E3DM5rZ1DOSgEfV
TID8+HEZVWZlxT6ahLqyglkWLbXauOyJ+vnIBh29SO0vnL4Nl3GTsyIfClWG9pxv
+DCw6OxDMjuIurZypGA+eWu4bAKiGPMlsxYfTqARWVz/nsC2YkE1bpGXcZr8RvD6
oOsTDqHUiu/GpcB8+UNfyIASg8861PXOn/zmz/XEWs0ZM1PfD7+uU2XQlPqfRJdN
UdYi6Eza6camvurVFKMnoMYqooOSS6E2nDaRjy5Qnvrp4doZmzCe7fwryuiOLLGJ
5xWUTPt3/5rU6hPN+foY91AazQvFg01Jepre16M/8mJON0sTcWc=
=l5r0
-----END PGP SIGNATURE-----
Chris Laprise
Apr 2, 2019, 7:52:19 AM4/2/19
to awokd, qubes...@googlegroups.com
system was reinstalled due to a compromise (or suspicion thereof). This
change was made shortly after Qubes project started promoting the idea
of "paranoid mode" restore, with which it fits very well.
In any case, the object for qvm-backup* isn't to save/restore everything
about dom0 since it only stores /home. And moving these files out of the
restore folder is relatively easy, if the user chooses.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Ryan Tate
Apr 2, 2019, 9:04:49 AM4/2/19
to Andrew David Wong, qubes-users
> On Apr 1, 2019, at 10:01 PM, Andrew David Wong <a...@qubes-os.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 01/04/2019 2.54 PM, Ryan Tate wrote:
>>
>> If the wish is not “restore” but rather to copy some files — “some
>> files and scripts that I need” — then it is up to the user to
>> transfer these files by the usual mechanism.
>>
>
> What is "the usual mechanism"? The main problem with the old behavior
> was that there was no reasonable way to get the dom0 home files out of
> the backup without clobbering the current dom0 home files that you
> want to keep.
Why is file transport being shoehorned into the backup mechanism? In order for some people to use restore for something other than restore, I had to spend a bunch of time navigating through obscure folders, copying with globs and mv and shunting aside old dirs, restarting (multiple times), and crossing my fingers it would work. Shouldn’t it be users who are doing strange, non backup/restore things who have to jump through hoops, and people who simply want to restore dom0 who get helpful default behavior?
If people seem open to a change I’ll file an enhancement request.
>
Andrew David Wong
Apr 3, 2019, 1:01:36 AM4/3/19
to Ryan Tate, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 02/04/2019 8.04 AM, Ryan Tate wrote:
>> On Apr 1, 2019, at 10:01 PM, Andrew David Wong
>> <a...@qubes-os.org> wrote: On 01/04/2019 2.54 PM, Ryan Tate
>> On Apr 1, 2019, at 10:01 PM, Andrew David Wong
>> wrote:
>>>
>>> If the wish is not “restore” but rather to copy some files —
>>> “some files and scripts that I need” — then it is up to the
>>> user to transfer these files by the usual mechanism.
>>>
>>
>> What is "the usual mechanism"? The main problem with the old
>> behavior was that there was no reasonable way to get the dom0
>> home files out of the backup without clobbering the current dom0
>> home files that you want to keep.
>
> The usual mechanism would be however you would normally move files
> from one machine to another. Not the backup/restore mechanism,
> since he scenario of wanting to move some files and scripts to a
> new machine is not backup/restore.
>
In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
>>>
>>> If the wish is not “restore” but rather to copy some files —
>>> “some files and scripts that I need” — then it is up to the
>>> user to transfer these files by the usual mechanism.
>>>
>>
>> What is "the usual mechanism"? The main problem with the old
>> behavior was that there was no reasonable way to get the dom0
>> home files out of the backup without clobbering the current dom0
>> home files that you want to keep.
>
> The usual mechanism would be however you would normally move files
> from one machine to another. Not the backup/restore mechanism,
> since he scenario of wanting to move some files and scripts to a
> new machine is not backup/restore.
>
dom0's home and VMs from one machine to another. This is because it is a
violation of the Qubes security model to move files from a less trusted
VM to dom0, and every other VM is, by definition, less trusted than
dom0. Therefore, qvm-backup[-restore] is the only official, secure way
to move files into dom0.
Sure, maybe this doesn't fit some narrow, technical definition of
"restore," but so what? For practical purposes, how does that affect
users in the real world who are trying to get things done securely? If
it really mattered, we could generalize the name to avoid using the word
"restore," but the name doesn't really matter to that degree.
For what it's worth, a lot of dedicated backup software also doesn't
abide by this narrow definition of "restore." For example, a lot of
backup software will deliver your restored files to you as a download,
via email, or in a location other than the original location or computer
from which they were backed up. "Backup and restore" doesn't have to
mean restoring an entire machine state. In Qubes, it's about
user-data-level backup. Using qvm-backup on dom0 is not intended to
duplicate the functionality of lvm snapshot.
> Why is file transport being shoehorned into the backup mechanism?
> In order for some people to use restore for something other than
> restore, I had to spend a bunch of time navigating through obscure
> folders, copying with globs and mv and shunting aside old dirs,
> restarting (multiple times), and crossing my fingers it would
> work. Shouldn’t it be users who are doing strange, non
> backup/restore things who have to jump through hoops, and people
> who simply want to restore dom0 who get helpful default behavior?
>
$ mv home-restore-2019-04-01-etc/* . # move all normal files out
$ mv home-restore-2019-04-01-etc/.* . # move all hidden files out
Simple, quick, and easy, with no weird hoops to jump through.
Now, don't get me wrong. I understand perfectly well that it's only
"simple, quick, and easy" _if you know what to do_ and that this will
_not_ be obvious to many users. But that's precisely why I suggested
that it should be an option via qvm-backup-restore and the GUI tool.
Make it discoverable so that users can understand that there are two
possible outcomes and choose the one they want, then do it for them.
> If people seem open to a change I’ll file an enhancement request.
>
issue for it:
https://github.com/QubesOS/qubes-issues/issues/4946
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
MDBe0w/+MdEEYakxVkGf1fA9lWl0gRM2wByzik0qR6yAjadA0JjdFB6zYNmSoW+7
Y0m2DLQ3N9CtA4dW/hcphJu0ujyNiV4HC0MVdbHPhsOSQSLckJ1wCrXR1zUPYDL2
egsB1cseT7n101y/zZt78DD9iCImurtkQZuF1wRHlYl8iVTgS+nE6BOPOxFd4rns
htX939BJrzhPWPh0etra2c6SupNxBBJgtOieEMkHcFY+BiE9rH36bbia6JWJXDYk
1sVGggUM6LgteqCwKHr9bRB40rpllMLG9/k/uisPvEP9wBj2Z1eMJ8Vro0zcIexF
2aoRy1vMSNZuT49C3T6+ABvdcr+eqN9ahssMSDP5zitqTPZwgncAoPubTRaKmUth
ST/50Cps3Hy7d5aYv8T/h1rClfwlw0c8tctYwFzjaeN45Vqjc7cAZzwv6IKOGPhE
WLcIs46JDHpYbbxi1Tdb1FUYiFVShSUacVzHI+G6tQBVJ3n0Lh3r65ByYhiAexHJ
HksFGMjDaJYF9dYeBwAtXgofCeOgYrIb1MR0Km7SnlRj9Acts/RrmGUS3ep8wm5/
MsLB+ykdujVFKahMi7mtCM717jMaahNCPxnU3gMCIUy8LqUo70vKFDR+xWG6AB6B
piCB6wFYibkJPJjf4DagJJERnj7p6ej53+ZntZ9ZPohI/wfswKE=
=+k1V
-----END PGP SIGNATURE-----
Ryan Tate
Apr 3, 2019, 1:53:53 PM4/3/19
to Andrew David Wong, qubes-users
Thanks for the thoughtful replies (I just now saw Chris' from before).
Also thank you Andrew for making a Github issue!
It sounds like there is at least some common ground on providing
smoother restore as an option, which I appreciate. If it's too much to
add code to that effect anytime soon (I know this is a small project)
I wonder if there could be some documentation just that's ok to
wholesale replace the new dom0 user home dir with the old one and
maybe giving the relevant shell command?
Personally, I expected the old dom0 to be the default and would vote
that it be the default as I wonder if these other scenarios (potential
compromised dom0, moving files to new machine) are really more common
than restore for more mundane reasons.BUT that said I think just
presenting the choice of whether to write old or new dom0 will provide
sufficient clarity for most people regardless of the default. I expect
most people look at the options pretty carefully when restoring.
Replying to some specific points:
On Tuesday, April 2, 2019 at 7:52:19 AM UTC-4, Chris Laprise wrote:
> The current method prevents an unsafe restore in the event that the
> system was reinstalled due to a compromise (or suspicion thereof). This
> change was made shortly after Qubes project started promoting the idea
> of "paranoid mode" restore, with which it fits very well.
That seems reasonable as the default if it is expected that this is
usually why people are restoring. I wonder if it's not more common
that people restore for other reasons, in which case I'd argue that
the current behavior should just be an option. But as I said above,
it's probably not a big deal - just giving people a choice would
probably lead to the right outcome.
On Wed, Apr 3, 2019 at 1:01 AM Andrew David Wong <a...@qubes-os.org> wrote:
>
> In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
> dom0's home and VMs from one machine to another. This is because it is a
> violation of the Qubes security model to move files from a less trusted
> VM to dom0, and every other VM is, by definition, less trusted than
> dom0. Therefore, qvm-backup[-restore] is the only official, secure way
> to move files into dom0.
Fair point, I forgot how hard Qubes makes it to move files into dom0.
That said, I would just note -- Files from dom0 do traverse other VMs
in all the scenarios we've discussed. I expect in backup/restore
scenario they are encrypted as they transit, for example, sys-usb. But
I don't know of any reason this could not be the case for random files
you want to export -- you would encrypt in gpg symmetric mode in dom0
with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
wherever and out into the world.
Admittedly, you would then need to jump through hoops to go back into
dom0, so it can't be described as "the usual way" as I did.
> All you had to do was move everything out of the restored subdirectory:
>
> $ mv home-restore-2019-04-01-etc/* . # move all normal files out
> $ mv home-restore-2019-04-01-etc/.* . # move all hidden files out
>
> Simple, quick, and easy, with no weird hoops to jump through.
>
> Now, don't get me wrong. I understand perfectly well that it's only
> "simple, quick, and easy" _if you know what to do_ and that this will
> _not_ be obvious to many users. But that's precisely why I suggested
> that it should be an option via qvm-backup-restore and the GUI tool.
> Make it discoverable so that users can understand that there are two
> possible outcomes and choose the one they want, then do it for them.
Yes, agree, thanks for finding the common ground.
> > If people seem open to a change I’ll file an enhancement request.
> >
>
> Since I was already writing all this, I just went ahead and opened an
> issue for it:
>
> https://github.com/QubesOS/qubes-issues/issues/4946
Thanks again for doing this.
Also thank you Andrew for making a Github issue!
It sounds like there is at least some common ground on providing
smoother restore as an option, which I appreciate. If it's too much to
add code to that effect anytime soon (I know this is a small project)
I wonder if there could be some documentation just that's ok to
wholesale replace the new dom0 user home dir with the old one and
maybe giving the relevant shell command?
Personally, I expected the old dom0 to be the default and would vote
that it be the default as I wonder if these other scenarios (potential
compromised dom0, moving files to new machine) are really more common
than restore for more mundane reasons.BUT that said I think just
presenting the choice of whether to write old or new dom0 will provide
sufficient clarity for most people regardless of the default. I expect
most people look at the options pretty carefully when restoring.
Replying to some specific points:
On Tuesday, April 2, 2019 at 7:52:19 AM UTC-4, Chris Laprise wrote:
> The current method prevents an unsafe restore in the event that the
> system was reinstalled due to a compromise (or suspicion thereof). This
> change was made shortly after Qubes project started promoting the idea
> of "paranoid mode" restore, with which it fits very well.
usually why people are restoring. I wonder if it's not more common
that people restore for other reasons, in which case I'd argue that
the current behavior should just be an option. But as I said above,
it's probably not a big deal - just giving people a choice would
probably lead to the right outcome.
On Wed, Apr 3, 2019 at 1:01 AM Andrew David Wong <a...@qubes-os.org> wrote:
>
> In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
> dom0's home and VMs from one machine to another. This is because it is a
> violation of the Qubes security model to move files from a less trusted
> VM to dom0, and every other VM is, by definition, less trusted than
> dom0. Therefore, qvm-backup[-restore] is the only official, secure way
> to move files into dom0.
That said, I would just note -- Files from dom0 do traverse other VMs
in all the scenarios we've discussed. I expect in backup/restore
scenario they are encrypted as they transit, for example, sys-usb. But
I don't know of any reason this could not be the case for random files
you want to export -- you would encrypt in gpg symmetric mode in dom0
with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
wherever and out into the world.
Admittedly, you would then need to jump through hoops to go back into
dom0, so it can't be described as "the usual way" as I did.
> All you had to do was move everything out of the restored subdirectory:
>
> $ mv home-restore-2019-04-01-etc/* . # move all normal files out
> $ mv home-restore-2019-04-01-etc/.* . # move all hidden files out
>
> Simple, quick, and easy, with no weird hoops to jump through.
>
> Now, don't get me wrong. I understand perfectly well that it's only
> "simple, quick, and easy" _if you know what to do_ and that this will
> _not_ be obvious to many users. But that's precisely why I suggested
> that it should be an option via qvm-backup-restore and the GUI tool.
> Make it discoverable so that users can understand that there are two
> possible outcomes and choose the one they want, then do it for them.
> > If people seem open to a change I’ll file an enhancement request.
> >
>
> Since I was already writing all this, I just went ahead and opened an
> issue for it:
>
> https://github.com/QubesOS/qubes-issues/issues/4946
Ryan Tate
Apr 3, 2019, 1:59:23 PM4/3/19
to Andrew David Wong, qubes-users
On Wed, Apr 3, 2019 at 1:53 PM Ryan Tate <ryan...@ryantate.com> wrote:
> That said, I would just note -- Files from dom0 do traverse other VMs
> in all the scenarios we've discussed. I expect in backup/restore
> scenario they are encrypted as they transit, for example, sys-usb. But
> I don't know of any reason this could not be the case for random files
> you want to export -- you would encrypt in gpg symmetric mode in dom0
> with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
> wherever and out into the world.
As I should have suspected, using the official backup-restore tools
> That said, I would just note -- Files from dom0 do traverse other VMs
> in all the scenarios we've discussed. I expect in backup/restore
> scenario they are encrypted as they transit, for example, sys-usb. But
> I don't know of any reason this could not be the case for random files
> you want to export -- you would encrypt in gpg symmetric mode in dom0
> with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
> wherever and out into the world.
does get you integrity checks (and perhaps better encryption?)
compared to this more basic technique I outlined, so I'm not
suggesting anyone run out and do it.
https://www.qubes-os.org/doc/backup-emergency-restore-v4/
Andrew David Wong
Apr 4, 2019, 4:00:29 AM4/4/19
to Ryan Tate, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
protecting dom0.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
MDDu2xAAnRBgCdSkgCTJs6nQs0gTy30ig/Ow5NqYTto6+pQfxOi1YYoQKAtzxNoH
bejIpw9BzxmtTpb2s7sJ5LfChQpONVMghpHhUxuweUSsMQpKWQRdFcl/AgLWDUPl
x65dqrl1rD/nvZ2gvyt0JxPgvLJGIrc7jnewa49t4GgMOqOihclfZ8DeeBjxONxB
5G3O3wJVDdsAhGGFmlzE2++WKTEm7ZxxW2H8RTWXVefPjxw9KiIpSIc+I2foIP8m
bohvihfoQutJ8xMUKvcGuWPArn1qdZnVxlHzkv6+LzeFNg5MgBefG493A0c75uu7
k/2aZM6zebVf8G+m4mZXWdL7jF5B+sjwVyLLp9gQPouYrckn/5Liks31KEd79gt3
5lUJdecvNLg5WwJ0O4FluMZ9qy9iX/lqI2IsSlux32Ag/roEWU98ntkcCMHIFsgQ
VGLk0sZVnn9gQsayNmnfUyWq26jwdTEmWhZaAst36x+vnOhP0SurY3oSTzDeOTVT
MzpEGaQfQiHsnZwC4WEgmPh4XO9dA46irxmAFoRKnzXopsA0wEAzlKO3wSHSPZa0
SDZdFJj+NrwUlJ+ru3GvtNFzg61vjdjgB6qq4AsZWjaRMtJ8T+1Vzirra8EzqLN1
ALDiQhfEwZJdF1nEs9C4zH7K2qU9WVDVafinyEh67tKFapaGEkM=
=kRPu
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages