date:20171111

On 11/11/2017 08:51 AM, Yuraeitha wrote:

@ Chris Laprise
On Saturday, November 11, 2017 at 1:45:07 PM UTC, Chris Laprise wrote:

On 11/11/2017 07:54 AM, Yuraeitha wrote:

On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:

For some reason the debian template didn't install when I installed Qubes, even
though I selected it. No matter I thought, I'll do it manually.

However following the instructions here:

https://www.qubes-os.org/doc/templates/debian/

namely:

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8

I get "Nothing to do. Complete"

qvm-ls reveals that debian-8 is absent.

Is this instruction out of date or do I need to enable something first? Any
tips appreciated.

The template re-install is currently broken, and requires fixing in a future
patch. I've had/seen mixed results with the plain template install too (rather
than re-install), so I suspect it's at least partly broken too? Either way it's
not you, this is something that likely needs patch fixing. Possibly you can
re-install Qubes and hope debian installs (sometimes work?, see below), or you
could try move debian from one of your 3.2. backup archives, and then update it
in Qubes 4 (hope for the best that the 3.2. template Qubes tools won't get in
the way).

Occasionally the template install goes wrong.

The first thing to try is 'sudo dnf remove qubes-template-debian-8' to
get the package out of there.

Another option is trying the current Debian release, version 9. There is
one issue (2913) where it takes 90sec to boot, but this should be
corrected soon and its easy to fix: After 90sec run a terminal and enter
'sudo rm
/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service'.
(Make sure you include the at-sign.)

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

I had little luck with that approach on my system, perhaps others can make it
work? But it might be because I did qvm-remove the template in dom0, before I
did the dnf remove in dom0. Perhaps I messed it up this way, it certainly won't
allow me to dnf remove the debian packages now.

What the dnf remove procedure wants is to find lvm disk volumes under
the name 'debian-8' but of course you already removed those with
qvm-remove (which unfortunately allows this in R4.0). A way to work
around this is to clone any template to the name 'debian-8', therefore
providing the expected lvm volumes... then removing the template package
should work.

qvm-clone fedora-25 debian-8
sudo dnf remove qubes-template-debian-8

Then you can install the template again:
sudo qubes-dom0-update qubes-template-debian-8

Also is doing the 'sudo rm
/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service'
instrumental to the success?

In my tests it is necessary or else debian-9 vms will experience 90sec
startup delays.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

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

Re: [qubes-users] Failed to verify R4.0 rc2 digests

2017-11-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-11-11 14:34, nicholas roveda wrote:
> I've just finished to download all the files for R4.0 rc2, but the 
> verification failed.
> 
> gpg --verify Qubes-R4.0-rc2-x86_64.iso.asc 
> Qubes-R4.0-rc2-x86_64.iso.DIGESTS
> gpg: Signature made Sat Oct 21 10:10:36 2017 BST using RSA key ID 9E2795E9
> gpg: BAD signature from "Qubes OS Release 4 Signing Key"'
> 

It looks like your command is a bit off.

If you're trying to verify the PGP signature on the ISO with this
command, the second argument should be the .iso file, not the .DIGESTS
file.

If you're trying to verify the PGP signature on the .DIGESTS file
itself, only that file should be specified.

This is covered in more detail here:

https://www.qubes-os.org/security/verifying-signatures/

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

iQIcBAEBCgAGBQJaB4l/AAoJENtN07w5UDAwHsYP/R4FeJfEfSk5xvlrbjYD7RgL
WfnV7sq3gLVO/FYk9TFy9Jmt6RpQD0CBBbntBNl/WKQ+p8NLson8crizglYo8JZv
YzZtT3gp8TI2B4OGns3JTSoYMIKJGPOXcw02Z8k5VtQ7m/sr4IVAaI2gN6xnuetS
JNDJPiqu9mJWaG3hGv4Ox0zEQQHkAdTwI8scVG88ozV/JclEChyb4JkLppRWizht
JyIJtG/wWGcjvMMxnEB3rqtaXh7TfK7XqEEUfZmjnfZmF5OdKEdbsz6S2/TjKx5b
UmEnm/ozHx42q31nItx0+cREM2F84V7MmAyFZAkD4WECvtkCC+uQiYbN7NzaMMW1
PNAFnQfl9KS0jHnO9AcfYiEgi1D/SDl1UyzYEBmQi/kwU7tq5Nwclka3xqZ2qmVs
t+HEPKHzADsYJM6STxUo5ugG0xQ9BdHoZfm13pk/rMRgN0ok5gXML5BV4bAQXDPT
9hPyZMuvQUkQuiC1RRrQesoNJRLmSjAQ1QWqhQqvyn7CVh5W6PBwXVPHNLtEFwAr
0//iFCe5pSV1NM0Lzqr9yW6kG2zvb7urb1Kl7Ms1tcJJYeqR/GOgRX2DbLeScIim
u+W3VpCtqhlC1cB0tELX8my37l2KH/5oAmEbwM/v+svq697JaYkqpyZuFq/KZHNI
xQAy2wsRT1KugkIpemU/
=I3qB
-END PGP SIGNATURE-

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

Re: [qubes-users] Re: Please specify which Qubes version you are using when you post

2017-11-11 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-11-10 15:27, Yuraeitha wrote:
> On Thursday, November 9, 2017 at 11:15:16 PM UTC, Unman wrote:
>> Now there are increasing numbers of people using 4rc2, it would
>> be really helpful if you specify WHICH version you are using when
>> you post to the list, particularly if you have a problem.. 
>> Sometimes it's obvious from the context, sometimes not, and the 
>> differences between 3.2 and 4 make it difficult to help if you
>> don't say.
> 
> To that end, perhaps allow the community to help update the guides,
> supervised by someone from the Qubes staff before updated to the
> http://www.qubes-os.org/doc page? In order to get more done faster.
> Perhaps make a double guide list, one for 3.2. and another for 4.0,
> until 4 is mainstream, and then later on delete or archive the 3.2
> guide list.
> 
> It could be a thread like this where people can throw in input
> where guides fall short going from 3.2 to 4, or other reasons for
> being outdated.
> 
> This would also hopefully reduce the amount of questions being
> asked if the answers are available.
> 
> https://www.qubes-os.org/doc/backup-restore/ for example is
> hopelessly outdated for Qubes 4 now, and looks like it needs an
> almost complete rewrite to the terminal commands instead of the
> graphical Qubes Manager that is now no more. And it's a guide many
> users may want when going to Qubes 4, especially among those who
> are not savy with the terminal, some Linux users are even outright
> scared of the terminal, its possible some among Qubes users also
> are put off by the terminal. Essentially, this might be one of the
> critical guides to get updated quickly.
> 
> While in contrast other guides, like
> https://www.qubes-os.org/doc/templates/fedora-minimal/ only need a
> copy of the entire post, and then edit 25 to 26 in the entire post.
> Minor less relevant stuff, but easy to point out and fix.
> 
> I mean, things like these the community could help with. It could
> also be extended to help write guides that no one has written yet,
> potentially further helping reducing questions asked.
> 

The mailing list thread is a good idea, and I see you've already
started one. Thank you! Also, high quality documentation improvements
are always welcome!

https://www.qubes-os.org/doc/doc-guidelines/

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

iQIcBAEBCgAGBQJaB4aBAAoJENtN07w5UDAw4+0QALX0A1/t6LeyW+wfFB7V/HJL
3X2BMC4UlIgjqDRcsgDZuKgBCW1wMpolnEijinPsIMXGiUdFvwbq4PCXzX2anR0F
C+z4mqfVRdhb7+HM6IlQ8cLmSOWdLbJSZqpMxBqpzyAr+ZlV5gkez10fNAn9d+xW
1pi4njbyHQKcRNgiWe88bVFgREtrOxU+UjUS0Y9OsE2f5PQ9jZOvBGnQ9J+B408Y
h/Ld9Ah63NpyYaTcNZG5ORGtdvyL+OD5WeReDiPY4aBj5F7reL/a11/R35fH3yrE
HP/TcYrvRW1MfJSczhj6NWAja2PAni1228Tc1w7Bn0FHQ0oq5U+tFzgAKUtfhoUJ
4BWV1t6ObGD6PBRioB3SgFbVhqWursXXBDMLBmEgx0g1tOFyfjO6ZmLZh4wK9Sus
Dwe334EL051+so7FKKvupLvVKsDB5ItDxtNN2n2YPt20rdxKGzz45WCUfHVa8yYm
dkuy2yQMXwtmhFj/XQBypCTI7wr62wVYEHKBfNLjYwp4VmeibshRPfDqIgk9IzPO
kp8+6ocVgsUN5NseNi0xlkBdDP91X/yRSMhUvLCSp+z5eKuAuRL0M1jCkpEgkkqC
ybz6PQuNW+QinuGLduRLjTEi63AfamaSEhAv8yPd/Woa5WrZrGh46LQIwDBIp+5W
FIUbNNKf730y5kmFOGWT
=DwGW
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aebd7cc1-350c-1c1f-16ad-ae89ded8b58d%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes & Quantum decryption Immunity

On 11/11/2017 08:31 AM, Yuraeitha wrote:

On Saturday, November 11, 2017 at 12:44:54 PM UTC, Chris Laprise wrote:

On 11/10/2017 05:51 PM, taii...@gmx.com wrote:

In this case you should ask the luks/dmcrypt mailinglist as that is
what qubes uses for disk crypto.

Would be simpler off the bat to limit discussion to asymmetric crypto,
as that is the type thought to be vulnerable to qc. LUKS/dmcrypt and
most other disk encryption uses symmetric crypto.

I believe qvm-backup crypto is also symmetric (although IIRC it may have
specific security issues that need to be addressed).

Finally, there is anti-evil-maid; I think it uses symmetric but not certain.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

That's an interesting twist, and seems like a very good point.

Though does that mean asymmetric is more vulnerable due to it's nature of
having two key systems (Private/Public) rather than a single private key? Lower
entropy with two keys perhaps?
or is it because asymmetry is typically used more when send over the internet
compared to symmetry which is more often used offline?

So then, asymmetric internet protocols going in and out of Qubes, or encrypted packages
or whole encrypted files send over the internet, is the bigger concern? or the more
immediate between the two one I assume. The question left to me, out of curiosity, is
just "why is it the asymmetric security a bigger concern". Are any of the two
guesses the right reason?

There are some articles/talks that explain the difference, but its not
due to entropy. Its because the public key provides too much info about
the private key to a qc search algorithm. This was already the case with
regular computer searches, at least with RSA which uses much larger keys
than a symmetric cipher like AES to compensate for the issue.

A figure I heard was that qc can cut search time for symmetric key
merely in half, whereas its can cut time for asymmetric key by orders of
magnitude.

Also about another aspect, are there by any chance any kind of encryption
between the ioslated qubes in Qubes? If true, then internet based attacks
cannot attack dom0 no matter what happens in the area of encryption cracking?
but it may be able to attack whatever is using encryption in the VM itself? But
offline physical encryption crack attacks, albeit seemingly requiring stronger
cracking capability, can reach dom0?

Specifically, if I understood this correctly, there is no immediate concern
right now to protect with encryption in an offline physical machine, unless a
copy is made of the data and stolen, or the entire drive is stolen, to be
cracked in the future. So if a drive, or copy thereof, is stolen, it may be a
future risk, but otherwise not a current risk.

Eventually all this seems to boil down to theft of data, or surveillance, which
is left to be cracked in the future, instead of now. But internet encrypted
data is significantly easier to steal.

Most Internet encryption is based on asymmetric ciphers. That's the main
issue and Qubes is not special in any sense on this topic.

As for quantum networks, they are slightly more obtainable than, say,
moon rockets.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a96c354a-19b9-2ba0-ad68-f39dffbac44a%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Experimenting with Wireguard VPN @Mullvad.net


On 11/11/2017 10:44 AM, Grogins wrote:


> Have tried to get Wireguard up on multiple occasions with both Debian
> and Fedora I get similar results every time. i.e. at step 3:
>
> [root@wireguardtey)mp ~]# qvm-copy-to-vm vpn /lib/modules/$(uname
> -r)/extra/wireguard.ko
> qfile-agent: Fatal error: stat wireguard.ko (error type: No such file or
> directory
>
> I've searched for file "wireguard.ko" but no results.
> Any ideas?


It must have failed to build the .ko during install. Probably the best 
way around this in Qubes 3.2 is to switch to the in-template kernel, per 
the link I sent. If you're using Qubes 4.0 the kernel switch process is 
simpler: qvm-prefs vmname kernel ''


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/81e28b48-839c-b00e-a5d6-2bafc407a320%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] /var/log excessive filesystem usage


On 11/11/2017 03:38 PM, taii...@gmx.com wrote:
Wait fedora doesn't sign their stuff? Damn that's terrible! So when 
you dnf something there isn't any gpg verification of the files?




Fedora signs packages individually. But nearly all (except Fedora) sign 
the overall repository manifest as well. Lack of repo signatures allows 
an attacker to selectively prevent individual updates from being 
installed. On a typical non-Fedora distro, the attacker can only hold 
back the entire repository (and they can't change the timestamp to make 
it appear current).


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a0840c91-4c56-d504-18aa-9d81af2edaa7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - ASUS PRIME B350M-A + AMD Ryzen 7 1700X

2017-11-11 Thread Foppe de Haan

On Saturday, November 11, 2017 at 10:25:42 PM UTC+1, Foppe de Haan wrote:
> On Saturday, November 11, 2017 at 8:12:17 PM UTC+1, David Schissler wrote:
> > Does the AMD Ryzen equivalent of VT-d work properly?  It seemed that AMD 
> > setups were quite deficient before and I'm hoping that they will become 
> > first class with Zen and Ryzen.  Lenovo recently a Thinkpad with an older 
> > AMD CPU and I'm guessing that it was a warmup for a Ryzen option by the 
> > middle of next year.
> 
> As far as I'm aware (I have a ryzen 1600 as my main system), it works without 
> problems (helped by the fact that AMD actively worked with Xen to ensure Zen 
> support). There should be additional laptops coming out q1, now that raven 
> ridge is finally done.

Only issue with RR is that vega display stack support is likely only coming 
with 4.15 (assuming Linus gives the green light), which isn't very likely to 
ship with the qubes installer.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5021adf9-46e2-42dd-8cf6-c960cfe97619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - ASUS PRIME B350M-A + AMD Ryzen 7 1700X

2017-11-11 Thread Foppe de Haan

On Saturday, November 11, 2017 at 8:12:17 PM UTC+1, David Schissler wrote:
> Does the AMD Ryzen equivalent of VT-d work properly?  It seemed that AMD 
> setups were quite deficient before and I'm hoping that they will become first 
> class with Zen and Ryzen.  Lenovo recently a Thinkpad with an older AMD CPU 
> and I'm guessing that it was a warmup for a Ryzen option by the middle of 
> next year.

As far as I'm aware (I have a ryzen 1600 as my main system), it works without 
problems (helped by the fact that AMD actively worked with Xen to ensure Zen 
support). There should be additional laptops coming out q1, now that raven 
ridge is finally done.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0d5057fb-6730-4dfb-986b-143155509f08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Does VT-d protect against this?

2017-11-11 Thread taii...@gmx.com


On 11/11/2017 06:27 AM, Yuraeitha wrote:


How on earth are these people getting away these crimes against humanity? It's 
truly mindblowing.
People keep buying their crap, or giving them their data[1], and the MSS 
has paid off all the right people. (ME as an No Such Agency project is 
too simple, it is probably much more than that)
When you use gmail you are supporting googles AI research which will 
eventually put tens of millions out of work, every time you solve a 
re-captcha you enhance their machine learning algorithms.


You are probably sitting in a chair and typing on a keyboard made in 
china by some large company? why? was saving a small amount of money 
worth putting your countrymen out of work? eventually putting you out of 
work? helping the PRC?


The best thing you can do to stick up for yourself is stop buying their 
cheap crap, it is as they say "vote with your wallet".


[1](ex: you with gmail, STOP USING IT - there are alternatives such as 
paying a massive $5/mo for email where you get tech support no spying 
and a professional email address without many letters and numbers after 
it as all the good ones are gone, can also use your own domain name too 
which is super easy)


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

Re: [qubes-users] /var/log excessive filesystem usage

2017-11-11 Thread taii...@gmx.com

On 11/11/2017 06:58 AM, Chris Laprise wrote:

Systemd linux takes 1min+ to boot vs 15 seconds on devuan's plane
jane SysVinit (redhat only created systemd to run a hostile takeover
of the linux community
... you must be new to Linux. :) Redhat has long exercised undue
influence over Linux development. When "desktop Linux" was a trend
over a decade ago, they threw their weight around in that arena too.
Unfortunately the community is stupid enough to let an unabashed
server-only company determine the direction of desktop development.

I have been using it for a decade :<

OTOH, going back to init instead of fostering one of the alternatives
has exposed a regressive streak in the community. Sysvinit sucked eggs
for use cases involving power management (sleep/wake/etc), peripheral
hotplug, anything where the system had to enter different global
states. It probably still does suck and somehow I can't believe that
devuan is thoroughly testing for PC use cases (doubt they even
recognize 'use case' as a development concept); On my last survey, no
one except Canonical does this.

I dunno SVI works fine for me.
You can install a few other init systems in devuan too, it is your choice.
Gentoo is also a great option if you have a fast CPU and time on your
hands then you can have whatever init system you desire. (I wish it came
with a nice management GUI so it wasn't such a time sink)
The tragedy here is that Ubuntu tried to address the issue reasonably
in their usual fashion (follow Apple's lead) and Redhat and their
neckbeard camp said "No". Over the years: No apt, No Mir, No upstart,
No addressing desktop security bug reports, No repo signing on Fedora
(can't compete with RHEL on update security!), No certification of
PCs... They'll wait 7-10 years until their boys get around to doing it
over. Redhat are the Knights Who Say NIH (Not Invented Here). Now
Canonical is taking their business and they are flailing about.
Wait fedora doesn't sign their stuff? Damn that's terrible! So when you
dnf something there isn't any gpg verification of the files?

Closed - wontfix User: lpottering

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/9fd906fc-3930-1d2c-f566-0fa81f6e04e9%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Failed to verify R4.0 rc2 digests

2017-11-11 Thread nicholas roveda

I've just finished to download all the files for R4.0 rc2, but the verification 
failed.

gpg --verify Qubes-R4.0-rc2-x86_64.iso.asc Qubes-R4.0-rc2-x86_64.iso.DIGESTS
gpg: Signature made Sat Oct 21 10:10:36 2017 BST using RSA key ID 9E2795E9
gpg: BAD signature from "Qubes OS Release 4 Signing Key"'

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

[qubes-users] Re: HCL - ASUS PRIME B350M-A + AMD Ryzen 7 1700X

2017-11-11 Thread David Schissler

Does the AMD Ryzen equivalent of VT-d work properly?  It seemed that AMD setups 
were quite deficient before and I'm hoping that they will become first class 
with Zen and Ryzen.  Lenovo recently a Thinkpad with an older AMD CPU and I'm 
guessing that it was a warmup for a Ryzen option by the middle of next year.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2c899377-6486-48ac-85f9-434c4ebe9f01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Propspect : When upgrading to the next stable version of Qubes 4.0XXX

2017-11-11 Thread brutellealexandre

When there will be a stable supported version of Qubes 4., and I upgrade, will 
I be able to keep all my set ups and docs on each on my VM's ? 

Or will I have to wipe it all in order to upgrade and install the new version ? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/93f2592a-9ebe-45d9-95e3-6a2a57e36318%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes & Quantum decryption Immunity

2017-11-11 Thread Vít Šesták

QC is a potential threat for both symmetric and asymmetric cryptography, just
the symmetric cryptography is threatened quite a bit more. And even asymmetric
cryptography is important for QubesOS security because of update signatures.

Symmetric cryptography is threatened by Grover's algorithm. The algorithm can
perform bruteforce search in N elements in O(sqrt(N)) time. In other words, it
reduces O(2^n) time to O(2^(n/2)) time. What's great: There is some proof that
this algorithm is optimal (probably under assumption that P≠NP). So, just using
double-length keys should be sufficient. This could justify AES256 instead
AES128. Doubling the key length could be an issue for password, but if you use
a memory-intensive key derivation function, it might be infeasible to run it on
quantum computers for some time.

Asymmetric crypto usually (always?) relies on problems that are believed to be
easier than NP. Some of them (integer factorization and discrete logarithm
problem) can be solved in polynomial time on QC (they belong to BQP class),
which would be a real threat for cryptography like RSA and ECC. There are some
“QC-proof”
asymmetric schemes that are believed to be secure against QC. But those aren't
widely used yet. It could be useful to use them together with some old schemes
like RSA or ECC.

Regards,
Vít Šesták 'v6ak'

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

Re: [qubes-users] Experimenting with Wireguard VPN @Mullvad.net

2017-11-11 Thread @LeeteqXV (Twitter & Mastodon.technology)

On 11/11/2017 10:44 AM, Grogins wrote:

Sent with ProtonMail  Secure Email.

 Original Message 
Subject: [qubes-users] Experimenting with Wireguard VPN @Mullvad.net
Local Time: November 6, 2017 4:51 PM
UTC Time: November 6, 2017 4:51 PM
From: tas...@posteo.net
To: qubes-users 

Mullvad recently added trial Wireguard VPN support, so I wrote a
howto
for setting it up on Qubes:

https://github.com/tasket/Qubes-vpn-support/wiki/Wireguard-VPN-connections-in-Qubes-OS

This is Debian-oriented but easy to adapt for Fedora.

Chris Laprise,tas...@posteo.net 
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

You received this message because you are subscribed to the Google 
Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to qubes-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to qubes-users@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58ea7822-448d-e745-e6f7-1a1fb3a2f927%40posteo.net.

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

> Have tried to get Wireguard up on multiple occasions with both Debian
> and Fedora I get similar results every time. i.e. at step 3:
>
> [root@wireguardtey)mp ~]# qvm-copy-to-vm vpn /lib/modules/$(uname
> -r)/extra/wireguard.ko
> qfile-agent: Fatal error: stat wireguard.ko (error type: No such file or
> directory
>
> I've searched for file "wireguard.ko" but no results.
> Any ideas?

You could search the different kernel versions under the /lib/modules 
dir, as the wg installer sometimes makes an erroneous decision that the 
kernel version you're running is not really the kernel that will be used.

Alternately, on Qubes 3.2: 
https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8471d233-97c5-e8ff-4452-7518e68c9f90%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: 4.RC2 CANT create / install VM from local iso

2017-11-11 Thread lowson . chris

On Saturday, October 28, 2017 at 1:25:33 PM UTC-4, Filip Magic wrote:
> On 10/28/17 11:29, Foppe de Haan wrote:
> > On Saturday, October 28, 2017 at 11:27:36 AM UTC+2, Foppe de Haan wrote:
> >> On Saturday, October 28, 2017 at 9:49:19 AM UTC+2, Roy Bernat wrote:
> >>> On Friday, 27 October 2017 11:26:01 UTC-4, Outback Dingo  wrote:
>  So we need updated docs or somethings broken...
> 
>  i copied the iso to /home/user from the AppVM tried to create an hvm
>  appvm got a unrecognized argument... ok
>  then tried without --hvm... seems ok however. qvm-start
>  results in a traceback
> 
>  [dingo@dom0 ~]$ qvm-create BSD --hvm --label blue
>  usage: qvm-create [-h] [--verbose] [--quiet] [--class CLS]
>    [--property NAME=VALUE] [--pool VOLUME_NAME=POOL_NAME]
>    [-P POOL_NAME] [--template VALUE] [--label VALUE]
>    [--help-classes]
>    [--root-copy-from FILENAME | --root-move-from FILENAME]
>    [VMNAME]
>  qvm-create: error: unrecognized arguments: --hvm
>  [dingo@dom0 ~]$ qvm-create BSD  --label blue
>  sudo qvm-start BSD 
>  --cdrom=/home/dingo/FreeBSD-11.1-RELEASE-amd64-disc1.iso
>  Traceback (most recent call last):
>    File "/bin/qvm-start", line 9, in 
>  load_entry_point('qubesadmin==4.0.9', 'console_scripts', 
>  'qvm-start')()
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 160, in main
>  drive_assignment = get_drive_assignment(args.app, args.drive)
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 98, in get_drive_assignment
>  backend_domain_name, ident = drive_str.split(':', 1)
>  ValueError: not enough values to unpack (expected 2, got 1)
>  [dingo@dom0 ~]$ qvm-start BSD
>  --cdrom=/home/dingo/FreeBSD-11.1-RELEASE-amd64-disc1.iso
>  Traceback (most recent call last):
>    File "/usr/bin/qvm-start", line 9, in 
>  load_entry_point('qubesadmin==4.0.9', 'console_scripts', 
>  'qvm-start')()
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 160, in main
>  drive_assignment = get_drive_assignment(args.app, args.drive)
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 98, in get_drive_assignment
>  backend_domain_name, ident = drive_str.split(':', 1)
>  ValueError: not enough values to unpack (expected 2, got 1)
>  [dingo@dom0 ~]$ qvm-start BSD
>  --cdrom=/home/dingo/FreeBSD-11.1-RELEASE-amd64-disc1.iso
>  Traceback (most recent call last):
>    File "/usr/bin/qvm-start", line 9, in 
>  load_entry_point('qubesadmin==4.0.9', 'console_scripts', 
>  'qvm-start')()
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 160, in main
>  drive_assignment = get_drive_assignment(args.app, args.drive)
>    File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py",
>  line 98, in get_drive_assignment
>  backend_domain_name, ident = drive_str.split(':', 1)
>  ValueError: not enough values to unpack (expected 2, got 1)
> 
>  [user@personal dom0]$
> >>> You dont need to use --hvm . it is the default in version 4. 
> >>> Regarding the cdrom i have also the same issue it seems that this switch 
> >>> has beed deprecated .
> >>>
> >>>
> >>> Roy
> >> try qubes-vm-boot-from-device or qvm-start VMNAME --cdrom=VMNAME:/path ; 
> >> or use the interface from the second page of the VM settings GUI.
> > (Btw, if you type qvm-, or qubes-, bash spits out a 
> > list of commands starting with those characters; you can usually find the 
> > command you are looking for that way; beyond that, --help or 'man 
> > qvm-command' will also provide hints as to available switches, except in 
> > the case of qvm-pci currently.)
> >
> Is qubes-vm-boot-from-device working for you guys ? I'm not able to
> install any OS from ISO in StandaloneVM.

nope having the same issue here, it starts the VM then exits. Going to try a 
block device to see if that works.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/44a31819-112b-43ca-bf08-9466a2b7dbc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Experimenting with Wireguard VPN @Mullvad.net

2017-11-11 Thread 'Grogins' via qubes-users

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: [qubes-users] Experimenting with Wireguard VPN @Mullvad.net
> Local Time: November 6, 2017 4:51 PM
> UTC Time: November 6, 2017 4:51 PM
> From: tas...@posteo.net
> To: qubes-users 
>
> Mullvad recently added trial Wireguard VPN support, so I wrote a howto
> for setting it up on Qubes:
>
> https://github.com/tasket/Qubes-vpn-support/wiki/Wireguard-VPN-connections-in-Qubes-OS
>
> This is Debian-oriented but easy to adapt for Fedora.
>
> Chris Laprise,tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
>
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/58ea7822-448d-e745-e6f7-1a1fb3a2f927%40posteo.net.
> For more options, visit https://groups.google.com/d/optout.

> Have tried to get Wireguard up on multiple occasions with both Debian
> and Fedora I get similar results every time. i.e. at step 3:
>
> [root@wireguardtey)mp ~]# qvm-copy-to-vm vpn /lib/modules/$(uname
> -r)/extra/wireguard.ko
> qfile-agent: Fatal error: stat wireguard.ko (error type: No such file or
> directory
>
> I've searched for file "wireguard.ko" but no results.
> Any ideas?

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

Re: [qubes-users] Relation between increasing RAM and the increased need for display memory


On 28/09/17 12:32, Zrubi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/21/2017 08:47 PM, Teqleez wrote:

Hi all.

I assume this is relevant not only for considerations related to
the practical limit/benefit of increasing RAM in existing
computers, but also regarding the specifications when buying new
computers.

- At the following amounts of RAM; 8GB -> 16GB -> 24GB -> 32GB ->
48GB -> 64GB, how much does the requirements for the graphics card
memory increase with each step, if we assume the
normal/daily/"permanent" usage to be 70-80% of the available RAM?

This obviously depends on how many different VM's one has open, and
how much video memory each one needs, but can we make an assumption
on some sort of average number for this, to see if it is possible
to find some kind of rule-of-thumb figures?

For example, if we assume a "normal"(?!?) Qubes-OS user whose sole
reason for increasing memory is in fact to be able to run more
Qubes simultaneously; how many more Qubes can he/she expect to be
running per extra 8gb of RAM, and how much more will each such step
"typically" require of the graphics card memory, if we assume a
"linear" growth in the number of concurrently open Qubes?

I am guessing that with the capacity to run (increasingly) many
Qubes, the amount of applications running in each one will be
lower, to the point where we most often choose to run
"one-app-qubes". For the sake of this example we could also assume
that this example user is a "lazy" person who will not bother
configuring minimal templates, but only use the default shipped
fedora-24(++) template for each one, just for the sake of
simplicity and playing around with these numbers a bit.


IMHO there is no real connection between RAM used by the OS and apps,
a and the RAM ins your VGA. (VRAM)

VRAM is used for:
- - game (3D) data rendering, which is out of scope in case of Qubes
(maybe if you using Compiz with fancy desktop effects)

- - display rendering.

The later is still need more and more VRAM because of the bigger and
bigger common resolutions Like:
800x600 -> 1024x768 -> 1920x1080 -> 2560x1080 -> 4K -> 8K -> etc.

So you still need more and more VRAM to render all your pixels in your
screens. These can be multiplied if you start using multi-monitor setups
.

But these needs are not growing as fast as your conventional RAM needs.
I'm using 3xHD screens, and the 512Mb VRAM used by the integrated VGA
is still enough for that,  while my OS has 16Gb RAM.


- -- 
Zrubi

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZzM+6AAoJEBozWgtUjzdkzbUQAMuN8HsuXf5YeKERJ8pubew9
5bzQIbv7bffzF0O7w4VndyxF28jE49KLjBkFf6siInOgL4SbG2SQVPP/lyHZG2kq
9rlCu0294ICHU7ASDOfnuQx+6IPJZdUGTXb2tt0r3OlY418Gdj/cHNIT5Ul1j/DW
nGpvKUNQzVzmV0Bl43KlKD4ZwBh1+Xz5AgfI21E2GGKiwpMMKWEGy6ZYmSoe7Opu
0LC/MHWABnQtNwNcGsXyZ6K0BhakuT3va32x4aQC7d2e60iJjvxHaLP+WEFEVSDd
LpbEPQVWA1+LJ4eOC5xmT0LkKCxeBezU2zOk+ZCP0jVcgwS7VecMQchuKUViNBEe
Lgx3BBSb39ZXZb89zwK6y+3nDb81Ewuq95d2i3PnCU72SJi9Z4Uhu5m2xVVYNNf8
eHk+dChrGp7QZ51bHNl4sdDsVGiWC6c7/Vf7LAeL5WBQi6hgeASvoTBWEOsHSgPj
PjTHXw0R3IXrLyfzajLmc51UMh9zn67pstI5y/6KjX89Bv9h38kXg5DnIxNDbxjD
FX0MJAECd2e4y3NOIclPVa8dY1m5nMgo4H4GbPXvF2mXsi1kY/CzTY/zT7/R0HaM
ufXupUY+Hnlv/v+QRlTob+d38H7eLeHf5wqmgIxSrQnsDSqc5HeprMjzQOCNvnaB
dW9yigS7udjNfVDjVbi1
=fVJ+
-END PGP SIGNATURE-



Ref. "(maybe if you using Compiz with fancy desktop effects) "

For me, the desktop environment affects my well-being and mood very 
much, so yes some of such "effects" are important, both for efficiency 
and for the general good feeling when working etc.,, not the fancy part.


I prefer to have 12+ viewports/workspaces, each with its own name and 
background image, so I can associate specific tasks/applications to each 
one, plus with a wrap-around function to navigate beyond the borders. I 
use Compiz for this on Ubuntu, and fortunately all of the above is 
possible in Qubes without any extra tools.


Compiz provides customized window transparency so that when I write, I 
arrange for good (text++) contrast towards the nice background image on 
each desktop, on a per-window basis. I use Alt+[numeric"+"] and 
Alt-[numeric"-"] keyboard shortcuts to increase/decrease the 
transparency on the active window. (Not sure if this is possible in 
Qubes out-of-the-box?)


With this as the background (all done outside of the VMs), along with 
the initially mentioned points about increasing use of one-app-vms, are 
you saying that we can basically just keep upping the RAM without 
worrying about the potential need for increased display memory?


I would like to know what are the minimum requirements for the graphics 
card in this respect, for "both ends of the spectre", so to speak;


a) ~16GB RAM, which is getting increasingly possible with sub-€1000 
laptops (just for the perspective on the limits).

b) >32GB RAM, for the high-end computers.

Will it be possible to use a (compatible) laptop in the sub-€1000 range 
as long as it has enough RAM, or should

[qubes-users] Re: Installing Debian template 4.0rc2


>Try run "dnf search qubes-template-*" in dom0, it'll give you a list of all 
>>installed Qubes templates.

Yes I can confirm debian-8 is there. I'll ignore for now and wait til the next 
update. Thanks for your help.

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

[qubes-users] Re: Installing Debian template 4.0rc2

On Saturday, November 11, 2017 at 2:19:22 PM UTC, JPL wrote:
> >The first thing to try is 'sudo dnf remove qubes-template-debian-8' to
> >get the package out of there. 
> 
> That gives an error: qvm-template-preprocess: qube with this name does not 
> exist

Try run "dnf search qubes-template-*" in dom0, it'll give you a list of all 
installed Qubes templates. It won't fix it, but it'll confirm if you got it 
currently installed or not. If the package is already installed, it'll explain 
why the install command in the first commend did not work. But in contrast it 
won't explain why you cannot reinstall/uninstall though.

Perhaps the next approach would be to manually remove the debian template? I'm 
a little unsure how to go about it though, especially in Qubes 4. 

Anyone out there thinks its a good idea, and have suggestions on how to go 
about it?

Also I rapport that I tried installing debian-9, with little success, it has 
similar behavior as debian-8. But maybe your debian-9 install would work?

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

Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn

On Saturday, November 11, 2017 at 1:40:24 PM UTC, Stumpy wrote:
> On 11.11.2017 13:43, David Hobach wrote:
> > On 11/11/2017 12:52 AM, Stumpy wrote:
> >> 
> >> 
> >> On 10.11.2017 17:45, David Hobach wrote:
> >>> On 11/10/2017 05:41 PM, David Hobach wrote:
>  
> > Your point about sys-net not working might very well be part of it 
> > as it seems to start sometimes and not others, though the firewall 
> > isn't starting 100% of the time.
>  
>  There's a few issues wrt the qubes firewall open on github. The 
>  funny/bad thing about it being that if it doesn't start, it'll 
>  default to "Allow all"... x_X
>  
>  That's present in 4.0rc2 at least.
> >>> 
> >>> Correction:
> >>> Just noticed that you were probably talking about the sys-firewall 
> >>> VM.
> >>> I was talking about the qubes-firewall service running in
> >>> sys-firewall.
> >> 
> >> Well it seems that reinstalling didn't help. I tried w/o creating the 
> >> whonix or usb sys templates, i didn't try the "advanced" option as I 
> >> was not sure how to make templates and wasn't s motivated as to go 
> >> that path. I did try the qvm-start  route and wasn't able to 
> >> start any of them, even when sys-net was up.
> >> A bit of a pity as I was looking forward to tinkering with it... and 
> >> "learning how to stop worrying and love" Qubes w/o a VM Manager, I 
> >> kinda liked the manager ;)
> > 
> > Check the other threads on the topic (there were a couple about VMs
> > not starting recently).
> > 
> > Also try to set non-starting VMs to virt_mode = pv and try qvm-start
> > again. That has some negative security implications (check Joannas
> > thread on pv vs hvm virtualisation), but it might get them started at
> > least.
> > 
> > qvm-prefs sys-firewall virt_mode pv
> > 
> 
> Thanks for the suggestions, while ultimately sec is important to me, for 
> this box I won't do anything important on it so this might be a 
> reasonable temp solution.

Did switching to PV instead of HVM work for you btw? It's good to know for 
others reading this thread in the future.

- - - - -

At any rate, regardless of PV or HVM, Qubes is still really secure compared to 
most (all?) personal based OS systems for daily life. The HVM is an improvement 
up from Qubes 3.2, but Qubes 3.2 was still reasonably secure in its own right, 
in this day and age, compared to the rest of the OS's out there. Like it seems 
you think too, it indeed won't be the end of the world not having it.

It's my understanding that the move towards HVM is to remove the kind of 
difficult to pull off PV attacks, which at current state certainly cannot be 
automated in any kind of malware either (I assume). Maybe a sophisticated 
futuristic A.I. or very dedicated (team of?) hackers with the right resources, 
can pull it off?

Maybe someone more experienced can confirm if PV attacks are indeed rare or 
difficult to pull off, or if any such attack can be made easy, standardized or 
automated. 

Don't get me wrong, I'm not suggesting its meaningless to move to HVM, it just 
does not seem like the end of the world right now not to have it (unless 
someone else proves me wrong). Attacks toward PV might become easier in the 
future too, and early prevention is great, rather than being reactive or 
proactive. 

HVM might currently be more relevant for high profile targeted people using 
Qubes, whom need security. Or the "speculative" unlucky lot whom are the 
victims of skilled hackers out there trying to figure out how to hack Qubes 
(it's speculative how many or if any are trying to find exploits in Qubes on 
live systems in the wild, but rational to assume by the logic of deduction to 
be at least some hackers out there trying to attack live Qubes systems, it's a 
big world). 

So it becomes a question of how many skilled hackers who found a way to attack 
PV whom seek a live Qubes system to practice/learn on, vs. how many users whom 
actually use Qubes, and thereby, the odds/risk that you are among the unlucky 
few to get an successful attack. Seemingly, they should currently be rare and 
unconfirmed.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/95925d74-8ed3-447b-b8cf-5f69901d5d5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Debian template 4.0rc2

>The first thing to try is 'sudo dnf remove qubes-template-debian-8' to
>get the package out of there. 

That gives an error: qvm-template-preprocess: qube with this name does not exist



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

Re: [qubes-users] Re: Question to Mirage OS firewall users

2017-11-11 Thread Thomas Leonard

On Thursday, November 9, 2017 at 4:18:13 AM UTC, Jean-Philippe Ouellet wrote:
> On Wed, Nov 8, 2017 at 3:09 PM, Thomas Leonard wrote:
> > On Thursday, April 13, 2017 at 1:33:53 PM UTC+1, Thomas Leonard wrote:
> >> On Thursday, April 13, 2017 at 11:08:11 AM UTC+1, Foppe de Haan wrote:
> >> > On Thursday, April 13, 2017 at 10:00:20 AM UTC+2, Thomas Leonard wrote:
> >> > > On Wednesday, April 12, 2017 at 10:32:11 PM UTC+1, Foppe de Haan wrote:
> >> > > > Any clue why Windows 7 won't boot when I have MirageOS selected as 
> >> > > > the firewall?
> >> > >
> >> > > I've never tried it. Do the mirage-firewall logs show anything 
> >> > > interesting when you try to boot Windows?
> >> >
> >> > No, but I do have this log (guest-windows-dm). First log doesn't boot 
> >> > (MirageOS), 2nd does (sys-firewall). Is that of any use?
> >>
> >> Oh, that's more useful than I was expecting! Looks like the Windows boot 
> >> process starts by running MiniOS! It's hanging at
> >>
> >> close network: backend at /local/domain/4/backend/vif/79/0
> >>
> >> I guess it asked the firewall to close the network, and never got a reply 
> >> (because the firewall doesn't have any code to do that).
> >
> > OK, I finally got some time to look into this. I think this patch should 
> > fix it (works for Linux HVM anyway):
> >
> > https://github.com/mirage/mirage-net-xen/pull/67
> >
> > I also made a patch that seems to let the firewall work with disposable VMs:
> >
> > https://github.com/mirage/mirage-net-xen/pull/68
> 
> Sweet :)
> 
> > Both are based on guesswork though - is the Xen netback protocol documented 
> > somewhere?
> 
> In xen src:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=refs/heads/master
> 
> netfront / netback in linux:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netback
> 
> And a somewhat outdated but much more approachable introduction in
> section 9.2 (starting p.169) of "The Definitive Guide to the Xen
> Hypervisor" book in case you have access to it.

Thanks. Is there anything about the setup protocol, though? This file seems 
less well commented:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/xenbus.h;h=927f9db5528798fca00455fdd687662d68b18b2e;hb=refs/heads/master

BTW, I've updated the Dockerfile to build with the patches applied now, if 
anyone wants to test it:

https://github.com/talex5/qubes-mirage-firewall/

I've had one report from a Qubes 4.0rc1 user that it now works for them (for 
HVM Linux).

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

Re: [qubes-users] Re: Installing Debian template 4.0rc2

@ Chris Laprise
On Saturday, November 11, 2017 at 1:45:07 PM UTC, Chris Laprise wrote:
> On 11/11/2017 07:54 AM, Yuraeitha wrote:
> > On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:
> >> For some reason the debian template didn't install when I installed Qubes, 
> >> even though I selected it. No matter I thought, I'll do it manually.
> >>
> >> However following the instructions here:
> >>
> >> https://www.qubes-os.org/doc/templates/debian/
> >>
> >> namely:
> >>
> >> [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
> >>
> >> I get "Nothing to do. Complete"
> >>
> >> qvm-ls reveals that debian-8 is absent.
> >>
> >> Is this instruction out of date or do I need to enable something first? 
> >> Any tips appreciated.
> > The template re-install is currently broken, and requires fixing in a 
> > future patch. I've had/seen mixed results with the plain template install 
> > too (rather than re-install), so I suspect it's at least partly broken too? 
> > Either way it's not you, this is something that likely needs patch fixing. 
> > Possibly you can re-install Qubes and hope debian installs (sometimes 
> > work?, see below), or you could try move debian from one of your 3.2. 
> > backup archives, and then update it in Qubes 4 (hope for the best that the 
> > 3.2. template Qubes tools won't get in the way).
> 
> Occasionally the template install goes wrong.
> 
> The first thing to try is 'sudo dnf remove qubes-template-debian-8' to 
> get the package out of there.
> 
> Another option is trying the current Debian release, version 9. There is 
> one issue (2913) where it takes 90sec to boot, but this should be 
> corrected soon and its easy to fix: After 90sec run a terminal and enter 
> 'sudo rm 
> /etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service'. 
> (Make sure you include the at-sign.)
> 
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

I had little luck with that approach on my system, perhaps others can make it 
work? But it might be because I did qvm-remove the template in dom0, before I 
did the dnf remove in dom0. Perhaps I messed it up this way, it certainly won't 
allow me to dnf remove the debian packages now. 

Also is doing the 'sudo rm 
/etc/systemd/system/multi-user.target.wants/wpa_supplicant@.service' 
instrumental to the success?

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

[qubes-users] Re: Installing Debian template 4.0rc2

On Saturday, November 11, 2017 at 1:27:33 PM UTC, JPL wrote:
> Thanks for the detailed reply. I have an i7 machine, installing to a USB 
> stick. Strangely, last time I tried (this is my second installation on the 
> same USB having borked the first) debian-8 *did* install so it's obviously a 
> very quirky bug. Whonix installed OK although it seems very slow (everything, 
> not just Tor browser). I don't see this issue reported on Github. Is it worth 
> reporting or are Axon, Marek et al aware?

I believe the debian template issue is somewhat related to the qvm-run or 
qvm-open-in-vm issues, but I'm definitely not sure if they are related. it just 
feels like that they are. Assuming they are indeed related, then Marek is at 
least partly confirmed to be aware of the issue. I'm not sure if he's fully 
aware of it yet, at least it doesn't seem like he was able to reproduce the 
problem, not at the time of his posting at least.

You can read a discussion here 
https://groups.google.com/forum/#!topic/qubes-devel/0wQftZSmYRY where Marek 
replied on a similar issue regarding the qvm-open-in-vm where I posted about 
qvm-run as well in addition to the original poster. I'm frankly also pretty 
frustrated with this template/AppVM issue, as you can read in those posts. But 
nevertheless, nothing to complain about, it's still in testing phase and not 
released yet, so its understandable. But my, it's one frustrating bug haha 

I believe it to be related, also because on my Ryzen 3 1200 (legacy boot based) 
Qubes 4-rc2 system, everything works, 
- all templates, including debian and whonix. 
- qvm-run and qvm-open-in-vm also worked fine here. 

However when it goes wrong, similar symptoms across both issues emerge on same 
systems, it seems?

I did not test the Ryzen system extensively, but I used it enough to feel it 
was a significant improvement over my own daily Intel M and Intel i5 system.

I'm really not sure if I was just lucky on Ryzen or if it's got anything to do 
with the architecture.

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

Re: [qubes-users] Re: Installing Debian template 4.0rc2

On 11/11/2017 07:54 AM, Yuraeitha wrote:

On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:

For some reason the debian template didn't install when I installed Qubes, even
though I selected it. No matter I thought, I'll do it manually.

However following the instructions here:

https://www.qubes-os.org/doc/templates/debian/

namely:

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8

I get "Nothing to do. Complete"

qvm-ls reveals that debian-8 is absent.

Is this instruction out of date or do I need to enable something first? Any
tips appreciated.

Occasionally the template install goes wrong.

The first thing to try is 'sudo dnf remove qubes-template-debian-8' to
get the package out of there.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/33b48103-2a2d-33d2-f3dd-f791edc58b91%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] View traffic going from/to an appvm? or going through the sys-firewall?

2017-11-11 Thread Stumpy

I posted earlier about trying to limit traffic on some appvms and got 
some helpful feedback about specific services but I am now thinking it 
would be most useful to just see traffic leaving a appvm and then adding 
rules based on that. problem is, i don't know how to view appvm network 
traffic. Is there a command I could use or a log that I could look over 
to help me with this? I would like to do this in both my fedora and deb 
based vms.


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

Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn

2017-11-11 Thread Stumpy

On 11.11.2017 13:43, David Hobach wrote:

On 11/11/2017 12:52 AM, Stumpy wrote:

On 10.11.2017 17:45, David Hobach wrote:

On 11/10/2017 05:41 PM, David Hobach wrote:

Your point about sys-net not working might very well be part of it
as it seems to start sometimes and not others, though the firewall
isn't starting 100% of the time.

There's a few issues wrt the qubes firewall open on github. The
funny/bad thing about it being that if it doesn't start, it'll
default to "Allow all"... x_X

That's present in 4.0rc2 at least.

Correction:
Just noticed that you were probably talking about the sys-firewall
VM.

I was talking about the qubes-firewall service running in
sys-firewall.

Well it seems that reinstalling didn't help. I tried w/o creating the
whonix or usb sys templates, i didn't try the "advanced" option as I
was not sure how to make templates and wasn't s motivated as to go
that path. I did try the qvm-start route and wasn't able to
start any of them, even when sys-net was up.
A bit of a pity as I was looking forward to tinkering with it... and
"learning how to stop worrying and love" Qubes w/o a VM Manager, I
kinda liked the manager ;)

Check the other threads on the topic (there were a couple about VMs
not starting recently).

Also try to set non-starting VMs to virt_mode = pv and try qvm-start
again. That has some negative security implications (check Joannas
thread on pv vs hvm virtualisation), but it might get them started at
least.

qvm-prefs sys-firewall virt_mode pv

Thanks for the suggestions, while ultimately sec is important to me, for
this box I won't do anything important on it so this might be a
reasonable temp solution.

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

Re: [qubes-users] Qubes & Quantum decryption Immunity

On Saturday, November 11, 2017 at 12:44:54 PM UTC, Chris Laprise wrote:
> On 11/10/2017 05:51 PM, taii...@gmx.com wrote:
> > In this case you should ask the luks/dmcrypt mailinglist as that is 
> > what qubes uses for disk crypto.
> >
> 
> Would be simpler off the bat to limit discussion to asymmetric crypto, 
> as that is the type thought to be vulnerable to qc. LUKS/dmcrypt and 
> most other disk encryption uses symmetric crypto.
> 
> I believe qvm-backup crypto is also symmetric (although IIRC it may have 
> specific security issues that need to be addressed).
> 
> Finally, there is anti-evil-maid; I think it uses symmetric but not certain.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

That's an interesting twist, and seems like a very good point. 

Though does that mean asymmetric is more vulnerable due to it's nature of 
having two key systems (Private/Public) rather than a single private key? Lower 
entropy with two keys perhaps? 
or is it because asymmetry is typically used more when send over the internet 
compared to symmetry which is more often used offline?

So then, asymmetric internet protocols going in and out of Qubes, or encrypted 
packages or whole encrypted files send over the internet, is the bigger 
concern? or the more immediate between the two one I assume. The question left 
to me, out of curiosity, is just "why is it the asymmetric security a bigger 
concern". Are any of the two guesses the right reason?

Also about another aspect, are there by any chance any kind of encryption 
between the ioslated qubes in Qubes? If true, then internet based attacks 
cannot attack dom0 no matter what happens in the area of encryption cracking? 
but it may be able to attack whatever is using encryption in the VM itself? But 
offline physical encryption crack attacks, albeit seemingly requiring stronger 
cracking capability, can reach dom0?

Specifically, if I understood this correctly, there is no immediate concern 
right now to protect with encryption in an offline physical machine, unless a 
copy is made of the data and stolen, or the entire drive is stolen, to be 
cracked in the future. So if a drive, or copy thereof, is stolen, it may be a 
future risk, but otherwise not a current risk.

Eventually all this seems to boil down to theft of data, or surveillance, which 
is left to be cracked in the future, instead of now. But internet encrypted 
data is significantly easier to steal.

This could be solved with the quantum network China made a big move towards 
recently though? One of the articles here about Quantum networks that goes into 
the pros and cons, as well as the feasibility and possible directions with the 
technology can take in the future. It seems this short brief article covers a 
bit of everything regarding this complex area 
https://www.wired.com/story/quantum-internet-is-13-years-away-wait-whats-quantum-internet/

Assuming quantum internet ever becomes a full scale replacement of our 
internet, perhaps this is the game changer we need to fix asymmetric 
encryption? After all, it wouldn't be a matter of hacking mathematics, it'd be 
increased to a level of hacking physics and the circumventing the laws of the 
universe. Anyone trying to read the signal, would apparently scramble it and 
make it unreadable. 

But in contrast, this cannot be used in symmetric encryption of i.e. local 
files and drives? and it requires a proper medium, like light fiber cables or 
similar, to carry the quantum signals, which would mean a lot of our modern 
infrastructure is not usable for quantum networking. 

It seems promising though, especially if it would arrive sooner rather than 
later to Linux/Qubes.

For example, the implications of combining quantum networking with the Tor 
network? It'd be potentially unhackable network/internet private connections? 
Tor's weakness, one of the bigger ones, is traffic sniffting at the end nodes. 
A quantum based internet could fix that issue on Tor, making it impossible to 
both know what is send, as well as to whom it was from or to.

Would there be any loose ends though? For example the joint between Qubes OS 
itself, and a future quantum based Tor based network? The weakness could be the 
joints and exploiting these with malware/surveillance? 
If the unit expected to receive the quantum signal itself is infected, then it 
could still surveillance any data/connections going through it? 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c7fc324d-8fe2-43a8-9d56-34c9f1b29056%40googlegroups.com.
For more options,

[qubes-users] Re: Installing Debian template 4.0rc2

Thanks for the detailed reply. I have an i7 machine, installing to a USB stick. 
Strangely, last time I tried (this is my second installation on the same USB 
having borked the first) debian-8 *did* install so it's obviously a very quirky 
bug. Whonix installed OK although it seems very slow (everything, not just Tor 
browser). I don't see this issue reported on Github. Is it worth reporting or 
are Axon, Marek et al aware?  

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

[qubes-users] Re: Installing Debian template 4.0rc2

On Saturday, November 11, 2017 at 12:54:49 PM UTC, Yuraeitha wrote:
> On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:
> > For some reason the debian template didn't install when I installed Qubes, 
> > even though I selected it. No matter I thought, I'll do it manually.
> > 
> > However following the instructions here: 
> > 
> > https://www.qubes-os.org/doc/templates/debian/
> > 
> > namely: 
> > 
> > [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
> > 
> > I get "Nothing to do. Complete"
> > 
> > qvm-ls reveals that debian-8 is absent.
> > 
> > Is this instruction out of date or do I need to enable something first? Any 
> > tips appreciated.
> 
> The template re-install is currently broken, and requires fixing in a future 
> patch. I've had/seen mixed results with the plain template install too 
> (rather than re-install), so I suspect it's at least partly broken too? 
> Either way it's not you, this is something that likely needs patch fixing. 
> Possibly you can re-install Qubes and hope debian installs (sometimes work?, 
> see below), or you could try move debian from one of your 3.2. backup 
> archives, and then update it in Qubes 4 (hope for the best that the 3.2. 
> template Qubes tools won't get in the way). 
> 
> Also, in my own experience, I've installed Qubes 4 RC-2 on now 4-5 different 
> hardware machines, including various different CPU architecturs, from the 
> Intel i5 line, Intel M line, and Ryzen 3 1200. I've experienced different 
> results. 
> 
> For example, I never got debian working on my Intel i5 or Intel M 
> architectures, but for what seems like a paradoxial twist of fate, my Ryzen 
> architecture installs all templates perfectly fine, including debian-8. 
> Everything just work here. 
> 
> But on my Intel i5 or M processers, all which support minimum Qubes 4 specs 
> btw, and HVM works just fine, however debian-8 just doesn't work. 
> 
> I've had mixed results with Whonix-ws and Whonix-gw on the Intel 
> architectures too, however fedora worked mostly on all systems.
> 
> Frankly I do not know if its caused by different CPU archtectures, however, 
> from what I anecdotally experienced, it seems like what made the difference. 
> 
> Also if you encounter python errors during the very last stage of Qubes 4 
> install, immediately reinstall, no second thoughts. Apparently this happens 
> for no easy to observe reason too, but I'm able to make the last stage Qubes 
> configuration work properly by re-installing a few times, try different 
> settings, mess and push the system a little around, trial and error. 
> Eventually I got a clean install, with no last stage python errors. I do not 
> know exactly what made it work, or what caused it, except trial and error, 
> and trying different install settings, seemed to work.
> 
> Also seen install and system stability outcomes between legacy BIOS and UEFI, 
> however I did not test it extensively, nor can I confirm if it truly is so. 
> It's just something I took slight notice of, and in my case, legacy BIOS 
> seemed to fix my Ryzen system, which now runs Qubes templates flawlessly, 
> except for the missing CPU features in this kernel, but at least it works.
> 
> Hopefully you can use any of this, but as said, nothing conclusive. But 
> merely some experience and observation from many Qubes 4 RC-2 installs, on 
> various different hardware systems.

Thanks for the detailed reply. I have an i7 machine, installing to a USB stick. 
Strangely, last time I tried (this is my second installation on the same USB 
having borked the first) debian-8 *did* install so it's obviously a very quirky 
bug. Whonix installed OK although it seems very slow (everything, not just Tor 
browser). I don't see this issue reported on Github. Is it worth reporting or 
are Axon, Marek et al aware?  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/872ab2ea-1d27-450a-90ac-239ed538b78c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Debian template 4.0rc2

On Saturday, November 11, 2017 at 12:23:28 PM UTC, JPL wrote:
> For some reason the debian template didn't install when I installed Qubes, 
> even though I selected it. No matter I thought, I'll do it manually.
> 
> However following the instructions here: 
> 
> https://www.qubes-os.org/doc/templates/debian/
> 
> namely: 
> 
> [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8
> 
> I get "Nothing to do. Complete"
> 
> qvm-ls reveals that debian-8 is absent.
> 
> Is this instruction out of date or do I need to enable something first? Any 
> tips appreciated.

The template re-install is currently broken, and requires fixing in a future 
patch. I've had/seen mixed results with the plain template install too (rather 
than re-install), so I suspect it's at least partly broken too? Either way it's 
not you, this is something that likely needs patch fixing. Possibly you can 
re-install Qubes and hope debian installs (sometimes work?, see below), or you 
could try move debian from one of your 3.2. backup archives, and then update it 
in Qubes 4 (hope for the best that the 3.2. template Qubes tools won't get in 
the way). 

Also, in my own experience, I've installed Qubes 4 RC-2 on now 4-5 different 
hardware machines, including various different CPU architecturs, from the Intel 
i5 line, Intel M line, and Ryzen 3 1200. I've experienced different results. 

For example, I never got debian working on my Intel i5 or Intel M 
architectures, but for what seems like a paradoxial twist of fate, my Ryzen 
architecture installs all templates perfectly fine, including debian-8. 
Everything just work here. 

But on my Intel i5 or M processers, all which support minimum Qubes 4 specs 
btw, and HVM works just fine, however debian-8 just doesn't work. 

I've had mixed results with Whonix-ws and Whonix-gw on the Intel architectures 
too, however fedora worked mostly on all systems.

Frankly I do not know if its caused by different CPU archtectures, however, 
from what I anecdotally experienced, it seems like what made the difference. 

Also if you encounter python errors during the very last stage of Qubes 4 
install, immediately reinstall, no second thoughts. Apparently this happens for 
no easy to observe reason too, but I'm able to make the last stage Qubes 
configuration work properly by re-installing a few times, try different 
settings, mess and push the system a little around, trial and error. Eventually 
I got a clean install, with no last stage python errors. I do not know exactly 
what made it work, or what caused it, except trial and error, and trying 
different install settings, seemed to work.

Also seen install and system stability outcomes between legacy BIOS and UEFI, 
however I did not test it extensively, nor can I confirm if it truly is so. 
It's just something I took slight notice of, and in my case, legacy BIOS seemed 
to fix my Ryzen system, which now runs Qubes templates flawlessly, except for 
the missing CPU features in this kernel, but at least it works.

Hopefully you can use any of this, but as said, nothing conclusive. But merely 
some experience and observation from many Qubes 4 RC-2 installs, on various 
different hardware systems.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b3069a5-4002-493e-8aa5-57c60823c6ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes & Quantum decryption Immunity


On 11/10/2017 05:51 PM, taii...@gmx.com wrote:
In this case you should ask the luks/dmcrypt mailinglist as that is 
what qubes uses for disk crypto.




Would be simpler off the bat to limit discussion to asymmetric crypto, 
as that is the type thought to be vulnerable to qc. LUKS/dmcrypt and 
most other disk encryption uses symmetric crypto.


I believe qvm-backup crypto is also symmetric (although IIRC it may have 
specific security issues that need to be addressed).


Finally, there is anti-evil-maid; I think it uses symmetric but not certain.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bd59baee-8a77-bf2e-20eb-c30965a0f3ad%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: 4.0 rc1 firewall failed stderr cannot execute qrexec-daeomn

2017-11-11 Thread David Hobach

On 11/11/2017 12:52 AM, Stumpy wrote:

On 10.11.2017 17:45, David Hobach wrote:

On 11/10/2017 05:41 PM, David Hobach wrote:

Your point about sys-net not working might very well be part of it
as it seems to start sometimes and not others, though the firewall
isn't starting 100% of the time.

There's a few issues wrt the qubes firewall open on github. The
funny/bad thing about it being that if it doesn't start, it'll
default to "Allow all"... x_X

That's present in 4.0rc2 at least.

Correction:
Just noticed that you were probably talking about the sys-firewall VM.
I was talking about the qubes-firewall service running in
sys-firewall.

Well it seems that reinstalling didn't help. I tried w/o creating the
whonix or usb sys templates, i didn't try the "advanced" option as I was
not sure how to make templates and wasn't s motivated as to go that
path. I did try the qvm-start route and wasn't able to start
any of them, even when sys-net was up.
A bit of a pity as I was looking forward to tinkering with it... and
"learning how to stop worrying and love" Qubes w/o a VM Manager, I kinda
liked the manager ;)

Check the other threads on the topic (there were a couple about VMs not
starting recently).

qvm-prefs sys-firewall virt_mode pv

Ah well, will try later to upload (somehow) the journalctl outpt.

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/0a708222-ce48-dc78-93d5-47c2a0256d00%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Re: R4 rc2: Multiple EFI Machines Install Failures

On Saturday, November 11, 2017 at 9:44:33 AM UTC, Eric Duncan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I'm having a difficult time attempting an EFI install of 
> Qubes-R4.0-rc2-x86_64.iso across 4 different machines and 3 different USB 
> sticks made by various procedures.
> 
> * Installing to an Asmedia USB3 device (all systems detect as HDD)
> * Must use EFI installation
> 
> On all of the following, I have used 3 different USB sticks made by various 
> procedures (Rufus in Windows on a USB2, dd in OSX and Etcher in OSX on two 
> USB3 sticks).  Also, I downloaded the ISO 3 different times and verified its 
> PGP signature each time.  All USB sticks act exactly the same, except for on 
> my Lenovo Helix: the Helix doesn't have proper EFI init that I've experienced 
> with other installations.
> 
> I am attempting to install Qubes on an M.2 SSD via an Asmedia USB3 enclosure 
> from all of the machines below.  This has worked flawless for Windows 10, 
> Ubuntu 16.04 and ArchLinux installations as it is detected as a HDD.
> 
> 
> Macbook Pro Retina mid-2014
> - --
> I get the first initial boot menu, asking to install with testing.
> 
> Selecting any option flashes the Xen boot for a microsecond, and returns back 
> to the menu.
> 
> 
> iMac 27" 5k late-2015
> - --
> Upon selecting Test installation media and install, it shows the Xen EFI boot 
> - and freezes the system right there.  IOW, one more step than the Macbook 
> Pro 2014.
> 
> 
> Lenovo Helix (1st gen)
> - --
> I already have Qubes R3.2 on this device.
> 
> The installer is not recognized from any of the Qubes 4.0 rc2 USB sticks 
> under EFI.
> 
> It shows and loads under Legacy; but, I require it to be EFI for the various 
> machines I'll be booting in going forward (namely, some UP boards that only 
> have EFI bios options).
> 
> 
> (Desktop) Asus Rampage IV Black Edition
> - --
> Saved the best for last.  And by "best" meaning the most inconsistent issues. 
>  This is my high end gaming desktop, dual Titans, overclocked, water cooled, 
> etc.
> 
> For the record, I have been running Windows 8.1, 10 and Arch Linux for the 
> past 4 years on this system (mostly Arch) with about 20 test installations 
> over and over using several high end devices.  I know this system very well, 
> and is extremely stable under Linux kernel as well as Windows with zero 
> instability.  Though, I have never tried FreeBSD kernels before.
> 
> I get various results using the same USB stick over and over.  I have removed 
> all overclocking with various results.  "Various" results meaning I cannot 
> reproduce the same error or condition all of the time.
> 
> Most common result:
> 
> When Anaconda starts, it flashes a graphic background with a "Progress" bar 
> that slowly moves across the bottom for about 30s - and freezes the entire 
> system, forcing a power off with power button 4s.
> 
> This screen does not show under normal installation.
> 
> Serious bug in the Installer:
> 
> Whenever the system freezes from one of the various issues, most of the time 
> it marks the USB3 device as "Dirty" - before it even gets to any installation 
> screen!  Worse off, it does this to my Arch and Ubuntu installs on the local 
> SSDs!  I've since disconnected the internal HDDs, but it still marks dirty 
> the USB3 I am installing to.  I usually have to remove it, and format it in 
> another machine, between installation attempts.
> 
> Occasional Progress:
> 
> Sometimes, the system will get past the Xen and Anaconda init and actually 
> load the Installation menu!  Where it asks for options for installing, 
> encrypt disk, and starts installing!
> 
> But when it gets to this point, which I have only made it to twice, it has 
> hard locked the system with the progress bar pretty close to the end running 
> some script.  I didn't write the script name down, but I will next time.
> 
> 
> If anyone has any advice, please let me know.  If Qubes 4.0 RTM will have a 
> lot of installer fixes, I may just wait for that.
> 
> Thanks!
> Eric
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAloGxlsACgkQ1HXhRIZm
> 5iYKaRAAxTE64Fua+TmnkbRfM3lwl+5lz9N2FHYMDCkwbv7wE6TKbR2Z5KgYdN+n
> SfgA7pBhEj5m317nC1MfzbFuZyHuwBlWsIfqnWxzs1n9Xjy7l5miu052mhEG5Wlw
> QyWYaPBBegd5bkrYH+I/4IEwOqKWVzE77qhrgSrfscAQhwXdH4mgU7J7PfdI8HZH
> NpjShlXelER9zBiUB1Huw9vcL3SM0b7cnI/qY5s5FyMb8OjPDYAmAEzaXWEUyIvQ
> V5AmZrv9cS2IyQ/PklSQsL4J1zNkSLv9z/OZuEyZY2tvBMFzqdJGlAAbmmB1vmIO
> RV8tRWlOhi+Qu0DR4xHN90ERLYIAZ6NZ1EC80pYKlcHPIyQW6fMBfn2IRlGxUs1X
> Zm8ox14b0oTmVPhDc0pjjuLNcxzHhzFpeA9Iav+OBF5MJRHVNOxKTUEnaFN8DTlw
> LymeuLFtBmlUptxGtgCgpaJ7jhaZh68WYWYLVINsr6apd/Oo+iHYU0evFr7qeMjX
> S+yM8H34/pah2qdPtrHrizwb0xDVSrcXnih4bF0113aX8rBEF7mJaFY0wrsWDaA1
> 5gCVzUMxZFbtvn1BRnGjaAX/+givCk5TjhLYPrleXqSSvS6fPeZlH5SBba+mmaLd
> TejeduMh5j3nIvjTOYDnPLOF4uOSRlqbGdpqQXzZGUFzVt8SRLw=
> =T0FM
> -END PGP SIGNATURE-

btw, in addition to the above, I assume you possibly can only have three

[qubes-users] Installing Debian template 4.0rc2

For some reason the debian template didn't install when I installed Qubes, even 
though I selected it. No matter I thought, I'll do it manually.

However following the instructions here: 

https://www.qubes-os.org/doc/templates/debian/

namely: 

[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8

I get "Nothing to do. Complete"

qvm-ls reveals that debian-8 is absent.

Is this instruction out of date or do I need to enable something first? Any 
tips appreciated.

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

[qubes-users] Re: R4 rc2: Multiple EFI Machines Install Failures

On Saturday, November 11, 2017 at 9:44:33 AM UTC, Eric Duncan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I'm having a difficult time attempting an EFI install of 
> Qubes-R4.0-rc2-x86_64.iso across 4 different machines and 3 different USB 
> sticks made by various procedures.
> 
> * Installing to an Asmedia USB3 device (all systems detect as HDD)
> * Must use EFI installation
> 
> On all of the following, I have used 3 different USB sticks made by various 
> procedures (Rufus in Windows on a USB2, dd in OSX and Etcher in OSX on two 
> USB3 sticks).  Also, I downloaded the ISO 3 different times and verified its 
> PGP signature each time.  All USB sticks act exactly the same, except for on 
> my Lenovo Helix: the Helix doesn't have proper EFI init that I've experienced 
> with other installations.
> 
> I am attempting to install Qubes on an M.2 SSD via an Asmedia USB3 enclosure 
> from all of the machines below.  This has worked flawless for Windows 10, 
> Ubuntu 16.04 and ArchLinux installations as it is detected as a HDD.
> 
> 
> Macbook Pro Retina mid-2014
> - --
> I get the first initial boot menu, asking to install with testing.
> 
> Selecting any option flashes the Xen boot for a microsecond, and returns back 
> to the menu.
> 
> 
> iMac 27" 5k late-2015
> - --
> Upon selecting Test installation media and install, it shows the Xen EFI boot 
> - and freezes the system right there.  IOW, one more step than the Macbook 
> Pro 2014.
> 
> 
> Lenovo Helix (1st gen)
> - --
> I already have Qubes R3.2 on this device.
> 
> The installer is not recognized from any of the Qubes 4.0 rc2 USB sticks 
> under EFI.
> 
> It shows and loads under Legacy; but, I require it to be EFI for the various 
> machines I'll be booting in going forward (namely, some UP boards that only 
> have EFI bios options).
> 
> 
> (Desktop) Asus Rampage IV Black Edition
> - --
> Saved the best for last.  And by "best" meaning the most inconsistent issues. 
>  This is my high end gaming desktop, dual Titans, overclocked, water cooled, 
> etc.
> 
> For the record, I have been running Windows 8.1, 10 and Arch Linux for the 
> past 4 years on this system (mostly Arch) with about 20 test installations 
> over and over using several high end devices.  I know this system very well, 
> and is extremely stable under Linux kernel as well as Windows with zero 
> instability.  Though, I have never tried FreeBSD kernels before.
> 
> I get various results using the same USB stick over and over.  I have removed 
> all overclocking with various results.  "Various" results meaning I cannot 
> reproduce the same error or condition all of the time.
> 
> Most common result:
> 
> When Anaconda starts, it flashes a graphic background with a "Progress" bar 
> that slowly moves across the bottom for about 30s - and freezes the entire 
> system, forcing a power off with power button 4s.
> 
> This screen does not show under normal installation.
> 
> Serious bug in the Installer:
> 
> Whenever the system freezes from one of the various issues, most of the time 
> it marks the USB3 device as "Dirty" - before it even gets to any installation 
> screen!  Worse off, it does this to my Arch and Ubuntu installs on the local 
> SSDs!  I've since disconnected the internal HDDs, but it still marks dirty 
> the USB3 I am installing to.  I usually have to remove it, and format it in 
> another machine, between installation attempts.
> 
> Occasional Progress:
> 
> Sometimes, the system will get past the Xen and Anaconda init and actually 
> load the Installation menu!  Where it asks for options for installing, 
> encrypt disk, and starts installing!
> 
> But when it gets to this point, which I have only made it to twice, it has 
> hard locked the system with the progress bar pretty close to the end running 
> some script.  I didn't write the script name down, but I will next time.
> 
> 
> If anyone has any advice, please let me know.  If Qubes 4.0 RTM will have a 
> lot of installer fixes, I may just wait for that.
> 
> Thanks!
> Eric
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAloGxlsACgkQ1HXhRIZm
> 5iYKaRAAxTE64Fua+TmnkbRfM3lwl+5lz9N2FHYMDCkwbv7wE6TKbR2Z5KgYdN+n
> SfgA7pBhEj5m317nC1MfzbFuZyHuwBlWsIfqnWxzs1n9Xjy7l5miu052mhEG5Wlw
> QyWYaPBBegd5bkrYH+I/4IEwOqKWVzE77qhrgSrfscAQhwXdH4mgU7J7PfdI8HZH
> NpjShlXelER9zBiUB1Huw9vcL3SM0b7cnI/qY5s5FyMb8OjPDYAmAEzaXWEUyIvQ
> V5AmZrv9cS2IyQ/PklSQsL4J1zNkSLv9z/OZuEyZY2tvBMFzqdJGlAAbmmB1vmIO
> RV8tRWlOhi+Qu0DR4xHN90ERLYIAZ6NZ1EC80pYKlcHPIyQW6fMBfn2IRlGxUs1X
> Zm8ox14b0oTmVPhDc0pjjuLNcxzHhzFpeA9Iav+OBF5MJRHVNOxKTUEnaFN8DTlw
> LymeuLFtBmlUptxGtgCgpaJ7jhaZh68WYWYLVINsr6apd/Oo+iHYU0evFr7qeMjX
> S+yM8H34/pah2qdPtrHrizwb0xDVSrcXnih4bF0113aX8rBEF7mJaFY0wrsWDaA1
> 5gCVzUMxZFbtvn1BRnGjaAX/+givCk5TjhLYPrleXqSSvS6fPeZlH5SBba+mmaLd
> TejeduMh5j3nIvjTOYDnPLOF4uOSRlqbGdpqQXzZGUFzVt8SRLw=
> =T0FM
> -END PGP SIGNATURE-

I believe, without certainty, however within reasonable amount, that

Re: [qubes-users] /var/log excessive filesystem usage

On 11/10/2017 05:57 PM, taii...@gmx.com wrote:

On 09/26/2017 03:56 AM, Alex wrote:

On 09/26/2017 09:44 AM,taii...@gmx.com wrote:

Update: deleting the contents of /var/log, /tmp and /var/tmp caused my
system to be unbootable which is silly as these are not meant to be
permanent locations

I received errors about qmemmman not being able to write a file, to
which I had to revert the changes and re-create it's directory to render
the system bootable again.

That's very strange - not the fact that qmemman does not work if you
remove its log directory, but the size on disk.

I've had this R3.2 installation since october 2016, and my /tmp has 4KB
worth of data, /var/tmp 20KB and the biggest is /var/log with 1.8GB.

But inside /var/log the biggest directory is journald/, that takes 99%
of the space, while qubes/ takes only 3.2 MB - the second biggest
directory being xen/ at 8.3MB.

To check directory size I used "du", with a line like this:
/var/log# du --max=1 -h

Please check settings in /etc/systemd/journald.conf to make sure
journald only logs what you need (and, in my case, does not discard what
it thinks I don't need).

Thanks, I don't normally use systemd on my other computers

You can also run 'journalctl' to prune the logs. That's what I've done
since Fedora doesn't come with a sensible default setting.

Another reason to hate systemd.
Systemd linux takes 1min+ to boot vs 15 seconds on devuan's plane jane
SysVinit (redhat only created systemd to run a hostile takeover of the
linux community
... you must be new to Linux. :) Redhat has long exercised undue
influence over Linux development. When "desktop Linux" was a trend over
a decade ago, they threw their weight around in that arena too.
Unfortunately the community is stupid enough to let an unabashed
server-only company determine the direction of desktop development.

OTOH, going back to init instead of fostering one of the alternatives
has exposed a regressive streak in the community. Sysvinit sucked eggs
for use cases involving power management (sleep/wake/etc), peripheral
hotplug, anything where the system had to enter different global states.
It probably still does suck and somehow I can't believe that devuan is
thoroughly testing for PC use cases (doubt they even recognize 'use
case' as a development concept); On my last survey, no one except
Canonical does this.

The tragedy here is that Ubuntu tried to address the issue reasonably in
their usual fashion (follow Apple's lead) and Redhat and their neckbeard
camp said "No". Over the years: No apt, No Mir, No upstart, No
addressing desktop security bug reports, No repo signing on Fedora
(can't compete with RHEL on update security!), No certification of
PCs... They'll wait 7-10 years until their boys get around to doing it
over. Redhat are the Knights Who Say NIH (Not Invented Here). Now
Canonical is taking their business and they are flailing about.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/537740c4-d943-8f3e-0a8c-1e2c1c21efda%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Does VT-d protect against this?

On Saturday, November 11, 2017 at 3:49:53 AM UTC, tai...@gmx.com wrote:
> VT-d, intel's crappy IOMMU doesn't protect you from ME by design.
> There is no disabling ME contrary to what some companies might say - 
> me_cleaner simply nerfs it.
> 
> If you want a PC without black box supervisor processors here are your 
> open source firmware options:
> Ultra high performance:
> TALOS 2 (POWER 9, so no qubes ATM unless you compile it yourself) - 
> price is appropriate for high end server hardware (for the same 
> performance x86-64 would cost more)
> Will be RYF upon release
> 
> Performance:
> KGPE-D16
> KCMA-D8
> Can play games in a VM via IOMMU-GFX, with the best CPU's equal to FX-8310.
> They support OpenBMC for open source remote management.
> I use these and they're great.
> 
> Laptop:
> Lenovo G505S (needs blob for video/power management, but can be replaced 
> with free code as there is no hardware code signing enforcement 
> anti-features)
> Novena (needs blob for 3D video accel)

The sheer fact that there are no massive uprisings against this, is simply 
astonishing on its own. It is so invasive into human rights and people's right 
to freedom, privacy and free speech. Not to mention to risk it poses towards 
the future of our democracies, or making dictatorships significantly worse than 
they are today. 

In the name of terror, lets slowly erode and destroy democracy and all its 
values, bit by bit, year by year, until it collapses.
Sounds like a good deal, lets keep this facde up that it's needed to fight 
terrorism, it's definitely going to end well.

How on earth are these people getting away these crimes against humanity? It's 
truly mindblowing. 

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

Re: [qubes-users] Qubes & Quantum decryption Immunity

On Friday, November 10, 2017 at 10:29:48 PM UTC, Sandy Harris wrote:
> On Fri, Nov 10, 2017 at 1:45 PM, Yuraeitha  wrote:
> 
> > Either way, cryptography protected by "structure", should be safe against a 
> > quantum computer, no? while all encryption without structure, would be 
> > extremely vulnerable to quantum computers?
> 
> I am not sure what you mean by "structure" in this context. If any of
> my guesses are correct, then I do not think that is the issue.
> 
> > Basically, long story short, is Qubes at risk in the near future of real 
> > quantum computing decryption attacks? For example, has there already gone 
> > thoughts or even development into securing Qubes against type of attacks 
> > like these?
> 
> I'm on several crypto mailing lists & follow the field fairly closely,
> though I would not claim to understand everything I read, let alone
> everything going on. As far as I can see, more-or-less everyone in the
> field agrees quantum computers are a serious threat in the long term,
> but no-one is much worried about threats in the next few years. Of
> course they could be wrong; neither AI researchers nor Go players
> thought a program that could win against top human players would turn
> up for decades, but then Google produced Alpha Go which did just that.
> A real paranoid would worry about whether some government lab already
> had a quantum computer capable of breaking a lot of crypto; my guess
> is that is not a realistic fear, but who knows?
> 
> The most worrisome threat is that a large enough (a few thousand
> q-bits) quantum machine breaks RSA public key encryption. RSA relies
> on sufficiently large semi-primes (products of two primes) being hard
> to factor. See https://en.wikipedia.org/wiki/Integer_factorization for
> background. There are about a dozen known methods for finding the
> factors, but on classical computers none that are efficient in the
> general case. On a quantum computer, though, there is a known
> efficient algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm
> so a big enough quantum machine breaks RSA.
> 
> That is a huge threat since RSA is very widely used. PGP, IPsec,
> Secure DNS, SSL & SSH (or at least most variants) all fall if RSA
> does. There are other public key methods that might replace RSA, but
> it is not clear they are safe either.

My bad, I made an important typo in the text above with the word 
possible/impossible, first two lines in second paragraph.  

"SO, by structure, I mean, what if the labyrinth is full of closed doors, where 
you need to solve puzzles that are possible to solve with numbers?"

Should be, 

"So, by structure, I mean, what if the labyrinth is full of closed doors, where 
you need to solve puzzles that are impossible to solve with numbers to get past 
it?"

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

Re: [qubes-users] Qubes & Quantum decryption Immunity

@ Sandy Harris
On Friday, November 10, 2017 at 10:29:48 PM UTC, Sandy Harris wrote:
> On Fri, Nov 10, 2017 at 1:45 PM, Yuraeitha  wrote:
> 
> > Either way, cryptography protected by "structure", should be safe against a 
> > quantum computer, no? while all encryption without structure, would be 
> > extremely vulnerable to quantum computers?
> 
> I am not sure what you mean by "structure" in this context. If any of
> my guesses are correct, then I do not think that is the issue.
> 
> > Basically, long story short, is Qubes at risk in the near future of real 
> > quantum computing decryption attacks? For example, has there already gone 
> > thoughts or even development into securing Qubes against type of attacks 
> > like these?
> 
> I'm on several crypto mailing lists & follow the field fairly closely,
> though I would not claim to understand everything I read, let alone
> everything going on. As far as I can see, more-or-less everyone in the
> field agrees quantum computers are a serious threat in the long term,
> but no-one is much worried about threats in the next few years. Of
> course they could be wrong; neither AI researchers nor Go players
> thought a program that could win against top human players would turn
> up for decades, but then Google produced Alpha Go which did just that.
> A real paranoid would worry about whether some government lab already
> had a quantum computer capable of breaking a lot of crypto; my guess
> is that is not a realistic fear, but who knows?
> 
> The most worrisome threat is that a large enough (a few thousand
> q-bits) quantum machine breaks RSA public key encryption. RSA relies
> on sufficiently large semi-primes (products of two primes) being hard
> to factor. See https://en.wikipedia.org/wiki/Integer_factorization for
> background. There are about a dozen known methods for finding the
> factors, but on classical computers none that are efficient in the
> general case. On a quantum computer, though, there is a known
> efficient algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm
> so a big enough quantum machine breaks RSA.
> 
> That is a huge threat since RSA is very widely used. PGP, IPsec,
> Secure DNS, SSL & SSH (or at least most variants) all fall if RSA
> does. There are other public key methods that might replace RSA, but
> it is not clear they are safe either.

Let me try rephrase the structure part, I may not have understood it correctly, 
and I can tell you know more than I do about encryption, so let me try emphasis 
the quantum part, which may or may not be right. I'm curious whether or how it 
can fit into encryption, so this is kind of a thought experiment. The logic in 
this analogy I'm sure you already know, but I want to use the analogy's 
conclusion to make a point afterwards, so here goes. Using a massive labyrinth 
analogy to solve a decryption calculation, a traditional classic computer can 
only seek one path at a time (1/0 on/off transistor logic), and if it's a dead 
end, it has to return to try another path, each turn, or dead end, being a 
calculated 1/0 state of information. A quantum computer can do many or even all 
paths at once in a single calculation instant, with having multiple or 
exponentially many states between 1/0, thereby following multiple of paths, 
resulting in a lot of dead ends, but at the same time discovering the single 
path out of the massive labyrinth, all in a few or a single calculation, 
depending on how many qubits the quantum computer has available. 

It's a bit simplified, but enough to make the analogy point. SO, by structure, 
I mean, what if the labyrinth is full of closed doors, where you need to solve 
puzzles that are possible to solve with numbers? But instead use something like 
human thought logic pattern? This would require either a human or a 
sophisticated A.I. to solve, but it's also more akin to that of a traditional 
computer, patterns, structures, based in many 1/0 forming a structure, and the 
answer can only be found if maintaining this structure all at once. A quantum 
computer cannot do that, right? If I understood it correctly, a quantum 
computer may be truly scary in its insane calculative power, but, it's by no 
means capable of being "smart", at the very least, not on its own. 

Where my knowledge of how encryption works, truly falls apart, is regarding the 
need of near-perfect or the not reached difficult to archive, perfect entropy. 
The more entropy, or chaos without structure and order, the harder it becomes 
to predict anything, and the harder it becomes to crack an encryption. This 
much is correctly understood I assume? So, if putting in roadbloacks for the 
quantum computer, which it cannot calculate, it significantly slows down it's 
quantum speed. Even if introducing a classic computer or A.I. to work together 
with the quantum computer, if the road blocks are difficult enough, it would 
overall slow down the quantum computer enough to make it

[qubes-users] R4 rc2: Multiple EFI Machines Install Failures

2017-11-11 Thread Eric Duncan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm having a difficult time attempting an EFI install of 
Qubes-R4.0-rc2-x86_64.iso across 4 different machines and 3 different USB 
sticks made by various procedures.

* Installing to an Asmedia USB3 device (all systems detect as HDD)
* Must use EFI installation

On all of the following, I have used 3 different USB sticks made by various 
procedures (Rufus in Windows on a USB2, dd in OSX and Etcher in OSX on two USB3 
sticks).  Also, I downloaded the ISO 3 different times and verified its PGP 
signature each time.  All USB sticks act exactly the same, except for on my 
Lenovo Helix: the Helix doesn't have proper EFI init that I've experienced with 
other installations.

I am attempting to install Qubes on an M.2 SSD via an Asmedia USB3 enclosure 
from all of the machines below.  This has worked flawless for Windows 10, 
Ubuntu 16.04 and ArchLinux installations as it is detected as a HDD.


Macbook Pro Retina mid-2014
- --
I get the first initial boot menu, asking to install with testing.

Selecting any option flashes the Xen boot for a microsecond, and returns back 
to the menu.


iMac 27" 5k late-2015
- --
Upon selecting Test installation media and install, it shows the Xen EFI boot - 
and freezes the system right there.  IOW, one more step than the Macbook Pro 
2014.


Lenovo Helix (1st gen)
- --
I already have Qubes R3.2 on this device.

The installer is not recognized from any of the Qubes 4.0 rc2 USB sticks under 
EFI.

It shows and loads under Legacy; but, I require it to be EFI for the various 
machines I'll be booting in going forward (namely, some UP boards that only 
have EFI bios options).


(Desktop) Asus Rampage IV Black Edition
- --
Saved the best for last.  And by "best" meaning the most inconsistent issues.  
This is my high end gaming desktop, dual Titans, overclocked, water cooled, etc.

For the record, I have been running Windows 8.1, 10 and Arch Linux for the past 
4 years on this system (mostly Arch) with about 20 test installations over and 
over using several high end devices.  I know this system very well, and is 
extremely stable under Linux kernel as well as Windows with zero instability.  
Though, I have never tried FreeBSD kernels before.

I get various results using the same USB stick over and over.  I have removed 
all overclocking with various results.  "Various" results meaning I cannot 
reproduce the same error or condition all of the time.

Most common result:

When Anaconda starts, it flashes a graphic background with a "Progress" bar 
that slowly moves across the bottom for about 30s - and freezes the entire 
system, forcing a power off with power button 4s.

This screen does not show under normal installation.

Serious bug in the Installer:

Whenever the system freezes from one of the various issues, most of the time it 
marks the USB3 device as "Dirty" - before it even gets to any installation 
screen!  Worse off, it does this to my Arch and Ubuntu installs on the local 
SSDs!  I've since disconnected the internal HDDs, but it still marks dirty the 
USB3 I am installing to.  I usually have to remove it, and format it in another 
machine, between installation attempts.

Occasional Progress:

Sometimes, the system will get past the Xen and Anaconda init and actually load 
the Installation menu!  Where it asks for options for installing, encrypt disk, 
and starts installing!

But when it gets to this point, which I have only made it to twice, it has hard 
locked the system with the progress bar pretty close to the end running some 
script.  I didn't write the script name down, but I will next time.


If anyone has any advice, please let me know.  If Qubes 4.0 RTM will have a lot 
of installer fixes, I may just wait for that.

Thanks!
Eric
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEcy6ry51h71BXa58r1HXhRIZm5iYFAloGxlsACgkQ1HXhRIZm
5iYKaRAAxTE64Fua+TmnkbRfM3lwl+5lz9N2FHYMDCkwbv7wE6TKbR2Z5KgYdN+n
SfgA7pBhEj5m317nC1MfzbFuZyHuwBlWsIfqnWxzs1n9Xjy7l5miu052mhEG5Wlw
QyWYaPBBegd5bkrYH+I/4IEwOqKWVzE77qhrgSrfscAQhwXdH4mgU7J7PfdI8HZH
NpjShlXelER9zBiUB1Huw9vcL3SM0b7cnI/qY5s5FyMb8OjPDYAmAEzaXWEUyIvQ
V5AmZrv9cS2IyQ/PklSQsL4J1zNkSLv9z/OZuEyZY2tvBMFzqdJGlAAbmmB1vmIO
RV8tRWlOhi+Qu0DR4xHN90ERLYIAZ6NZ1EC80pYKlcHPIyQW6fMBfn2IRlGxUs1X
Zm8ox14b0oTmVPhDc0pjjuLNcxzHhzFpeA9Iav+OBF5MJRHVNOxKTUEnaFN8DTlw
LymeuLFtBmlUptxGtgCgpaJ7jhaZh68WYWYLVINsr6apd/Oo+iHYU0evFr7qeMjX
S+yM8H34/pah2qdPtrHrizwb0xDVSrcXnih4bF0113aX8rBEF7mJaFY0wrsWDaA1
5gCVzUMxZFbtvn1BRnGjaAX/+givCk5TjhLYPrleXqSSvS6fPeZlH5SBba+mmaLd
TejeduMh5j3nIvjTOYDnPLOF4uOSRlqbGdpqQXzZGUFzVt8SRLw=
=T0FM
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit

[qubes-users] Re: IP Redirection to localhost in AppVM