[qubes-users] Re: USB Keyboard no longer reachable following recent update

[Alex Dubois]

On Saturday, 12 January 2019 12:52:29 UTC, Alex Dubois  wrote:
> Hi,
> 
> Did a qubes-dom0-update + fedora template update last night. Reboot this 
> morning and I can't reach the USB keyboard anymore.
> 
> I can't remember if I had removed my sys-usb VM after I got bitten recently 
> and fixed the situation following this 
> https://github.com/QubesOS/qubes-issues/issues/2270.
> 
> Following the explanation there I could boot and use the USB keyboard from my 
> fedora on USB-key:
> I did not have any entry with  rd.qubes.hide_all_usb in xen-4.x.x.config
> And I did not have a file 
> /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service.
> 
> Any hint appreciated.
> 
> I am using Qubes as my home firewall and the entire house is disconnected 
> (can't reconnect easily as I have VLans all over the place, dns server on 
> QubesOS, etc...).

Had to edit out from grub.cfg rd.qubes.hide_all_usb entries to be able to enter 
the LUKS password

-- 
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/e0ea7822-6b25-4956-b508-154a1e70b038%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] USB Keyboard no longer reachable following recent update

[Alex Dubois]

Hi,

Did a qubes-dom0-update + fedora template update last night. Reboot this 
morning and I can't reach the USB keyboard anymore.

I can't remember if I had removed my sys-usb VM after I got bitten recently and 
fixed the situation following this 
https://github.com/QubesOS/qubes-issues/issues/2270.

Following the explanation there I could boot and use the USB keyboard from my 
fedora on USB-key:
I did not have any entry with  rd.qubes.hide_all_usb in xen-4.x.x.config
And I did not have a file 
/etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service.

Any hint appreciated.

I am using Qubes as my home firewall and the entire house is disconnected 
(can't reconnect easily as I have VLans all over the place, dns server on 
QubesOS, etc...).

-- 
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/aa317785-af08-4a3c-ac52-fdf3f11cd066%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Ubuntu server mininal 16.04 quick install guide for Qubes r4

[Alex Dubois]

Hi,

This guide is to install an Ubuntu VM, not a template.

I had few little issues with the install so here is how I did it, this may save 
some time to others in the future.

1 - create HVM image (documented here https://www.qubes-os.org/doc/hvm/)

Note that I configured 800MB for the memory. You may be able to find smaller 
value but 400MB was causing some kernel module to fail to load (probably as 
memory balancing doesn't work)

qvm-create my-new-vm --class StandaloneVM --property virt_mode=hvm --property 
kernel='' --label=green --property memory=800

2 - boot the VM (same doc page)

qvm-start hyperledger --cdrom=disp1234:/home/user/Download/ubuntu-server.iso

3 - Install Ubuntu

F4 to use the minimal mode

when you reach networking config, the firewall is not very chatty obviously so 
it probably does not answer a ping, or whatever test ubuntu installer is doing. 
Selected manual to set-up IP/mask (getting info via qubes-manager).

I had to leave the default gateway blank for the install to be able to continue.
This can be fixed latter after reboot by editing /etc/network/interfaces and 
adding below broacast: gateway 10.137.x.x

DNS can be set:10.139.1.1 10.139.1.2

you don't need to set a domain name (unless you know you do for your specific 
set-up)

Disk partition, I selected guided LVM on the first disk (OS).
Second disk is for private image (leveraged when you use template).

You can leave the http proxy blank (again unless you know you have have, and I 
hope you did not put it in the firewallVM as this is a bad practice by the way).

I selected auto install of security updates

Enjoy Qubes-OS.

Alex




-- 
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/6bc33e40-6691-4bc5-9b11-0e068459a03b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach <trip...@hackingthe.net> wrote:
> 
> On 03/13/2018 07:14 AM, Alex Dubois wrote:
>>> On 12 Mar 2018, at 18:40, David Hobach <trip...@hackingthe.net> wrote:
>>> 
>>>> On 03/11/2018 03:15 PM, David Hobach wrote:
>>>> An alternative might be to setup the local DNS service in a VM closer to 
>>>> the Internet, i.e. not in the proxy VM which also implements the qubes 
>>>> firewall.
>>>> Something like
>>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>>>> qubes-fw <-- client VM
>>>> I didn't test that though.
>>> 
>>> I just tested that as well now and it works as expected without any of the 
>>> aforementioned caveats.
>>> 
>>> So I'd recommend the one above over the previously discussed
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>>> (at least I was talking about that architecture - maybe the others were 
>>> talking about something different...).
>>> The same holds true for VPN users.
>> This type of architecture is bad practice as the attack surface of DNS is 
>> bigger than Qubes firewall, and an attack on this daemon compromise all 
>> traffic, not just DNS.
>> A better arch is
>> Internet
>> - netVM
>> - - firewallVM
>> - - - Service (ie DNS or VPN)
>> - - - clientVM1
>> - - - clientVM2
> 
> I believe your essential point was not to use proxy VMs for services at all.
> 
> My main point was not to mix a Qubes Firewall VM with local services. I think 
> you basically agree with that.

Yes agree

> 
> I however also disagree with your point wrt proxy VM usage as there's no 
> attack vector for E2E encrypted traffic on proxy VMs except for DoS which 
> you'll notice.

Let’s agree to disagree;). This is possibly true client to VPN, but the attack 
surface VPN to internetVPN is not small, there are a substantial number of line 
of code for the support of various protocols, with negotiation phases, parsing 
of data stream into such control flow. (I.e. some of the long list of OpenSSL 
vuln lead to remote code exec I suspect). 
So my point is you can use proxy if all the clients are going to use the VPN. 
And this apply also only if all the traffic would flow through the service (VPN 
use case OK, dns or http proxy not OK).

> If you're using non-E2E encrypted traffic (except for maybe DNS) you have a 
> different problem altogether and even then I'd trust my proxy VM a lot more 
> than any other hop (your Wifi provider? the 4+ backbone providers you pass?) 
> on the route to the destination.
I may have misunderstood you, but this is outside the subject of the discussion 
or please clarify. 

> 
> Moreover it is rather inconvenient to configure each and every client VM to 
> use that service VM which can also lead to unexpected misconfigurations & 
> leakages.
I agree that it is less trivial to setup but you lower your attack surface 
significantly.

So I agree that it depends on the circumstances, but I think my statement is 
preferable as a general rule, and I think Qubes should move toward supporting 
such setup, making it easier to configure. 

Best Regards
Alex
> 

-- 
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/14B0F388-B653-4981-A8B6-D0901E3B5B18%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 12 Mar 2018, at 18:40, David Hobach  wrote:
> 
>> On 03/11/2018 03:15 PM, David Hobach wrote:
>> An alternative might be to setup the local DNS service in a VM closer to the 
>> Internet, i.e. not in the proxy VM which also implements the qubes firewall.
>> Something like
>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>> qubes-fw <-- client VM
>> I didn't test that though.
> 
> I just tested that as well now and it works as expected without any of the 
> aforementioned caveats.
> 
> So I'd recommend the one above over the previously discussed
> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
> (at least I was talking about that architecture - maybe the others were 
> talking about something different...).
> The same holds true for VPN users.

This type of architecture is bad practice as the attack surface of DNS is 
bigger than Qubes firewall, and an attack on this daemon compromise all 
traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2

And firewallVM intercept the traffic for the VM that needs it.
Note that a service can also be a client for another service.
Note2 that does not mean that the arch should be flat, if you are worried that 
a mis conf of firewallVM could put you at risk you could do
Internet
- NetVM
- - FirewallVM
- - - FirewallVPN
- - - - clientVPNVM
- - - - vpmServiceVM
- - - firewallDNS
- - - - clientDNSVM
- - - - dnsServiceVM
- - - firewallWebServer
- - - - ReverseProxyAuthVMservice
- - - - - webServerVMservice
- - - - - - webDMserviceVM
- - - - ClientWebVM

> 
> I also documented this at https://github.com/QubesOS/qubes-issues/issues/3051
> 

-- 
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/C3D0CBC3-8C5A-4BB5-B866-866E9B3144D9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 11 Mar 2018, at 10:21, Chris Laprise <tas...@posteo.net> wrote:
> 
>> On 03/10/2018 04:43 PM, Alex Dubois wrote:
>>> On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
>>> ‐‐‐ Original Message ‐‐‐
>>> 
>>>> On March 8, 2018 11:26 AM, Chris Laprise <t...@p...o.net> wrote:
>>>> 
>>>> ​​
>>>> 
>>>>>>> \> \[1\] https://dnsprivacy.org/wiki/
>>>> 
>>>>>>>> \[2\] https://www.qubes-os.org/doc/networking/
>>>> 
>>>> Micah,
>>>> 
>>>> If you have any specific instructions on how to setup the forwarder
>>>> 
>>>> you're using, I'd be happy to try it myself and post a solution for use
>>>> 
>>>> with qubes-firewall.
>>>> 
>>>> I found the dnsprivacy wiki to be a bit scattered and not very specific.
>>>> 
>>>> Their video "tutorial" is really a lecture on the concept.
>>> 
>>> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
>>> -- I'm traveling right now and haven't spent a lot of time on it, and might 
>>> not for the next week or two. But once I figure it out I'd like to write a 
>>> blog post or something with instructions. But maybe I should sent it to 
>>> this list first for people to test and give feedback.
>> For your info, I have a wiki on how to use dns-crypt here: 
>> https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
>> It is supposed to be exposed via blog.bowabos.com but github changed 
>> something and the static site does not get automatically generated at the 
>> moment...
> 
> Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and 
> unbound.
> 
> One problem is that the howto assumes particular Qubes 10.137.2.x and 
> 10.138.2.x nets for unbound.

Yes I need to rewrite it for Qubes 4.

The other blog post on Atlassian stack also needs a rewrite and I have now a 
better network topology (more secure) for it. Time is my problem

> 
> Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all share 
> the same IP address. This isn't explained in the Qubes networking or firewall 
> docs, so it may be a bug...
> 
> To keep unbound.service from failing I changed unbound.conf to this:
> 
>> interface: 
>> access-control: 10.137.0.0/24 allow
>> harden-large-queries: yes
>> private-address: 10.0.0.0/8
>> private-address: 192.168.0.0/16
>> val-permissive-mode: yes
>> do-not-query-localhost: no
> 
> ...and for now omitted the '-d' destination part in iptables.
> 
> Then if I issue:
> 
>> sudo iptables -t nat -F PR-QBS
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
>> $eth0_address
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
>> $eth0_address
> 
> it appears to work from a downstream appVM. But I haven't checked yet to see 
> if its really using the dnscrypt proxy; even if it is, the config may need to 
> be adjusted for better security.
> 
> -- 
> 
> 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/8ECF3140-FD4B-400C-AB7D-A459F74327AC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
> ‐‐‐ Original Message ‐‐‐
> 
> On March 8, 2018 11:26 AM, Chris Laprise  wrote:
> 
> > ​​
> > 
> > >>>\> \[1\] https://dnsprivacy.org/wiki/
> > 
> > > > > > \[2\] https://www.qubes-os.org/doc/networking/
> > 
> > Micah,
> > 
> > If you have any specific instructions on how to setup the forwarder
> > 
> > you're using, I'd be happy to try it myself and post a solution for use
> > 
> > with qubes-firewall.
> > 
> > I found the dnsprivacy wiki to be a bit scattered and not very specific.
> > 
> > Their video "tutorial" is really a lecture on the concept.
> 
> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
> -- I'm traveling right now and haven't spent a lot of time on it, and might 
> not for the next week or two. But once I figure it out I'd like to write a 
> blog post or something with instructions. But maybe I should sent it to this 
> list first for people to test and give feedback.

For your info, I have a wiki on how to use dns-crypt here: 
https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
It is supposed to be exposed via blog.bowabos.com but github changed something 
and the static site does not get automatically generated at the moment...

-- 
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/11825052-26fe-48a8-bd08-7da3f15b7787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 8 Mar 2018, at 13:50, awokd <aw...@danwin1210.me> wrote:
> 
> On Thu, March 8, 2018 1:16 pm, Alex Dubois wrote:
> 
> I think the indentation got broken, this is you, right?

Ouch yes might have been I had a problem with my mail client. 

> 
>>> True but if the content is not accepted in Qubes... you may still want
>>> to have it in Qubes Community.
>>> 
>>> An example is a page on setting up a vnc connection for remote admin to
>>> dom0... some user would want that, also you break a big part of the
>>> Qubes security. Qubes will not accept such a doc (I hope). It would
>>> reside in the Qubes-community doc in a section “at your own risk”, with
>>> a warning on the security risk and maybe a link to the PR discussion
>>> with Qubes as to why it was rejected. Now Qubes 4.4 for example comes
>>> along and they have a way to provide such service, we would be able to
>>> PR in Qubes after modifications.
>>> 
>>> 
>>> But I also see you point with a blank repo, it is clear and less prone
>>> to mistakes.
>>> 
>>> Not sure but personally I prefer to just work on the fork. It will be
>>> more often useful and less copy pasting when submitting PR from one
>>> repo to the other (ie multiple pages updates in one PR)
>>> 
>>> For new docs, it has the advantage to also implicitly help selecting
>>> the right place to host the info.
>>> 
>>> The empty one will either be a mess or will have to be organised as
>>> well (with the additional burden that it also has to be aware of
>>> Qubes-doc)
>>> 
>>> 
>>> You can fork Qubes-community/Qubes-doc and do whatever you want (and
>>> others can access it (and know you forked) also not the reason so you
>>> could have a link to your fork in a in-progress section of Qubes
>>> community)
>>> 
>>> I am naturally fairly organised and have experience of very large
>>> projects where I left sometimes too much flexibility and ended up with
>>> a mess 3 years later. So this is why I’m not keen on blank areas. But
>>> this is a community project, so I am also very interested in the human
>>> interaction factor and respectful of others opinions.
>>> 
>>> If I have not convinced you and awokd, I don’t see a big problem in
>>> having both.
> 
> Yes, that's part of that "magic" step I wasn't sure how to address. I'll
> defer to your experience on it. My hope is the wiki will make it easy for
> people to contribute too without worrying about PRs and all that, but I'm
> not sure how much admin overhead's going to be involved.
> 
I don’t have much experience with GitHub, a bit more with git. 

True the wiki may address it. 

The best is probably to test it. 

I am snowed under at work at the moment. So maybe test between you on one of 
your existing projects and then we can discuss. 


-- 
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/2D1D604A-E974-455D-9B42-ADEC79AB9A90%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 8 Mar 2018, at 07:57, Alex Dubois <bowa...@gmail.com> wrote:
> 
> 
> 
> Sent from my mobile phone.
> 
>> On 7 Mar 2018, at 18:48, [799] <one7tw...@gmail.com> wrote:
>> 
>> Hello Alex,
>> 
>>> On 03/07 07:57, Alex Dubois wrote:
>>> 
>>> From my part if I want let say to add a script to clean-up the logs in 
>>> Dom0...
>>> 1- I will agree with the others where in the official doc we think it 
>>> should go (in an issue) and possibly how to do it, w$
>>> 2- Once consensus I raise the issue in Qubes official so they can provide 
>>> feedback
>>> 3- In parallel I work on the issue in community repo by either using GitHub 
>>> web UI to edit the script and raise a PR, or b$
>>> 4- PR is reviewed by community
>>> 5- PR approuve and change merged (maybe a header is added saying under 
>>> review for integration in Qubes doc)
>>> 6- submit PR in main Qubes-doc
>>> 7- if PR rejected, I will update the community page with a header included 
>>> saying this is a community only page.
>>> 
>>>> Thereof the risk is lower that someone doesn't know where to publish 
>>>> changes.
>>>> the qubes-doc should be seen as the production area documentation while 
>>>> qubes-community-doc is something like a preprodu$
>> 
>> as far as I have understand thebenefitwould be, that the discussion 
>> always starts (!)in the production qubes-doc.
>> Then the actualcoding/discussion/happening in the Qubes-Community doc.   
>>   
>> If "mature" a Pull Request is raised toupload the doc to qubes-doc, 
>> correct?
>> 
>> Wouldn't it be good to remove the content from the community-doc then, so 
>> that it really only serves as a staging repositorr$
> 
> True but if the content is not accepted in Qubes... you may still want to 
> have it in Qubes Community.
> 
> An example is a page on setting up a vnc connection for remote admin to 
> dom0... some user would want that, also you break a big part of the Qubes 
> security. Qubes will not accept such a doc (I hope). It would reside in the 
> Qubes-community doc in a section “at your own risk”, with a warning on the 
> security risk and maybe a link to the PR discussion with Qubes as to why it 
> was rejected. 
> Now Qubes 4.4 for example comes along and they have a way to provide such 
> service, we would be able to PR in Qubes after modifications.
> 
> But I also see you point with a blank repo, it is clear and less prone to 
> mistakes.
> 
> Not sure but personally I prefer to just work on the fork. It will be more 
> often useful and less copy pasting when submitting PR from one repo to the 
> other (ie multiple pages updates in one PR)
> 
> For new docs, it has the advantage to also implicitly help selecting the 
> right place to host the info.
> 
> The empty one will either be a mess or will have to be organised as well 
> (with the additional burden that it also has to be aware of Qubes-doc)
> 
> You can fork Qubes-community/Qubes-doc and do whatever you want (and others 
> can access it (and know you forked) also not the reason so you could have a 
> link to your fork in a in-progress section of Qubes community)
> 
> I am naturally fairly organised and have experience of very large projects 
> where I left sometimes too much flexibility and ended up with a mess 3 years 
> later. So this is why I’m not keen on blank areas. But this is a community 
> project, so I am also very interested in the human interaction factor and 
> respectful of others opinions.
> 
> If I have not convinced you and awokd, I don’t see a big problem in having 
> both.
>> 
>> [799]
>> 

-- 
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/178C3F4D-61B1-4642-B5AA-CD44D25891E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 6 Mar 2018, at 01:28, Andrew David Wong <a...@qubes-os.org> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-05 16:28, Alex Dubois wrote:
>>> On 5 Mar 2018, at 21:07, 799 <one7tw...@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>>>>> On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just 
>>>>>> create a new "community" repo where Pull request get 
>>>>>> reviewed by us but finally approved by more experienced 
>>>>>> Power Users (this group can include Qubes OS Team, but also
>>>>>> experienced community members selected by the Qubes 
>>>>>> Team/David)?
>>>>> 
>>>>> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote: I
>>>>> wouldn't mind helping out on reviews on something like this,
>>>>> as well as contributing my own half-baked ideas.
>>>> 
>>>> On 5 March 2018 at 08:57, Alex Dubois <bowa...@gmail.com> 
>>>> wrote: True we could have sandbox per person, or each person 
>>>> fork (the fork) and we have a page with list of forks Once idea
>>>> is ready, do a PR to the community fork...
>>>> 
>>>> This is the spirit of git
>>> 
>>> can't we just start to fork qubes-doc to qubes-community-doc and
>>> start there. If we think we need to rearrange the content or get
>>> rid of it, because it just doesn't make sense, we can still do 
>>> so.
>>> 
>>> In the main qubes-doc repository it seems that some skilled users
>>> are able to approve Pull Requests, I don't know enough about
>>> github how this works? Are those special permissions for trusted
>>> users or can it be anyone? I would like to see Andrew David Wong
>>> or marmarek as power users supporting this - by at least maybe
>>> giving feedback. If there are any other skilled persons which are
>>> happy to gibr feedback to improve the scripts which are collected
>>> there, this is even better - just mentioned those two as they
>>> were super helpfull when I wrote my first Qubes Docs hey, ho -
>>> let's go.
>> 
>> Give David a bit of time. His schedule might be busy, he may need 
>> to sync with a number of other persons, they may discuss what’s 
>> best. There is no rush. He is doing a great work as community 
>> manager.
>> 
> 
> Thanks. :}
> 
> Currently, qubes-doc PRs have to be approved by a member of the Qubes
> team before being merged into the master branch, which is the live
> version. (Usually, I'm the one who does the merge. In those cases, if
> you don't see explicit approval from another member of the team, it
> just means that I'm the one who has reviewed and approved the PR.)
> This system is great for maintaining high standards of security (as a
> first priority) and quality (as a second priority) for the docs.
> However, it's very time-consuming, since (at least) one of us has to
> review every single PR that gets merged (as well as many of those that
> ultimately get rejected, which are a small minority).
> 
> Currently, we barely have enough time to keep up with the stream of
> PRs that get submitted to qubes-doc, so it's very unlikely that we'd
> also have time to review or provide substantive feedback on PRs for a
> second, community-run version of qubes-doc that receives even more PRs
> (if I'm understanding the proposal correctly).
> 
> However, I do like the sound of a fully-community-run version that
> serves to collaboratively improve content before it is submitted to
> qubes-doc. Currently, most contributors just submit their work
> directly to qubes-doc, and the quality tends to vary. Perhaps the
> community-run version could be an optional (but recommended,
> especially for first-time contributors) place where work is polished
> up with feedback from the community before it's submitted as a PR to
> qubes-doc to be reviewed by the team. This could make things easier
> for contributors, improve the quality of the docs, and save the team's
> time.
> 
> 
> P.S. - You can call me "Andrew." "David" is my middle name. :)

Oups apologies for some reason David did stick in my mind.

OK let’s starts.

2 options,

-1-
It is a new repo in QubesOS project and:
- github allows the QubesOS team to manage with sufficient level of granularity 
the access so community team does not have access to main part (but this is 
error prone from an admin point of view as well as github vuln)
- Qubes team has the resources

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 21:42, awokd <aw...@danwin1210.me> wrote:
> 
>> On Mon, March 5, 2018 9:07 pm, 799 wrote:
>> Hello,
>> 
>> 
>>>>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>>>>> 
>>>>> Can't we just create a new "community" repo where Pull request get
>>>>> reviewed by us but finally approved by more experienced Power Users
>>> (this
>>> 
>>>>> group can include Qubes OS Team, but also experienced community
>>>>> members selected by the Qubes Team/David)?
>>>> 
>>>> On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>>>> I wouldn't mind helping out on reviews on something like this, as well
>>>> as contributing my own half-baked ideas.
>>> 
>>> On 5 March 2018 at 08:57, Alex Dubois <bowa...@gmail.com> wrote:
>>> True we could have sandbox per person, or each person fork (the fork)
>>> and we have a page with list of forks Once idea is ready, do a PR to the
>>> community fork...
>>> 
>>> This is the spirit of git
>>> 
>>> 
>> 
>> can't we just start to fork qubes-doc to qubes-community-doc and start
>> there. If we think we need to rearrange the content or get rid of it,
>> because it just doesn't make sense, we can still do so.
> 
> I was picturing an empty repo with relaxed editing requirements (can
> Github do this?) for new content only. Think forking existing might be
> confusing short and long term. :)

I provided my input earlier on this in case you missed it. What others think?

> 
>> In the main qubes-doc repository it seems that some skilled users are
>> able to approve Pull Requests, I don't know enough about github how this
>> works? Are those special permissions for trusted users or can it be
>> anyone?
> 
> In the official repo, I believe only Andrew and marmarek (and probably
> other Qubes members) can merge. This responsibility should stay with
> official Qubes reps. due to the sensitivity. However, there are some
> (Whonix, template maintainers) who might also authoritatively review
> related commits.
> 
>> I would like to see Andrew David Wong or marmarek as power users
>> supporting this - by at least maybe giving feedback.
> 
> adw's stated elsewhere they are happy with a community run site but
> wouldn't have the resources to support it.
> 
>> If there are any
>> other skilled persons which are happy to gibr feedback to improve the
>> scripts which are collected there, this is even better - just mentioned
>> those two as they were super helpfull when I wrote my first Qubes Docs
> 
> 
> 

-- 
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/AE67729B-1060-4551-9D45-B2BE24B2687A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 21:07, 799 <one7tw...@gmail.com> wrote:
> 
> Hello,
> 
>> >> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>> >> Can't we just create a new "community" repo where Pull request get
>> >> reviewed by us but finally approved by more experienced Power Users (this
>> >> group can include Qubes OS Team, but also experienced community members
>> >> selected by the Qubes Team/David)?
>> >
>> > On 4 Mar 2018, at 21:44, awokd <aw...@danwin1210.me> wrote:
>> > I wouldn't mind helping out on reviews on something like this, as well as
>> > contributing my own half-baked ideas.
>> 
>> On 5 March 2018 at 08:57, Alex Dubois <bowa...@gmail.com> wrote:
>> True we could have sandbox per person, or each person fork (the fork) and we 
>> have a page with list of forks
>> Once idea is ready, do a PR to the community fork...
>> 
>> This is the spirit of git
> 
> can't we just start to fork qubes-doc to qubes-community-doc and start there.
> If we think we need to rearrange the content or get rid of it, because it 
> just doesn't make sense, we can still do so.
> 
> In the main qubes-doc repository it seems that some skilled users are able to 
> approve Pull Requests, I don't know enough about github how this works?
> Are those special permissions for trusted users or can it be anyone?
> I would like to see Andrew David Wong or marmarek as power users supporting 
> this - by at least maybe giving feedback. If there are any other skilled 
> persons which are happy to gibr feedback to improve the scripts which are 
> collected there, this is even better - just mentioned those two as they were 
> super helpfull when I wrote my first Qubes Docs
> hey, ho - let's go.

Give David a bit of time. His schedule might be busy, he may need to sync with 
a number of other persons, they may discuss what’s best. There is no rush. He 
is doing a great work as community manager. 

In the mean time, I certainly don’t want to break your enthusiasm, anybody who 
wants can fork the Qubes-doc to work on his bits and once things are decided 
either raise issues and PR either to main Qubes OS or the community one.

We can discuss here ideas and agree on the way to proceed.

At the moment I am trying to help on the QWT as I think it essential for Qubes, 
most users have a leg in the windows world professionally.
After that, I would like to finish my Qubes-yubikey app
And finally do a proposal for a daemon-service (service+AppVM+firewall rules), 
as I feel a lot of users are compromising their system by doing the wrong thing 
(already mentioned I think)
Or work on Qubes-manager replacement but I have never done Linux client dev...

Maybe others can also share their plans...

> 
> [799]
>   
> 

-- 
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/1FE16220-B6F8-4F06-B1DE-E7718831615E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 5 Mar 2018, at 07:59, 799 <one7tw...@gmail.com> wrote:
> 
> Hello Alex,
> 
> 05.03.2018 8:28 "Alex Dubois" wrote:
> 
> I think it is important to keep it as a fork for few reasons:
> - most importantly we focus on helping the Qubes team 
> - if not it would be hard to clean-up what is in Qubes-doc, in the community 
> repo, and if the Qubes-doc get improved directly, it won’t be ported to 
> community, leading to not up to date info
> 
> Valid points, I agree.
> 
> However I think my suggestion is only to be taken with Qubes team validation.
> And if they feel it is not the best way and prefer the mailing lists and 
> existing infrastructure it is important to respect that and get back in line. 
> 
> I love the work of the Qubes Team, don't get to me wrong, but I don't 
> understand why and how they could block the community effort to create a fork?
> Some of use have already forked the docs and are currently developing their 
> own improved scripts.
> Doing so in a collaborative and centralized way would be much better.
> But - I would like to see of course - that Qubes Team is also supporting this 
> idea and knows about it.
Same
> One reason was also to indicate clearly which part of the documentation is 
> official and thereof reasonable secure and which is unofficial and maybe less 
> secure.
> I definitely like the idea of an index page / rating system.
> 
> too much resources discussing this, but rather contribute directly
> 
> Let's go, I am ready to start.
> @David (in his role of the community manager):
> What do you think?
> 
> I feel that a pair/trio need to be “responsible” per area or subject. With a 
> person helped by one or two for the overall. 
> 
> Yes, but we have already some interested people here, I think we only need to 
> discuss the approvement process and how and if of those ideas/scripts might 
> be placed more visible (maybe as a link) somewhere on the Qubes website which 
> is the main area for new users (?).
I agree

Approvement process should have:
- initial Issue exposing the idea and the work proposed = requirements (so that 
we collaboratively shape what will be done, how and by who)
- once this phase is done, a proper concise and precise issue can be raised to 
Qubes 
- work executed with a number of PR on Qubes-doc community (possible individual 
working on their own fork)
- PR approved by interested moderator
- once issue is felt resolved, submit PR to Qubes project (if issue was 
accepted by Qubes)

Some issues may fall outside of official doc (issue or PR get rejected). 
Moderator modify issue to store the result of the work in a community doc with 
the disclaimer you mention (for the one where the issue is accepted by Qubes 
team) we put a work in progress instead. 

> At least a link to it, with maybe a disclaimer:
> 
> "Take a look what is happening in the Qubes Community.
> 
> DISCLAIMER: the content there should be treated as work in progress and has 
> not been reviewed by the Qubes OS Team and maybe thereof less "reasonable 
> secure" or maybe even opening attack vectors to your Qubes installation.
> Even more if you implement a script which you haven't reviewed (and 
> understood) and which has not been marked as meeting the Qubes OS quality 
> standards.
> WARNING:
> If you implement changes in dom0 or the sys-VMs (sys-net, sys-firewall, 
> sys-usb) this might result in a total loss of security"
> 
> For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn 
> in line (I.e. sys-firewall). This is a bad practice as the attack surface of 
> one protocol is exposing the entier Qubes system. 
> A better way is to have these hosted on app-vm and have sys-firewall 
> intercepting and routing the traffic. 
> Even having sys-firewall doing the download rather than a dispvm is 
> increasing the attack surface (not sure if still the case)
> 
> This is a good example, is there a disclaimer or security rating on the 
> qubes-doc pages?

No that I am aware of, and this is were I slap myself on the wrist as I should 
have raised an issue or PR (but this may have wasted time from Qubes team) and 
this could be one of the issue we work collaboratively in the community repo 
shape and refine before sending upstream.

> 
> [799]

-- 
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/96D15406-2197-4284-94D3-DC5860E959C7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 4 Mar 2018, at 21:44, awokd  wrote:
> 
>> On Sun, March 4, 2018 8:04 pm, 799 wrote:
>> 
>> 
>> Can't we just create a new "community" repo where Pull request get
>> reviewed by us but finally approved by more experienced Power Users (this
>> group can include Qubes OS Team, but also experienced community members
>> selected by the Qubes Team/David)?
> 
> I wouldn't mind helping out on reviews on something like this, as well as
> contributing my own half-baked ideas.

True we could have sandbox per person, or each person fork (the fork) and we 
have a page with list of forks
Once idea is ready, do a PR to the community fork...

This is the spirit of git

> Can't really commit the time to be a
> forum moderator, but something like this 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/492AFBEE-BF3F-46E0-82CD-CE9D849B67E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

Sent from my mobile phone.

> On 4 Mar 2018, at 20:04, 799 <one7tw...@gmail.com> wrote:
> 
> Hello Alex,
> 
> 
> 2018-03-04 11:49 GMT+01:00 Alex Dubois <bowa...@gmail.com>:
>> 
>> I had some thought.
>> - Qubes team probably don't have the time to spread too thin, and would 
>> prefer for us to help them on there Qubes repo
>> - Some people invest time in documenting, but it takes time for Qubes team 
>> to validate the pull request, and sometime they may prefer to not accept the 
>> PR.
> 
> It is important to communicate why a pull request has not been approved.
> This communication takes some time and also fixing the issues

Yes agreed and the fork would be a good staging area/first pass

> 
>> I think one of these 2 options would be a first good step in the right 
>> direction:
>> - Qubes team provides a fork of qubes-doc in another project on which 
>> community members accept PR that can then be accepted as PR upstream on the 
>> official qubes-doc, qubes team only manage the access right for the PR (?)
>> - Someone is happy to put the effort to do option 1 and manage it (which 
>> should be limited to access right to that repo to trusted comminutity 
>> members to accept PR), as long as Qubes team agree with the approach
> 
> 
> I agree that this will be the easiest option and allows us to start 
> collecting scripts.
> I am unsure if we really need to fork the whole qubes-doc as this might lead 
> to confusion where to work when improving the existing documentation.

I think it is important to keep it as a fork for few reasons:
- most importantly we focus on helping the Qubes team 
- if not it would be hard to clean-up what is in Qubes-doc, in the community 
repo, and if the Qubes-doc get improved directly, it won’t be ported to 
community, leading to not up to date info

That does not prevent the fork from starting new areas of documentation.

I strongly feel that if it is not a fork we will dilute our contribution to the 
project. 

If David does not have the bandwidth to manage the access right, I feel awokd 
is a good candidate too. He acquired a good visibility of the overall doc.

However I think my suggestion is only to be taken with Qubes team validation.
And if they feel it is not the best way and prefer the mailing lists and 
existing infrastructure it is important to respect that and get back in line. 

It is also important to not spend too much resources discussing this, but 
rather contribute directly. 

> 
> Can't we just create a new "community" repo where Pull request get reviewed 
> by us but finally approved by more experienced Power Users (this group can 
> include Qubes OS Team, but also experienced community members selected by the 
> Qubes Team/David)?

I don’t have much experience in managing communities.

I feel that a pair/trio need to be “responsible” per area or subject. With a 
person helped by one or two for the overall. 



> 
>> I have one concern with such proposal. A number of community proposal are 
>> sometimes not very secure (to be gentle). So ideally a layer of meta-data is 
>> added (maybe on a single index page), with the rating of the doc page.
> 
> 
> Agree, it might feel frustrating in the beginning of you start contributing 
> docs and then find out that the "nice idea" that you had leads to several 
> security risks or is just not yet ready to be released.
> But: this is exactly the point what I like about Qubes. That I can rely that 
> it's not that easy to do something stupid which compromises security. 
> As such writing docs or scripts always include a learning curve which is a 
> good thing.

Yes and different people have different expectations.

But I think an index page rating the security level or enumerating the risks 
identified would be nice.

For example in the Qubes-doc, there are pages to put dns, http-proxy or vpn in 
line (I.e. sys-firewall). This is a bad practice as the attack surface of one 
protocol is exposing the entier Qubes system. 
A better way is to have these hosted on app-vm and have sys-firewall 
intercepting and routing the traffic. 
Even having sys-firewall doing the download rather than a dispvm is increasing 
the attack surface (not sure if still the case)

All these points are not criticism of Qubes, perfect security does not exist, 
but capturing them in a central place would be beneficial. That said, the most 
important thing is that I am at fault for doing this in an email rather than in 
a PR.
But this same PR done in the community staging area would give some bandwidth 
to Marek and co. 
However Marek may loose visibility on how things are going so David or awokd 
need to sync with him a summary. 
> 
> [799]
> 

-- 
You received this message because you are subscribed t

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

[Alex Dubois]

On Sunday, 4 March 2018 01:11:08 UTC, Yuraeitha  wrote:
> On Sunday, March 4, 2018 at 2:01:40 AM UTC+1, Yuraeitha wrote:
> > @[799]
> > Maybe we can do both and increase the overall value altogether? I'll 
> > understand if you don't think that is a good idea, but lets for a moment 
> > try see if a merged forum/github-wiki concept can work. We could make a 
> > sub-forum or even a whole forum section for GitHub account activity. Make a 
> > sticky post which is kept updated, with overview and introducing every 
> > GitHub content developers who are making unofficial work to Qubes. Then 
> > below that, everyone can post a detailed post for their GitHub page, 
> > listing and giving brief or detailed explanations of what it brings of 
> > value. Essentially it's possible to promote ones work here, so that others 
> > can find it. 
> > 
> > So overall, for example one forum section for guides on how to use and get 
> > into Qubes (i.e. new people to Qubes, and how to get started). Another 
> > section for work on scripts and guides with sub-forums, moving the 
> > scripts/guides over as they develop. And a final forum section to polish 
> > the scripts/guides to finish them. Then we can have a forum section for 
> > GitHub pages as described above, this way, people can choose the degree 
> > they want others to meddle in their work. For example GitHub while 
> > cooperative, doesn't tend to have others come in unless there is an open 
> > invitation there, or if the other party is rude. But on the forum here, 
> > it's an open invitation to come and work together on a project. This way 
> > one can preserve a form of individuality too, and invite others in 
> > naturally through the forum as a framework, if that is what is desired. The 
> > forum will then focus on both approaches, whether it's promoting/sharing 
> > work done on, or inviting on projects for work to-do.
> > 
> > As such people can choose the style they like. Also in addition to that, 
> > not everyone enjoys working in groups, but some enjoys working alone (and 
> > that should be respected, imo). For example it may fuel energy and be 
> > relaxing to work alone (it can even be a way of relaxing after a long day 
> > at work/similar), while in contrast it would be exhausting to work with 
> > others. Essentially the embodiment of being introvert and extrovert, both I 
> > think is completely normal and none is better than the other. People who 
> > gain energy working with others prefer a different work-style. Nothing 
> > wrong with it either, it's just how people gain energy, there is nothing 
> > bad about either of the two.
> > 
> > I think if we mix the approaches together, we can add value to both 
> > suggestions. It's also easier to have discussions for both groups, for 
> > example a forum for the copyright/law discussions on using other people 
> > work, so that we can be better informed on such matters. We can also 
> > highlight some kinds of works in various of different forums, wherever 
> > there is people willing to discuss or read, and all this can be closely 
> > tied to GitHub and GitHub Wiki's. What do you think of a merged approach?
> > 
> > 
> > 
> > 
> > 
> >   
> > @Andrew
> > On Saturday, March 3, 2018 at 6:25:08 AM UTC+1, Andrew David Wong wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > On 2018-03-02 23:16, Andrew David Wong wrote:
> > > > On 2018-03-02 15:05, Yuraeitha wrote:
> > > >> Some of the issues/questions addressed seems like they could be 
> > > >> solved quite effectively and efficiently on a highly
> > > >> customize-able forum?
> > > > 
> > > >> [...]
> > > > 
> > > >> Thoughts about using a forum?
> > > > 
> > > > FYI, in case you haven't seen this thread:
> > > > 
> > > > https://groups.google.com/d/topic/qubes-users/2rqas38ncFA/discussion
> > > >
> > >  
> > > While at it, here are some other old threads where similar ideas have
> > > been suggested:
> > > 
> > > https://groups.google.com/d/topic/qubes-users/D0YuoXMe_vE/discussion
> > > 
> > > https://groups.google.com/d/topic/qubes-users/es4q40dt1EE/discussion
> > > 
> > > Approximately every 6-12 months since the beginning of the project, a
> > > new person (including me, at one point, IIRC) suggests that there
> > > should be a Qubes wiki or forum, so you'll find many more threads like
> > > these if you search through the archives. :)
> > > 
> > > - -- 
> > > Andrew David Wong (Axon)
> > > Community Manager, Qubes OS
> > > https://www.qubes-os.org
> > > 
> > > -BEGIN PGP SIGNATURE-
> > > 
> > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqaMZcACgkQ203TvDlQ
> > > MDDD4xAAwbajnwJ/PZxzrVnmzKECGkYVQQDs90LieN1s/ewuqilNx9Cdxk8Fy9La
> > > jokevIemgSB/QjqRD1zl2L0ksn/XhsOgQyWyK+RCSNWdKsvDhJtsVvh0B5SA5t4N
> > > FrMzig0uUHLodl9ZOT9ltvy/nOnMBj8YcfQ2i+3yEaOFSN6hc7DkyXnPRhLbEdrK
> > > pwJJxbdAkvocSu6tEL1xE86cZ1CZrBIHvrVt1oCy1QPCr5EBNUukg4JMGOygZNi2
> > > 

Re: [qubes-users] Dom0 connectivity for maintenance

[Alex Dubois]

On Wednesday, 28 February 2018 17:59:09 UTC, awokd  wrote:
> On Wed, February 28, 2018 5:53 pm, Unman wrote:
> 
> >
> > By design dom0 has no networking.
> > If you MUST break Qubes , and you cant use the admin features in 4.0
> > (see my last post),then you'll have to use some service to pass data in
> > and out of dom0 WITHOUT networking.
> 
> Another option for remote access might be a TCP/IP based hardware KVM, or
> equivalent built in to your computer already like IPMI or DRAC. Obviously,
> Qubes can't provide any security beyond a screensaver password from an
> attack using those.

This could be useful: https://www.qubes-os.org/doc/safe-remote-ttys/

only tty...

-- 
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/8e73d22a-cd6d-4d86-9ddd-bb1740e09aaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4 and coreboot

[Alex Dubois]

On Thursday, 1 March 2018 07:30:29 UTC, Steven Sheffey  wrote:
> On Tuesday, February 27, 2018 at 3:42:07 PM UTC-6, qube...@go-bailey.com 
> wrote:
> > Do the Qubes devs recommend a specific payload to use with coreboot and 
> > Qubes 4?
> > 
> > For those who are using coreboot with the Qubes 4 release candidates, 
> > what payload are you using?
> > 
> > Have you run into any oddities with said payload detecting the install 
> > DVD or USB stick as well as with the subsequent installation?
> > 
> > I haven't been able to get coreboot with a petitboot payload working 
> > well with Qubes 4 thus far so am thinking of trying a different payload.
> > 
> > Thanks in advance.
> 
> I use Coreboot + SeaBIOS with Qubes 4, and it works perfectly on a Thinkpad 
> x230.

Any good how-to/doc you would recommend. I'm on a Lenovo T430 and might give 
coreboot a try...

-- 
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/4a0135a6-bf03-4fd1-88a0-91e9e2c57703%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

[Alex Dubois]

On Wednesday, 28 February 2018 17:41:06 UTC, thorsten...@gmail.com  wrote:
> > Could you try this:
> > qvm-prefs sys-firewall | grep netvm
> > it should say sys-net? Y/N
> 
> yes, result is sys-net
> 
> 
> > Even if it states sys-net, let's try to force it again
> > qvm-prefs sys-firewall -s netvm sys-net
> 
> that command did not work due to wrong syntax, so I did:
> 
> qvm-prefs --set sys-firewall netvm sys-net
> 
> If sys-firewall is shut down, the command works.
> If sys-firewall is running, the command fails with the error:
> "no such preoperty: 'netvm'", in addition if sys-firewall is running while I 
> do this, the eth0 interface is removed from sys-firewall.
> 
> 
> > and try the arp -an in sys-firewall again
> 
> Still the same result:
> ? (10.137.0.5) at  on eth0
> 
> Maybe I should try to look into the script(s) that are running when using 
> "qvm-prefs --set sys-firewall netvm sys-net"?

Yes good idea. I would need to do so too to be able to help now... I'm not 
familiar with this part.

-- 
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/19ea3dbe-7b8a-4a60-8935-e2f5f50be320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Wednesday, 28 February 2018 06:37:14 UTC, ThierryIT  wrote:
> Le samedi 24 février 2018 21:49:49 UTC+2, Alex Dubois a écrit :
> > On Wednesday, 21 February 2018 09:01:45 UTC, ThierryIT  wrote:
> > > Le mercredi 14 février 2018 09:49:37 UTC+2, ThierryIT a écrit :
> > > > Le dimanche 11 février 2018 10:08:52 UTC+2, ThierryIT a écrit :
> > > > > Le samedi 10 février 2018 22:58:15 UTC+2, Alex Dubois a écrit :
> > > > > > > On 10 Feb 2018, at 17:46, ThierryIT <v...@gmail.com> wrote:
> > > > > > > 
> > > > > > > Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
> > > > > > >> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> > > > > > >>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > > > > > >>>> Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a 
> > > > > > >>>> écrit :
> > > > > > >>>>>> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > > > > >>>>>> Not familiar with this ... Will need procediure to follow.
> > > > > > >>>>>> 
> > > > > > >>>>>> 
> > > > > > >>>>>> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a 
> > > > > > >>>>>> écrit :
> > > > > > >>>>>>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  
> > > > > > >>>>>>> wrote:
> > > > > > >>>>>>>> No, I am still under R3.2
> > > > > > >>>>>>>> 
> > > > > > >>>>>>>> Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > > > >>>>>>>>> On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > > >>>>>>>>>> "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > > > >>>>>>>>>> 
> > > > > > >>>>>>>>>> 
> > > > > > >>>>>>>>>> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a 
> > > > > > >>>>>>>>>> écrit :
> > > > > > >>>>>>>>>> 
> > > > > > >>>>>>>>>>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > > > >>>>>>>>>>> 
> > > > > > >>>>>>>>>>>> Nobody ?
> > > > > > >>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT 
> > > > > > >>>>>>>>>>>> a écrit :
> > > > > > >>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> Hi,
> > > > > > >>>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> I am going to install a new sys-usb.
> > > > > > >>>>>>>>>>>>> I have before to install all what I need to the 
> > > > > > >>>>>>>>>>>>> template (fedora-26)
> > > > > > >>>>>>>>>>>>> first. When following your procedure:
> > > > > > >>>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> 
> > > > > > >>>>>>>>>>>>> ykpers has been installed but: I cannot do the same 
> > > > > > >>>>>>>>>>>>> for
> > > > > > >>>>>>>>>>>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > > > >>&g

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

[Alex Dubois]

On Tuesday, 27 February 2018 23:48:27 UTC, thorsten...@gmail.com  wrote:
> A friend was using my PC and forgot to logout, so I accidently posted with 
> his account. So here it goes again:
> 
> > This is probably just because it tries to resolve the IPs and DNS times 
> > out. if you use netstat -nr, it should be fast.
> 
> Yes, using "netstat -nr" I get a result immediately in sys-firewall:
> 
> Destination Gateway Genmask Flags MSS Window irtt 
> Iface
> 0.0.0.0 10.137.0.5 0.0.0.0 UG 0 0 0 eth0
> 10.137.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 
> 
> > could you please do the arp -an after the ping 8.8.8.8
> 
> "arp -an" in sys-net displays:
> ? (192.168.0.2) at xx:xx:xx:xx:xx:xx [ether] on enp0s0
> 
> (xx:xx:xx:xx:xx:xx is a valid mac address, I just replaced the actual values 
> with X's)
> 
> 
> "arp -an" in sys-firewall displays:
> 
> ? (10.137.0.5) at  on eth0

Yes, so the problem is that you don't have connectivity between the 2 VMs.
Could you try this:
qvm-prefs sys-firewall | grep netvm
it should say sys-net? Y/N

Based on the info in the Qubes Firewall doc page
Even if it states sys-net, let's try to force it again
qvm-prefs sys-firewall -s netvm sys-net

and try the arp -an in sys-firewall again

-- 
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/38962d3b-4f42-4c6b-9759-7bfb974b4362%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 19:02:13 UTC, Ivan Mitev  wrote:
> On 02/09/18 20:56, Alex Dubois wrote:
> > On Friday, 9 February 2018 18:43:06 UTC, Ivan Mitev  wrote:
> >> On 02/09/18 20:23, Alex Dubois wrote:
> >>> On Friday, 9 February 2018 18:01:08 UTC, Ivan Mitev  wrote:
> >>>> On 02/09/18 19:37, Alex Dubois wrote:
> >>>>> On Friday, 9 February 2018 13:17:19 UTC, Alex Dubois  wrote:
> >>>>>> On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> >>>>>>> On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> After booting the win7 VM, the DVD get recognized.
> >>>>>>>> Windows is loading file progress bar is going smoothly
> >>>>>>>> But the win7 VM goes into halted or transient state just after 
> >>>>>>>> displaying the graphical splash screen Starting Windows
> >>>>>>>>
> >>>>>>>> At the moment I am exploring how to resolve this issue in R4 
> >>>>>>>> https://github.com/QubesOS/qubes-issues/issues/2488
> >>>>>>>>
> >>>>>>>> I've tried
> >>>>>>>> qvm-features win7 video-model cirrus
> >>>>>>>> but same problem
> >>>>>>>
> >>>>>>> Fixed.
> >>>>>>> The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> >>>>>>> qvm-prefs win7 memory 2048
> >>>>>>>
> >>>>>>> I'll update the doc.
> >>>>>>
> >>>>>> I have also tested that
> >>>>>> qvm-features win7 video-model cirrus
> >>>>>> is NOT required (in my case).
> >>>>>
> >>>>> I should test fully before saying things. It was required after the 
> >>>>> first reboot.
> >>>>>
> >>>>> This thread provide a comprehensive view 
> >>>>> https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94
> >>>>>
> >>>>
> >>>> FYI once the second part of the installation is complete and you have a
> >>>> working windows VM, you can revert the display adapter to standard vga
> >>>> (qvm-features --unset win7 video-model).
> >>>>
> >>>> Happy that the qubes-devel thread was useful :)
> >>>
> >>> Yes thanks a lot. I have now a working win7. Starting Windows-Tools 
> >>> install.
> >>
> >> I just did that :) - it works well... (but don't try to install the pv
> >> storage driver otherwise you'll get a BSOD).
> > 
> > Thanks for the warning ;-)
> > 
> > I can't find qubes-windows-tools
> > is it in testing branch?
> 
> Yes (in R3.2):
> 
> https://yum.qubes-os.org/r3.2/current-testing/dom0/fc23/rpm/qubes-windows-tools-3.2.2-3.x86_64.rpm
> 
> Extract with:
> 
> rpm2cpio qubes-windows-tools-3.2.2-3.x86_64.rpm | cpio -idmv
> 
> And start the VM (assuming the iso is in the 'untrusted' VM):
> 
> qvm-start --cdrom=untrusted:/home/user/qubes-windows-tools.iso win7

Would you know have to validate the rpm signature by any chance?

-- 
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/631e9154-8387-4c78-a803-6f42a4adb315%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: AW: Re: [qubes-users] Installing Chrome

[Alex Dubois]

On Tuesday, 27 February 2018 11:39:03 UTC, Yuraeitha  wrote:
> On Tuesday, February 27, 2018 at 3:06:36 AM UTC+1, brenda...@gmail.com wrote:
> > On Monday, February 26, 2018 at 7:21:11 PM UTC-5, [799] wrote:
> > > An 27. Feb. 2018, 00:59, Yuraeitha schrieb:
> > > > It is by no means a complete guide as you
> > > > make it sound though, it's relying overly much
> > > > on closed code, and Chromium is no good
> > > > here to look into Google Chrome. I wouldn't
> > > > call it the "go to" guide to get everything
> > > > working. 
> > > 
> > > Seriously? Do you know how much time it takes to write a how-to? To test 
> > > all
> > > steps and to use the feedback from other committed users to make it 
> > > better?
> > > And as mentioned the guide is written for a special use case, playing
> > > multimedia on Qubes as I wanted an OS which I can use for everything I'm 
> > > using
> > > a laptop for.
> > 
> > Hey, just wanted to say: thanks for the guide, it's great. :)
> > 
> > One of the strengths of Qubes is that you *can* divide your usage into 
> > compartments which have different compromises (both security-wise and 
> > philosophy-wise). A full-out "yes, we can Netflix and ... well, popcorn in 
> > this case" Qube and separately have a "open source intelligence research 
> > behind VPN and/or TOR" Qube or "develop sensitive open source application" 
> > Qube on the same machine, *and* worry less about cross contamination 
> > (security, software development ethics, identities, etc.) is just a big win.
> > 
> > Again: thanks! I am already using your guide and I appreciate all the work 
> > you and others put into it.
> > 
> > ...
> > > > The fact that Firefox isn't even mentioned in
> > > > that "between the lines self-proclaimed all
> > > > solution page guide", makes me a bit sad and
> > > > disappointed in Qubes. I hope this is a
> > > > mistake. 
> > > 
> > > Honestly it was me writing this "self-proclaimed all solution page guide"
> > > which took me lots of hours starting from the first version and following 
> > > the
> > > excellent feedback from other users to improve it.
> > > Maybe you should provide content instead of being sad that others try to
> > > contribute to the Qubes project?
> > 
> > Great idea! Maybe Yuraeitha can write up a "multimedia, most of it, with 
> > firefox" guide? I have seen Yuraeitha add useful information on other 
> > threads in this forum, appears to be very engaged and generally appears to 
> > mean well.
> > 
> > > Do you know how motivating it feels if people comment on your work like 
> > > you're
> > > doing?
> > 
> > I hope I have at least added some positive balance. :)
> > 
> > > If my how-to will convince one user to try out Qubes because he can even 
> > > do 
> > > the "evil closed source" stuff, I am happy.
> > 
> > :)
> > 
> > Brendan
> 
> I think you add positive balance Brendan, I like that you try to see both 
> parties views and seek to make peace. Although I did overstep and caused a 
> provocation, when I could have criticized without it becoming emotional. Even 
> if I did not do it intentionally, it's still something I need to take 
> responsibility for.
> 
> To which I really apologize for [799], I hope we can still see eye to eye. By 
> the way, even if I criticized your how-to doc here, there are two things that 
> soften the perceived written criticism (quite a lot actually), which I want 
> to underline. First the work you did is really good, I like what you did. 
> What I criticized is only a lack of work into open alternatives, and not the 
> work you did, which is good (which the criticism here takes a whole different 
> character when criticizing an institution/culture rather than a single 
> person). Adding a section to the how-to with minimum a brief mention of 
> privacy/open-source concerns could be a good quick solution as a disclaimer, 
> which would fend off this criticism even if you don't add open source 
> solutions. Second, I want to admit that I make mistakes too (which is 
> obvious, but the point here is that I'm admitting to it, in fact I make a lot 
> of mistakes). I'm not trying to belittle, be arrogant or feel superior (I 
> don't). It's just that my writing style can be very straight forward and it 
> can risk sounding harsh. Adding on-top of that, I can be pretty darned 
> merciless when it comes to challenging authority, which is not how I act 
> towards individual people. I believed in the moment of the writing that what 
> I challenged, did not have a face or emotions, but instead was a system, an 
> authority through institutionalization/culture. But it turned out the wrath I 
> put forward actually hit a person, which was not my intention at all. Shaking 
> things up can sometimes fix issues in institutions, but it's not a good 
> approach for individual people. I hope you will forgive me for being rude 
> towards you, I do feel bad about it... Especially when as a person a mistake 
> like this is very minor, 

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

[Alex Dubois]

On Tuesday, 27 February 2018 18:46:52 UTC, thorsten...@gmail.com  wrote:
> > Can you also try doing this against the template you're using for your 
> > sys-firewall?
> > 
> > qvm-features fedora-26-minimal qubes-firewall 1 
> 
> I did this and restarted everything, no difference.
> 
> 
> > Yes probably. For reference, to check (or enable):
> > - go to start menu/System Tools/Qube Manager
> > - right click sys-net/Qube Settings/Services tab
> > - clocksync should be in the list and ticked if not type clocksync and 
> > click on +
> > - I think a full reboot is required. There are probably ways to avoid it... 
> 
> clocksync is checked.
> 
> 
> > I am confused, did you do this in sys-net or sys-firewall. Because sys-net 
> > would have a default route and a route for your Lan. You may have tripped 
> > the info which is fine.
> 
> In fact I left the default routes away and just focused on the missing one.
> When I start sys-firewall a new network interface is added (vifx.0) where x 
> is a number.
> "ifconfig -a" displays:
> 
> vif3.0: flags=4098  mtu 1500
> (and also 2 default interfaces: enp0s0 and lo, which are both UP and RUNNING)
> 
> 
> I noticed here that "UP" / "RUNNING" is missing for the vif, therefore I have 
> to "up" it myself.
> This might be part of the problem, since it has to be running in order to add 
> a new route (which should be done automatically).
> So "route" in sys-net displays only the default routes:
> 
> Destination Gateway Genmask Flags Metric Ref Use 
> Iface
> default gateway 0.0.0.0 UG 100 0 0 enp0s0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0enp0s0
> 
> So if I add the route myself it additionally displays:
> 
> 10.137.0.6 0.0.0.0 255.255.255.255 U 100 0 0vif3.0
> 
> So far so good, the values in sys-net are looking "ok" to me now. Or am I 
> missing something?

Yes looks good.

> 
> 
> > on sys-firewall, you are probably going to need to ifconfig eth0 up and you 
> > should have something like this:
> > -bash-4.4# netstat -nr
> > Kernel IP routing table
> > Destination Gateway Genmask Flags   MSS Window  irtt 
> > Iface
> > 0.0.0.0 10.137.0.14  0.0.0.0 UG0 0  0 
> > eth0
> > 10.137.0.14  0.0.0.0 255.255.255.255 UH0 0  0 
> > eth0 
> 
> On sys-firewall eth0 and lo are UP and RUNNING, but "route" takes around 20 
> seconds to finish and displays:
> 
> Destination Gateway Genmask Flags Metric Ref Use 
> Iface
> default gateway 0.0.0.0 UG 0 0 0 eth0
> gateway 0.0.0.0 255.255.255.255 UH 0 0 0eth0
> 
> The long waiting time before "route" finishes makes me wonder...

This is probably just because it tries to resolve the IPs and DNS times out. if 
you use netstat -nr, it should be fast.

> 
> I deleted the default routes and recreated them. I also restarted the eth0 
> interface.
> 
> When I try to ping 8.8.8.8 from sys-firewall I get:
> 
> From 10.137.0.6 icmp_seq=1 Destination Host Unreachable
> From 10.137.0.6 icmp_seq=2 Destination Host Unreachable
> ...
> 
> 
> I also switched the templates of sys-net and sys-firewall to debian-9, but 
> the result is the same (vif down in sys-net, no route for vif).
> 
> The more I try to fix this, I get a feeling that the root of the problem lies 
> inside sys-net.

Or the "physical" link between sys-net and sys-firewall. I believe there is a 
doc page (or maybe a thread here) on how to reconnect after a disconnection.

could you please do the arp -an after the ping 8.8.8.8
If you have a MAC address for sys-net, then you have "wire" connectivity, 
otherwise, it is where the pb is.

> It seems like the vif in sys-net does not get "up", which breaks the 
> setup/initialization script (or maybe it breaks earlier, I don't know).
> 
> If I knew, which steps have to be done to set up network between a VM, 
> sys-firewall and sys-net correctly, I could try to pinpoint the problem 
> better.
> What happens exactly behind the scenes when sys-firewall starts and uses 
> sys-net as netVM?
> Also I was thinking if iptables might be involved here?!

-- 
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/23340a00-ae9a-4886-84e3-8906be13e949%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Clearing qubes-dom0-cached packages

[Alex Dubois]

On Tuesday, 27 February 2018 16:13:43 UTC, Yuraeitha  wrote:
> On Tuesday, February 27, 2018 at 4:45:45 PM UTC+1, Alex Dubois wrote:
> > On Tuesday, 27 February 2018 15:34:00 UTC, Alex Dubois  wrote:
> > > On Friday, 12 February 2016 22:08:05 UTC, m.3.7.31.127...@gmail.com  
> > > wrote:
> > > > I accidentally ran qubes-dom0-update qubes*testing and qubes downloaded 
> > > > testing packages. I didn't install them, and I don't want to. However, 
> > > > the packages are still cached and I have no way to update qubes now 
> > > > without installing the testing packages.
> > > > 
> > > > How can I clear the package cache?
> > > 
> > > Hi,
> > > 
> > > I had the exact problem in this thread. I wanted to check if my 
> > > qubes-dom0-update was broken or not. so enabled testing, which downloaded 
> > > packages, I let it finished but then did not install.
> > > 
> > > Searched the past threads and found this one.
> > > 
> > > Applied the --clean option
> > > Which seem to have done some things as I had now 5 packages that it 
> > > wanted to install.
> > > Which seems to confirm that qubes-dom0-update was stuck, also I am not 
> > > sure (or maybe these 5 packages were release during my experiment on the 
> > > current repo).
> > > 
> > > Is there a way in github to see the list of packages and the associated 
> > > commits for each repo?
> > 
> > Sorry it was 8 packages.
> > 
> > I have cleared both rpm and repodata, and with the clean option was offered 
> > to install these 8 packages. which I did.
> 
> Have you cleaned your templates too to keep them up-to-date and in sync with 
> dom0?

Good heads-up. Just did, and there was also 25 packages (6 of which on 
qubes-vm-r4.0-current).

I am not going to speculate at this point if Qubes OS team released some 
updates this afternoon or not.

-- 
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/20cc5724-956e-41cd-bd5b-e60d1107254e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Clearing qubes-dom0-cached packages

[Alex Dubois]

On Tuesday, 27 February 2018 15:34:00 UTC, Alex Dubois  wrote:
> On Friday, 12 February 2016 22:08:05 UTC, m.3.7.31.127...@gmail.com  wrote:
> > I accidentally ran qubes-dom0-update qubes*testing and qubes downloaded 
> > testing packages. I didn't install them, and I don't want to. However, the 
> > packages are still cached and I have no way to update qubes now without 
> > installing the testing packages.
> > 
> > How can I clear the package cache?
> 
> Hi,
> 
> I had the exact problem in this thread. I wanted to check if my 
> qubes-dom0-update was broken or not. so enabled testing, which downloaded 
> packages, I let it finished but then did not install.
> 
> Searched the past threads and found this one.
> 
> Applied the --clean option
> Which seem to have done some things as I had now 5 packages that it wanted to 
> install.
> Which seems to confirm that qubes-dom0-update was stuck, also I am not sure 
> (or maybe these 5 packages were release during my experiment on the current 
> repo).
> 
> Is there a way in github to see the list of packages and the associated 
> commits for each repo?

Sorry it was 8 packages.

I have cleared both rpm and repodata, and with the clean option was offered to 
install these 8 packages. which I did.

-- 
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/881cf787-4f3e-44de-8ca9-bc11f77ce0f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 rc4 / Qubes backup doesn't find the directory

[Alex Dubois]

On Tuesday, 27 February 2018 10:39:06 UTC, Yuraeitha  wrote:
> On Tuesday, February 27, 2018 at 7:00:46 AM UTC+1, ThierryIT wrote:
> > Le mardi 27 février 2018 02:50:05 UTC+2, Yuraeitha a écrit :
> > > On Monday, February 26, 2018 at 8:04:44 PM UTC+1, ThierryIT wrote:
> > > > Hi,
> > > > 
> > > > I would like to backup few of my VMs.
> > > > I have mount my external usb (not using sys-usb) HDD.
> > > > From the console where my HDD is attached/mounted, I have access 
> > > > through /mnt/removable to all my previous (3.2) backup files.
> > > > I have created, in /mnt/removable, a new folder.
> > > > When running the Qubes backup, and choosing the newly created folder, I 
> > > > have this error:
> > > > 
> > > > Selected directory do not exists or not a directory
> > > > 
> > > > I have created others folders, I have change permissions ... Same 
> > > > problem.
> > > > Today all my folders are:
> > > > 
> > > > - drwxrwxr-x 3 user:user AppVM_bck
> > > > 
> > > > Same pb if root:root
> > > > 
> > > > ??
> > > 
> > > Apologies, I overlooked the "- drwxrwxr-x 3 user:user AppVM_bck" line in 
> > > your post. Since your USB controller then must be directly passed into 
> > > the AppVM, you can try create a direct path copy directly in dom0, even 
> > > though you won't be using this path. As suggested in Rusty Bird's link. 
> > > Does it work for you?
> > 
> > I have created the "/mnt/removable" in dom0.
> > If using as path: /mnt/removable/AppVM_bck I do still have the same error 
> > message.
> > If using as path: /mnt/removable I do have a permission denied.
> > 
> > drwxr-xr-x root rootmnt
> > drwxr-xr-x root rootremovable
> > drwxrwxr-x user user AppVM_bck
> > 
> > Are the permissions correct ? It should be root:root or user:user ?
> > 
> > Thx
> 
> It looks like you did the permissions correctly, lets try something else. I 
> suggest you try make a new fixed artificial mounting path rather than the 
> dynamic allocated one, because it may quite reasonably be why Qubes 4 can't 
> find its way to the path when special symbolic location letters are used as 
> path shortcuts, such as $HOME/ or ~/ and similar for /home/user, which seems 
> similar to /run/removable. So it may be that dynamic folders aren't working 
> very well. 
> 
> For example XFCE4 keybinding a script located in /home/user/ can be a huge 
> hassle if using $HOME/ or ~/ to bypass dynamic user-names in different Linux 
> systems, and instead one has to write the actual user-name in the path, which 
> means it only works if using the full path name, rather than path shortcuts. 
> Maybe it's the same that happens with /mnt/removable. In which case, it may 
> be useful to abandon this location to something not bound by location rules, 
> which can be anywhere but the official places.
> 
> Perhaps this bug could even be related to the recent $ some days back? I 
> dunno though, but without any insight, it seems like it maybe could be.
> 
> So try un-mount the USB drive in the AppVM, and make a new fixed location 
> folder, it could be in /mnt/some-folder <--- give folder a name, but without 
> spaces and special letters to avoid issues.
> 
> Change the some-older's ownership to user and give it permissions. Then once 
> that is done, mount your drive to the folder with appropriate mounting 
> permissions. Then do the same new path in dom0, with same 
> ownership/permissions. 
> 
> Generally only the last folder should have the same permission, at least as 
> far as I know the parent folder permission shouldn't matter much. So don't 
> worry about the parent folders, just focus on the final folder in the path.
> 
> Does it make a difference when you clear out dynamic paths for fixed paths, 
> then remount it, and ensure all permissions are in place?
> 
> Also I don't think you need the dom0 trick if you try this approach, although 
> I could be wrong. I think the dom0 identical path trick is a method to trick 
> the system to not fail on the shortcut path. So by avoiding shortcut paths 
> altogether, you may not need to do the dom0 trick to bypass the bug. I'm not 
> 100% sure if this how it actually works, but it may be worth a try.

fyi, I had same problem, and doing the back-up at the root of the mount point 
allowed me to continue (/media on a DispVM in my case where I had bound a 
second HD on my SATA temporarilly).

-- 
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/a8ff7216-f51d-4fc1-8a14-093c5232af8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Clearing qubes-dom0-cached packages

[Alex Dubois]

On Friday, 12 February 2016 22:08:05 UTC, m.3.7.31.127...@gmail.com  wrote:
> I accidentally ran qubes-dom0-update qubes*testing and qubes downloaded 
> testing packages. I didn't install them, and I don't want to. However, the 
> packages are still cached and I have no way to update qubes now without 
> installing the testing packages.
> 
> How can I clear the package cache?

Hi,

I had the exact problem in this thread. I wanted to check if my 
qubes-dom0-update was broken or not. so enabled testing, which downloaded 
packages, I let it finished but then did not install.

Searched the past threads and found this one.

Applied the --clean option
Which seem to have done some things as I had now 5 packages that it wanted to 
install.
Which seems to confirm that qubes-dom0-update was stuck, also I am not sure (or 
maybe these 5 packages were release during my experiment on the current repo).

Is there a way in github to see the list of packages and the associated commits 
for each repo?

-- 
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/7d0ba026-99cb-46fd-81d8-460602b6ffb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

[Alex Dubois]

On Monday, 26 February 2018 23:17:41 UTC, Thorsten Schierer  wrote:
> Ok, I set up 2 new VMs (sys-net and 
> sys-firewall) in case something went wrong during the setup, but the 
> result was the same as before.
> 
> Not sure how to enable the 
> clocksync service in sys-net (fedora-26 template) but the date/time 
> settings are correct, so I assume it already is syncing correctly.

Yes probably. For reference, to check (or enable):
- go to start menu/System Tools/Qube Manager
- right click sys-net/Qube Settings/Services tab
- clocksync should be in the list and ticked if not type clocksync and click on 
+
- I think a full reboot is required. There are probably ways to avoid it...

> 
> But I did some more research and this is what I found out so far is:
> 
> sys-net itself has a working internet connection (I can do "ping 
> www.google.com" 
> in a terminal and everything is fine).
> Also other VMs that use sys-net directly as netVM can access the internet 
> (i.e. ping a server etc.).
> The only exception is sys-firewall, in which a ping just fails due to no 
> connection.
> 
> When sys-firewall starts up, a new vif is created inside sys-net (which was 
> expected), but there is no route created.
> When
>  I tried to create a new route it said "Network is down". So it did 
> "ifconfig vif8.0 up" and afterwards added a new route with:
> 
> "sudo ip route add 10.137.0.15 dev vif8.0 metric 32752"
> 
> 
> "route -v" displays:
> 10.137.0.15   0.0.0.0   255.255.255.255   UH   32752   0   0   vif8.0
> 
I am confused, did you do this in sys-net or sys-firewall. Because sys-net 
would have a default route and a route for your Lan. You may have tripped the 
info which is fine.

my routing on sys-net looks like this:
-bash-4.4# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG0 0  0 ens5
10.137.0.15  0.0.0.0 255.255.255.255 UH0 0  0 vif8.0
192.168.0.0 0.0.0.0 255.255.255.0   U 0 0  0 ens5

You should not have needed to ifconfig vifX up. This is something that will 
need to be looked at later.

on sys-firewall, you are probably going to need to ifconfig eth0 up and you 
should have something like this:
-bash-4.4# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags   MSS Window  irtt Iface
0.0.0.0 10.137.0.14  0.0.0.0 UG0 0  0 eth0
10.137.0.14  0.0.0.0 255.255.255.255 UH0 0  0 eth0

if .14 is the ip of sys-net (ifconfig | grep -i ast)


from sys-firewall, try ping 8.8.8.8 (Google dns) or something else to remove 
dns resolution from the picture

also arp -an
to check you have connectivity to sys-net and arp resolution
> 
> 
> 
> 
> 
> 
> 
> So at this point the ifconfig and route entries look exactly like on my other 
> machine which is working fine out of the box.
> 
> Unfortunately sys-firewall still does not have a working internet connection 
> ("ping www.google.com" results in "Name or service not known" due to no DNS 
> connectivity).
> 
> 
> So it seems like
>  as soon as I create a new VM with "provides network" checked, it can 
> not use the network connection of sys-net. Any other VM that does not 
> provide network ifself can use sys-net directly and works fine.
> 
> I think there is a problem with some kind of proxy setup in sys-firewall or 
> something.
> 
> Is
>  there some documentation which steps are done regarding networking 
> during the startup of sys-firewall, so I can try to do those steps manually 
> one
>  by one to see where the problem appears?
> 
> 
> 
> 
> 2018-02-26 22:38 GMT+01:00 Alex Dubois <bow...@gmail.com>:
> On Monday, 26 February 2018 03:48:29 UTC, thorsten...@gmail.com  wrote:
> 
> > I installed Qubes 4.0-rc4 and have a problem with my internet connection.
> 
> > sys-net itself has a working internet connection but sys-firewall does not. 
> > No need to mention that every other VM that uses sys-firewall as netVM does 
> > also have no working internet connection.
> 
> >
> 
> > If I switch the default netVM from sys-firewall to sys-net (for testing), 
> > dom0 can use it to update etc. Also any other VM gets internet connection 
> > with sys-net as Networking VM.
> 
> >
> 
> > An update of dom0 from testing-repository did not fix the problem.
> 
> > Also switching the sys-firewall template from fedora-26 to debian-9 does 
> > not help.
> 
> >
> 
> > I found a similar problem here:
> 
> > https://gi

[qubes-users] Re: firewall/proxy VM not working with Qubes 4.0-rc4

[Alex Dubois]

On Monday, 26 February 2018 03:48:29 UTC, thorsten...@gmail.com  wrote:
> I installed Qubes 4.0-rc4 and have a problem with my internet connection.
> sys-net itself has a working internet connection but sys-firewall does not. 
> No need to mention that every other VM that uses sys-firewall as netVM does 
> also have no working internet connection.
> 
> If I switch the default netVM from sys-firewall to sys-net (for testing), 
> dom0 can use it to update etc. Also any other VM gets internet connection 
> with sys-net as Networking VM.
> 
> An update of dom0 from testing-repository did not fix the problem.
> Also switching the sys-firewall template from fedora-26 to debian-9 does not 
> help.
> 
> I found a similar problem here:
> https://github.com/QubesOS/qubes-issues/issues/2141
> 
> So I checked the network interfaces and they are like this:
> 
> sys-net:
> lo
> enp0s0
> vif2.0
> 
> sys-firewall:
> eth0
> lo
> 
> Not sure, but I guess the vif interface is missing in sys-firewall?
> How do I fix this problem?

vif interface will appear when a VM connects to it.

Could you clarify the term no internet.

I had a lot of problems solved once sys-net had the service clocksync enabled 
(as it should).

-- 
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/46a6952f-6fd5-4aec-93ca-994937a24c5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Wednesday, 21 February 2018 09:01:45 UTC, ThierryIT  wrote:
> Le mercredi 14 février 2018 09:49:37 UTC+2, ThierryIT a écrit :
> > Le dimanche 11 février 2018 10:08:52 UTC+2, ThierryIT a écrit :
> > > Le samedi 10 février 2018 22:58:15 UTC+2, Alex Dubois a écrit :
> > > > > On 10 Feb 2018, at 17:46, ThierryIT <v...@gmail.com> wrote:
> > > > > 
> > > > > Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
> > > > >> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> > > > >>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > > > >>>> Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > > > >>>>>> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > > >>>>>> Not familiar with this ... Will need procediure to follow.
> > > > >>>>>> 
> > > > >>>>>> 
> > > > >>>>>> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > > >>>>>>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > > >>>>>>>> No, I am still under R3.2
> > > > >>>>>>>> 
> > > > >>>>>>>> Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > >>>>>>>>> On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > >>>>>>>>>> "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > >>>>>>>>>> 
> > > > >>>>>>>>>> 
> > > > >>>>>>>>>> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > >>>>>>>>>> 
> > > > >>>>>>>>>>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > >>>>>>>>>>> 
> > > > >>>>>>>>>>>> Nobody ?
> > > > >>>>>>>>>>>> 
> > > > >>>>>>>>>>>> 
> > > > >>>>>>>>>>>> 
> > > > >>>>>>>>>>>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a 
> > > > >>>>>>>>>>>> écrit :
> > > > >>>>>>>>>>>> 
> > > > >>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> Hi,
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> I am going to install a new sys-usb.
> > > > >>>>>>>>>>>>> I have before to install all what I need to the template 
> > > > >>>>>>>>>>>>> (fedora-26)
> > > > >>>>>>>>>>>>> first. When following your procedure:
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> ykpers has been installed but: I cannot do the same for
> > > > >>>>>>>>>>>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> no match for argument
> > > > >>>>>>>>>>>>> 
> > > > >>>>>>>>>>>>> ideas ?
> > > > >>>>>>>>>>> 
> > > > >>>>>>>>>>> Not quite sure what you are trying to do here. What 
> > > > >>>>>>>>>>> procedure? What
> > > > >>>>>>>>>>> command are you entering?
> > > > >>>>>>>>> 
> > > > >>>>>>>>> Are you trying this on Qubes 4.0? Those Yubikey packages 
> > > > >>>>>>>>> might not be in
> > > > >>>>>>

Re: [qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Saturday, 10 February 2018 04:39:14 UTC, Yuraeitha  wrote:
> On Friday, February 9, 2018 at 8:02:13 PM UTC+1, Ivan Mitev wrote:
> > On 02/09/18 20:56, Alex Dubois wrote:
> > > On Friday, 9 February 2018 18:43:06 UTC, Ivan Mitev  wrote:
> > >> On 02/09/18 20:23, Alex Dubois wrote:
> > >>> On Friday, 9 February 2018 18:01:08 UTC, Ivan Mitev  wrote:
> > >>>> On 02/09/18 19:37, Alex Dubois wrote:
> > >>>>> On Friday, 9 February 2018 13:17:19 UTC, Alex Dubois  wrote:
> > >>>>>> On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> > >>>>>>> On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> After booting the win7 VM, the DVD get recognized.
> > >>>>>>>> Windows is loading file progress bar is going smoothly
> > >>>>>>>> But the win7 VM goes into halted or transient state just after 
> > >>>>>>>> displaying the graphical splash screen Starting Windows
> > >>>>>>>>
> > >>>>>>>> At the moment I am exploring how to resolve this issue in R4 
> > >>>>>>>> https://github.com/QubesOS/qubes-issues/issues/2488
> > >>>>>>>>
> > >>>>>>>> I've tried
> > >>>>>>>> qvm-features win7 video-model cirrus
> > >>>>>>>> but same problem
> > >>>>>>>
> > >>>>>>> Fixed.
> > >>>>>>> The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> > >>>>>>> qvm-prefs win7 memory 2048
> > >>>>>>>
> > >>>>>>> I'll update the doc.
> > >>>>>>
> > >>>>>> I have also tested that
> > >>>>>> qvm-features win7 video-model cirrus
> > >>>>>> is NOT required (in my case).
> > >>>>>
> > >>>>> I should test fully before saying things. It was required after the 
> > >>>>> first reboot.
> > >>>>>
> > >>>>> This thread provide a comprehensive view 
> > >>>>> https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94
> > >>>>>
> > >>>>
> > >>>> FYI once the second part of the installation is complete and you have a
> > >>>> working windows VM, you can revert the display adapter to standard vga
> > >>>> (qvm-features --unset win7 video-model).
> > >>>>
> > >>>> Happy that the qubes-devel thread was useful :)
> > >>>
> > >>> Yes thanks a lot. I have now a working win7. Starting Windows-Tools 
> > >>> install.
> > >>
> > >> I just did that :) - it works well... (but don't try to install the pv
> > >> storage driver otherwise you'll get a BSOD).
> > > 
> > > Thanks for the warning ;-)
> > > 
> > > I can't find qubes-windows-tools
> > > is it in testing branch?
> > 
> > Yes (in R3.2):
> > 
> > https://yum.qubes-os.org/r3.2/current-testing/dom0/fc23/rpm/qubes-windows-tools-3.2.2-3.x86_64.rpm
> > 
> > Extract with:
> > 
> > rpm2cpio qubes-windows-tools-3.2.2-3.x86_64.rpm | cpio -idmv
> > 
> > And start the VM (assuming the iso is in the 'untrusted' VM):
> > 
> > qvm-start --cdrom=untrusted:/home/user/qubes-windows-tools.iso win7
> 
> Nice one Ivan, this really pushes forward the ability to re-install Win7 
> without having to use Qubes 3.2. for it.
> 
> @Alex 
> Do you feel the system is as stable as it was on Qubes 3.2. with this fresh 
> re-install on Qubes 4? Of course with the included Qubes 4 required 
> adjustments like network, page-file, and so on.

I am not using Windows day to day. It is more to help the project that I spend 
time on it. I had tried a number of things with previous version of Qubes. 
Trying to get all things to work on R4.
I Have not yet done the QWT.

I think there is still some wokr for non tech users to feel as comfortable. It 
is stable but there are a number of small usability bugs. nothing you can't 
solve if you are happy to close qubes-manager and re-open or launch a dom0 
command or two.

-- 
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/656e7fe2-a77d-41fb-8819-1489a7256f89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.

[Alex Dubois]

On Monday, 19 February 2018 16:19:07 UTC, QUBE-A-LICIOUS  wrote:
> On Monday, February 19, 2018 at 4:08:36 AM UTC-6, schnuren...@gmail.com wrote:
> > On Sunday, February 18, 2018 at 5:52:34 PM UTC+1, QUBE-A-LICIOUS wrote:
> > > On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com 
> > > wrote:
> > > > On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS 
> > > > wrote:
> > > > > Hi there,
> > > > > 
> > > > > I have a fresh install of Qubes 4r4.  However, when I reboot and or 
> > > > > login I have to manually change dom0 time to UTC.
> > > > > 
> > > > > Impact: Whonix/Tor does not work because of the incorrect time.
> > > > > 
> > > > > Manual workaround:
> > > > > 1.  Get the correct UTC from a browser.
> > > > > 2.  Open Dom0 Terminal and update to UTC such as the following:
> > > > > 
> > > > >   sudo date --set "2018-02-13 21:30"
> > > > > 
> > > > > 3. Shutdown Service:sys-whonix
> > > > > 4.  Restart a whonix domain such as Domain:anon-whonix(this restarts 
> > > > > the sys-whonix service that was just shutdown.
> > > > > 5.  Then run WhonixCheck to make sure it works.  It usually does and 
> > > > > Whonix/Tor is functional.
> > > > > 
> > > > > =
> > > > > Qubes cannot be this bad, really.
> > > > > 
> > > > > How can I have this Date and time correctly updated on boot up?  Like 
> > > > > it should.
> > > > > 
> > > > > Thanks for all your help.
> > > > > NSJ
> > > > 
> > > > Most times it is easy to point on another guilty one instead looking 
> > > > what may happen with the own stuff. So far you are the only one with 
> > > > this misbehavior.
> > > > Qubes works as expected - at least in this point.
> > > > But most user already experienced this behavior; qubes-os or any other 
> > > > distribution.
> > > > The keyword is hwclock. You always update the software-based time, but 
> > > > if you restart, all temporary data is gone. (should)
> > > > So your OS fetches at boot the time from the bios.
> > > > If you update your time within the qubes-os, you should update your 
> > > > hardware clock (hc) as well: sudo hwclock --systohc
> > > > If your time resets when you unplug your device from power supply, your 
> > > > device's battery is flat.
> > > 
> > > --
> > > I did some analysis this morning.  So at the same point in time the 
> > > following settings on my Qubes laptop showed the following values.  
> > > (Bottom line is that whonix/tor does not work)
> > > 
> > > 1.  The hardware BIOS clock is:  1030  (BIOS battery good, removed laptop 
> > > battery for few hours and date/time stayed same)
> > > 
> > > 2.  Dom0 time is: 0530 ( via date command)
> > > 
> > > 3.  service:sys-whonix is:  1030 (via date command)
> > > 
> > > 4.  Clock on upper right of screen is:  0430
> > > 
> > > Tor Boostrap info is:
> > > 
> > > Whonixcheck gave up waiting
> > > clock skew -21635 in directory from DIRSERV
> > > 
> > > sudo date --set “2018 -02-18 17:30:00”
> > > 
> > > -
> > > I think that on a normal bootup the clocks should be in sync and 
> > > Whonix/Tor should work.
> > 
> > bios time differs a lot from dom0 and dom0 time seems in the UTC 
> > (timezone), while the clock on your desktop should be therefore in the -1 
> > hour timezone. 
> > There is already something wrong, isn't it?
> > Could you please set the correct time in dom0 and do a 'sudo hwclock 
> > --systohw' to get dom0's sys date and bios time in sync.
> > And reboot pls. After reboot check the time in bios, dom0 and your clockVM 
> > (probably sys-net) before connecting to any network.
> > In System Tools -> Qubes Global Settings in dom0 you can check the name of 
> > the clock VM.
> > The time of your whonix should, as far as I know, differs in timezone as 
> > qubes built-in rule randomly each bootup of the VM. (Do not know for sure)
> > 
> > I either do not know whether sys-whonix only changes the timezone and if it 
> > is an attack surface if someone from the outside could simulate/fake 
> > specific minutes and seconds your network-time-daemon adapt and your whonix 
> > could be associated to your isp.
> > 
> > Even there seems to be some misconfiguration I never got, the behavior 
> > remembers me to an empty hardware battery.
> 
> ==
> 1.  I changed to the correct Time Zone from the command line.  Fixed the -1 
> hour offset.
> 2.  I updated the dom0 time
> 3.  I ran the sudo hwclock -w to set the hardware clock from the current 
> system time.
> 4.  I rebooted the laptop.
> 
> The current results are:
> 
> 1.  BIOS clock is:  1530  (via BIOS menu on startup)
> 
> 2.  Dom0 time is: 0930 with correct time zone.  (Correct!)
> 
> 3.  service:sys-whonix is:  1530 UTC
> 
> 4.  Clock on upper right of screen is:  0930 (Correct!)
> 
> 5.  sys-net is 0930.  (Correct!)
> 
> 6.  Tor Boostrap info is:  (from sys-whonix occurs right after startup)
> 
> ERROR systemd clock check result:
> Unexpected 

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

> On 10 Feb 2018, at 17:46, ThierryIT <vmware...@gmail.com> wrote:
> 
> Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
>> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
>>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
>>>> Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
>>>>>> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
>>>>>> Not familiar with this ... Will need procediure to follow.
>>>>>> 
>>>>>> 
>>>>>> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
>>>>>>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
>>>>>>>> No, I am still under R3.2
>>>>>>>> 
>>>>>>>> Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
>>>>>>>>> On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
>>>>>>>>>> "https://github.com/adubois/qubes-app-linux-yubikey;
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
>>>>>>>>>> 
>>>>>>>>>>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Nobody ?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I am going to install a new sys-usb.
>>>>>>>>>>>>> I have before to install all what I need to the template 
>>>>>>>>>>>>> (fedora-26)
>>>>>>>>>>>>> first. When following your procedure:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ykpers has been installed but: I cannot do the same for
>>>>>>>>>>>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
>>>>>>>>>>>>> 
>>>>>>>>>>>>> no match for argument
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ideas ?
>>>>>>>>>>> 
>>>>>>>>>>> Not quite sure what you are trying to do here. What procedure? What
>>>>>>>>>>> command are you entering?
>>>>>>>>> 
>>>>>>>>> Are you trying this on Qubes 4.0? Those Yubikey packages might not be 
>>>>>>>>> in
>>>>>>>>> the Qubes repo yet.
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I have not maintained this for some time. So long that I can't remember 
>>>>>>> if the packages had been created/tested, I don't think they have.
>>>>>>> 
>>>>>>> Best is you follow the steps to build it on a new temporary VM, don't 
>>>>>>> be afraid it should not be too hard:
>>>>>>> - Execute the yum command in "Build dependancies"
>>>>>>> - Also install pam-devel
>>>>>>> - Follow the steps in preparing the build and build
>>>>>>> - Deploy the code in Dom0 and the USB VM.
>>>>>>> 
>>>>>>> I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
>>>>>>> probably be able to help until this is done.
>>>>>>> 
>>>>>>> Any help from someone who is used to packaging under Fedora would be 
>>>>>>> nice.
>>>>>>> 
>>>>>>> Alex
>>>>> 
>>>>> Sure, I'll update the doc and post here. However as I said don't want to 
>>>>> touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
>>>>> 2-3weeks
>

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

> On 10 Feb 2018, at 20:16, joevio...@gmail.com wrote:
> 
> Yubikey can have different modes of authentication.  I remember looking at 
> the work of adubois last year as a possible solution.
> My Yubikey has a slot used for Challenge/Response, which is MUCH easier to 
> work with when you have multiple systems and devices.
> 
> I guess YubicoOTP would require something like a custom PAM module... but 
> with Challenge/Response, my solution was to use the built-in pam_exec.so to 
> run a very short script when authenticating.

My solution is a custom PAM module with password + OTP and master password (to 
use if compromised USB VM).
This OTP slot of the Yubikey is then dedicated for 1 Qubes. 
I made sure you can’t forget the yubikey in the slot, the OTP is transmitted to 
USBVM when key is pressed and transmitted to Dom0 when you remove the key. 
If on key removal you are not authenticated you have to assume that USBVM is 
compromised and may be used for hold and replay attack. You have to go to a 
secure area, login with master password, destroy USBVM and reinstall front-end 
+ re-initialise the PAM. 
If you press by mistake the yubikey, I think you have also a risk of compromise 
and have to do the same. 

The challenge response is more practical but I feel less secure (I might be 
wrong), I have not looked deeply into it. Influencing the generation of the 
challenge (to be the same as a previous one) via clock. 
> 
> The only dependency is to install ykpers on sys-usb as it uses ykchalresp.
> 
> https://gist.github.com/Joeviocoe/929ebde1066a22491bf93ccc9d6c0ba3
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/BkdTuXZZnwE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e5d1abf4-4627-4a09-927c-ec4294cc481d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-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/EF1BE37B-21E0-44BE-866C-2BE99DD1726E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > > On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > > Not familiar with this ... Will need procediure to follow.
> > > > 
> > > > 
> > > > Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > > > On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > > > > No, I am still under R3.2
> > > > > > 
> > > > > > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > > > > >
> > > > > > > >
> > > > > > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > > > > >
> > > > > > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > > > > >>
> > > > > > > >>> Nobody ?
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit 
> > > > > > > >>> :
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>> Hi,
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> I am going to install a new sys-usb.
> > > > > > > >>>> I have before to install all what I need to the template 
> > > > > > > >>>> (fedora-26)
> > > > > > > >>>>  first. When following your procedure:
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> ykpers has been installed but: I cannot do the same for
> > > > > > > >>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > > > > >>>>
> > > > > > > >>>> no match for argument
> > > > > > > >>>>
> > > > > > > >>>> ideas ?
> > > > > > > >>
> > > > > > > >> Not quite sure what you are trying to do here. What procedure? 
> > > > > > > >> What
> > > > > > > >> command are you entering?
> > > > > > > 
> > > > > > > Are you trying this on Qubes 4.0? Those Yubikey packages might 
> > > > > > > not be in
> > > > > > > the Qubes repo yet.
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I have not maintained this for some time. So long that I can't 
> > > > > remember if the packages had been created/tested, I don't think they 
> > > > > have.
> > > > > 
> > > > > Best is you follow the steps to build it on a new temporary VM, don't 
> > > > > be afraid it should not be too hard:
> > > > > - Execute the yum command in "Build dependancies"
> > > > > - Also install pam-devel
> > > > > - Follow the steps in preparing the build and build
> > > > > - Deploy the code in Dom0 and the USB VM.
> > > > > 
> > > > > I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> > > > > probably be able to help until this is done.
> > > > > 
> > > > > Any help from someone who is used to packaging under Fedora would be 
> > > > > nice.
> > > > > 
> > > > > Alex
> > > 
> > > Sure, I'll update the doc and post here. However as I said don't want to 
> > > touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
> > > 2-3weeks
> > 
> > Did you upgrade to Q4R4 ?
> 
> I'm in the process. Having issues with PCI path-through of my second NIC that 
> I need to solve. I have to use PV mode for now and not too happy to have too. 
> I'll open another thread if I can't find a way...

Hi Thierry,

I have recompiled it OK. This was working on R3.2. You can test it on R4 but no 
idea if it will work. I hope to have a bit of time to look at it this week.

To compile it if you want to test / debugInR4
create new VM with network (to get the github) or without network but you'll 
have to copy the download to the VM by another mean. Then:
yum install pam-devel gettext-devel git libtool libyubikey libyubikey-devel -y
yum group install "Development Tools"
git clone https://github.com/adubois/qubes-app-linux-yubikey.git
cd qubes-app-linux-yubikey/
libtoolize --install
autoreconf --install
./configure
make check

files to copy to Dom0 are in folder back-end
files to copy to USBVM are in folder front-end

USBVM should be a VM started on boot with the USB controller that you insert 
the key in...

Read the doc, it is not polished.
There are mechanisms to detect USBVM compromise, hold-replay attacks, etc...

-- 
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/a73944a1-7c80-4ad1-9235-8e43a581f195%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 18:43:06 UTC, Ivan Mitev  wrote:
> On 02/09/18 20:23, Alex Dubois wrote:
> > On Friday, 9 February 2018 18:01:08 UTC, Ivan Mitev  wrote:
> >> On 02/09/18 19:37, Alex Dubois wrote:
> >>> On Friday, 9 February 2018 13:17:19 UTC, Alex Dubois  wrote:
> >>>> On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> >>>>> On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> After booting the win7 VM, the DVD get recognized.
> >>>>>> Windows is loading file progress bar is going smoothly
> >>>>>> But the win7 VM goes into halted or transient state just after 
> >>>>>> displaying the graphical splash screen Starting Windows
> >>>>>>
> >>>>>> At the moment I am exploring how to resolve this issue in R4 
> >>>>>> https://github.com/QubesOS/qubes-issues/issues/2488
> >>>>>>
> >>>>>> I've tried
> >>>>>> qvm-features win7 video-model cirrus
> >>>>>> but same problem
> >>>>>
> >>>>> Fixed.
> >>>>> The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> >>>>> qvm-prefs win7 memory 2048
> >>>>>
> >>>>> I'll update the doc.
> >>>>
> >>>> I have also tested that
> >>>> qvm-features win7 video-model cirrus
> >>>> is NOT required (in my case).
> >>>
> >>> I should test fully before saying things. It was required after the first 
> >>> reboot.
> >>>
> >>> This thread provide a comprehensive view 
> >>> https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94
> >>>
> >>
> >> FYI once the second part of the installation is complete and you have a
> >> working windows VM, you can revert the display adapter to standard vga
> >> (qvm-features --unset win7 video-model).
> >>
> >> Happy that the qubes-devel thread was useful :)
> > 
> > Yes thanks a lot. I have now a working win7. Starting Windows-Tools install.
> 
> I just did that :) - it works well... (but don't try to install the pv 
> storage driver otherwise you'll get a BSOD).

Thanks for the warning ;-)

I can't find qubes-windows-tools
is it in testing branch?

-- 
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/d0327049-68f6-425e-9cc5-990627c14be3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 18:01:08 UTC, Ivan Mitev  wrote:
> On 02/09/18 19:37, Alex Dubois wrote:
> > On Friday, 9 February 2018 13:17:19 UTC, Alex Dubois  wrote:
> >> On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> >>> On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> >>>> Hi,
> >>>>
> >>>> After booting the win7 VM, the DVD get recognized.
> >>>> Windows is loading file progress bar is going smoothly
> >>>> But the win7 VM goes into halted or transient state just after 
> >>>> displaying the graphical splash screen Starting Windows
> >>>>
> >>>> At the moment I am exploring how to resolve this issue in R4 
> >>>> https://github.com/QubesOS/qubes-issues/issues/2488
> >>>>
> >>>> I've tried
> >>>> qvm-features win7 video-model cirrus
> >>>> but same problem
> >>>
> >>> Fixed.
> >>> The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> >>> qvm-prefs win7 memory 2048
> >>>
> >>> I'll update the doc.
> >>
> >> I have also tested that
> >> qvm-features win7 video-model cirrus
> >> is NOT required (in my case).
> > 
> > I should test fully before saying things. It was required after the first 
> > reboot.
> > 
> > This thread provide a comprehensive view 
> > https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94
> > 
> 
> FYI once the second part of the installation is complete and you have a 
> working windows VM, you can revert the display adapter to standard vga 
> (qvm-features --unset win7 video-model).
> 
> Happy that the qubes-devel thread was useful :)

Yes thanks a lot. I have now a working win7. Starting Windows-Tools install.

-- 
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/7f15f159-955c-4811-86d7-20d0b6d195be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 13:17:19 UTC, Alex Dubois  wrote:
> On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> > On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> > > Hi,
> > > 
> > > After booting the win7 VM, the DVD get recognized.
> > > Windows is loading file progress bar is going smoothly
> > > But the win7 VM goes into halted or transient state just after displaying 
> > > the graphical splash screen Starting Windows
> > > 
> > > At the moment I am exploring how to resolve this issue in R4 
> > > https://github.com/QubesOS/qubes-issues/issues/2488
> > > 
> > > I've tried
> > > qvm-features win7 video-model cirrus
> > > but same problem
> > 
> > Fixed.
> > The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> > qvm-prefs win7 memory 2048
> > 
> > I'll update the doc.
> 
> I have also tested that
> qvm-features win7 video-model cirrus
> is NOT required (in my case).

I should test fully before saying things. It was required after the first 
reboot.

This thread provide a comprehensive view 
https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94

-- 
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/7c4bf0cc-9daf-4b7b-93fd-fd02a3203a4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

On Friday, 9 February 2018 10:50:03 UTC, Yuraeitha  wrote:
> On Friday, February 9, 2018 at 11:02:21 AM UTC+1, Alex Dubois wrote:
> > On Friday, 9 February 2018 09:04:25 UTC, Yuraeitha  wrote:
> > > On Friday, February 9, 2018 at 9:25:52 AM UTC+1, Alex Dubois wrote:
> > > > Hi,
> > > > 
> > > > I am trying to get Windows installed on R4.
> > > > 
> > > > qvm-create win7 --class StandaloneVM --label blue
> > > > qvm-prefs win7 | grep virt
> > > >   it is pvh
> > > > qvm-prefs win7 virt_mode hvm (I suspect doc needs to be updated here)
> > > > qvm-start win7 --cdrom=sys-usb:sr0
> > > >   I get 4 lines SeaBios, last one being "Probing EDD (edd=off to 
> > > > disable!... ok" - Screenshot attached.
> > > > qvm-ls
> > > >   win7 is halted
> > > > 
> > > > I saw ticket https://github.com/QubesOS/qubes-issues/issues/3055 
> > > > providing the --cdrom option.
> > > > 
> > > > Am I missing something?
> > > 
> > > Right now "most" things work in Qubes 4, but many of them have one of the 
> > > multiple of approaches to do the same thing, where some of these multiple 
> > > approaches are not working. Extra approaches to do the same thing, may 
> > > have lower priority if it works if done in a different way. These issues 
> > > will eventually get fixed, it's just a matter for the developers to 
> > > advance down the list of priorities of fixes.
> > 
> > Yes I know, I'm planning on helping... on a Windows 10 QWT workaround that 
> > is secure and follow Qubes OS philosophy.
> > > 
> > > For example, sometimes using the terminal is better, while other times 
> > > the GUI works better. Mostly the terminal works better, but there are 
> > > cases where the GUI works better than the terminal commands. 
> > > 
> > > Your issue might be one of those case, "Especially!" considering the GUI 
> > > to boot from a CDROM/DVD has been re-made, and the whole admin 
> > > panel/python code beneath it. So chances are that the GUI works better, 
> > > since they put focused effort into this GUI tool, and "may" have 
> > > postponed terminal fixes for later lower priorities.
> > > 
> > > What I recommend is that you shutdown your Win7 VM --> go to the VM's 
> > > graphical settings --> Advanced tab --> pick the "Boot qube from CDROM" 
> > > button.
> > > 
> > > Try give it a try, see if it works or not. 
> > 
> > I had tried and it was not working, but thanks for the suggestion.
> > > 
> > > 
> > > 
> > > If it doesn't work: Then it might be because this feature has an overall 
> > > lower priority to get fixed compared to other things in Qubes 4 atm. 
> > > Perhaps other suggestions can find a way to bypass this issue, keep 
> > > checking this thread over the coming days for anyone posting.
> > > 
> > > Also Qubes 4 will probably not be final release stage before both GUI and 
> > > terminal works for the most important features. Until then, you have to 
> > > find work-arounds for things like these.
> 
> ah my bad, I did not know that. I tend to just go full speed ahead with the 
> size of my context in my suggestions if I don't know anything about a persons 
> existing knowledge. It does from time to time cause big problems if I assumed 
> wrong, I really need to stop doing that habit ^^;
> 
> btw in case you haven't seen it, we currently having a discussion about Win7 
> in Qubes-devel 
> https://groups.google.com/forum/#!topic/qubes-devel/tBqwJmOAJ94 
> In case some of the work-around fixes and issue discussions may have some 
> useful inputs for the work on Win10 (for example Marek's post is very 
> insightful), and also the wiki that Ivan made is being used to keep every 
> confirmed known issues in a single place.

No problem.

Ah thanks for the pointer. I'll check. (I wish I could PM). Assume I do thank 
you in the future when I do not reply ;)

-- 
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/6a1a8a88-cc9b-4fb4-8d92-014394eeb632%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 13:07:27 UTC, Alex Dubois  wrote:
> On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> > Hi,
> > 
> > After booting the win7 VM, the DVD get recognized.
> > Windows is loading file progress bar is going smoothly
> > But the win7 VM goes into halted or transient state just after displaying 
> > the graphical splash screen Starting Windows
> > 
> > At the moment I am exploring how to resolve this issue in R4 
> > https://github.com/QubesOS/qubes-issues/issues/2488
> > 
> > I've tried
> > qvm-features win7 video-model cirrus
> > but same problem
> 
> Fixed.
> The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
> qvm-prefs win7 memory 2048
> 
> I'll update the doc.

I have also tested that
qvm-features win7 video-model cirrus
is NOT required (in my case).

-- 
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/219e8663-dfa0-4a9d-936e-ad6516ca7ea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

On Friday, 9 February 2018 12:31:10 UTC, Alex Dubois  wrote:
> Hi,
> 
> After booting the win7 VM, the DVD get recognized.
> Windows is loading file progress bar is going smoothly
> But the win7 VM goes into halted or transient state just after displaying the 
> graphical splash screen Starting Windows
> 
> At the moment I am exploring how to resolve this issue in R4 
> https://github.com/QubesOS/qubes-issues/issues/2488
> 
> I've tried
> qvm-features win7 video-model cirrus
> but same problem

Fixed.
The minimum specs from Microsoft for Windows 7 64bits is 2GB of RAM.
qvm-prefs win7 memory 2048

I'll update the doc.

-- 
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/a07e2bc1-2c48-4738-abb7-43d08edf27a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Windows on R4 (rc4) - Install crash on splash screen: Starting Windows

[Alex Dubois]

Hi,

After booting the win7 VM, the DVD get recognized.
Windows is loading file progress bar is going smoothly
But the win7 VM goes into halted or transient state just after displaying the 
graphical splash screen Starting Windows

At the moment I am exploring how to resolve this issue in R4 
https://github.com/QubesOS/qubes-issues/issues/2488

I've tried
qvm-features win7 video-model cirrus
but same problem

-- 
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/413b83fe-9222-4b82-9480-29e13972b9b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

On Friday, 9 February 2018 10:42:51 UTC, awokd  wrote:
> On Fri, February 9, 2018 10:25 am, Alex Dubois wrote:
> > On Friday, 9 February 2018 08:35:17 UTC, awokd  wrote:
> >
> >> On Fri, February 9, 2018 8:25 am, Alex Dubois wrote:
> >> Try
> >> qvm-prefs win7 kernel ""
> >
> > @awokd, I've created a pull request to update the doc
> > https://github.com/QubesOS/qubes-issues/issues/3055
> 
> Thank you! Found it under https://github.com/QubesOS/qubes-doc/pull/576.
> I'm planning on leaving the Win7 on R4.0 documentation to the future
> maintainer of QWT 4.0 right now, but that question comes up a lot. It
> applies to other OSes in an HVM too, maybe it should also be a FAQ?

Oh sorry put the wrong link

Yes, I'll try to help you clean up once I get a better grasp on Win7 and Win10 
on R4 (with the RDPClient+Samba HackWinVM to get QWT functionality until it is 
there).

I have another problem now. I'll create a new thread.

-- 
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/8983034d-8e33-4516-9575-6aeb6b323171%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

On Friday, 9 February 2018 08:35:17 UTC, awokd  wrote:
> On Fri, February 9, 2018 8:25 am, Alex Dubois wrote:
> Try
> qvm-prefs win7 kernel ""

@awokd, I've created a pull request to update the doc 
https://github.com/QubesOS/qubes-issues/issues/3055

-- 
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/1f2e6587-abfb-4b73-b8b4-2339eb594c9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

On Friday, 9 February 2018 09:04:25 UTC, Yuraeitha  wrote:
> On Friday, February 9, 2018 at 9:25:52 AM UTC+1, Alex Dubois wrote:
> > Hi,
> > 
> > I am trying to get Windows installed on R4.
> > 
> > qvm-create win7 --class StandaloneVM --label blue
> > qvm-prefs win7 | grep virt
> >   it is pvh
> > qvm-prefs win7 virt_mode hvm (I suspect doc needs to be updated here)
> > qvm-start win7 --cdrom=sys-usb:sr0
> >   I get 4 lines SeaBios, last one being "Probing EDD (edd=off to 
> > disable!... ok" - Screenshot attached.
> > qvm-ls
> >   win7 is halted
> > 
> > I saw ticket https://github.com/QubesOS/qubes-issues/issues/3055 providing 
> > the --cdrom option.
> > 
> > Am I missing something?
> 
> Right now "most" things work in Qubes 4, but many of them have one of the 
> multiple of approaches to do the same thing, where some of these multiple 
> approaches are not working. Extra approaches to do the same thing, may have 
> lower priority if it works if done in a different way. These issues will 
> eventually get fixed, it's just a matter for the developers to advance down 
> the list of priorities of fixes.

Yes I know, I'm planning on helping... on a Windows 10 QWT workaround that is 
secure and follow Qubes OS philosophy.
> 
> For example, sometimes using the terminal is better, while other times the 
> GUI works better. Mostly the terminal works better, but there are cases where 
> the GUI works better than the terminal commands. 
> 
> Your issue might be one of those case, "Especially!" considering the GUI to 
> boot from a CDROM/DVD has been re-made, and the whole admin panel/python code 
> beneath it. So chances are that the GUI works better, since they put focused 
> effort into this GUI tool, and "may" have postponed terminal fixes for later 
> lower priorities.
> 
> What I recommend is that you shutdown your Win7 VM --> go to the VM's 
> graphical settings --> Advanced tab --> pick the "Boot qube from CDROM" 
> button.
> 
> Try give it a try, see if it works or not. 

I had tried and it was not working, but thanks for the suggestion.
> 
> 
> 
> If it doesn't work: Then it might be because this feature has an overall 
> lower priority to get fixed compared to other things in Qubes 4 atm. Perhaps 
> other suggestions can find a way to bypass this issue, keep checking this 
> thread over the coming days for anyone posting.
> 
> Also Qubes 4 will probably not be final release stage before both GUI and 
> terminal works for the most important features. Until then, you have to find 
> work-arounds for things like these.

-- 
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/e7b1f8c3-274c-4817-b443-3b3db17cf19e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

On Friday, 9 February 2018 08:35:17 UTC, awokd  wrote:
> On Fri, February 9, 2018 8:25 am, Alex Dubois wrote:
> Try
> qvm-prefs win7 kernel ""

Great, it fixed 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/3d7e3581-b83f-4a35-881c-d7937f3d2aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Windows on R4 (rc4) - DVD or iso not detected

[Alex Dubois]

Hi,

I am trying to get Windows installed on R4.

qvm-create win7 --class StandaloneVM --label blue
qvm-prefs win7 | grep virt
  it is pvh
qvm-prefs win7 virt_mode hvm (I suspect doc needs to be updated here)
qvm-start win7 --cdrom=sys-usb:sr0
  I get 4 lines SeaBios, last one being "Probing EDD (edd=off to disable!... 
ok" - Screenshot attached.
qvm-ls
  win7 is halted

I saw ticket https://github.com/QubesOS/qubes-issues/issues/3055 providing the 
--cdrom option.

Am I missing something?


-- 
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/1824236a-fffa-4e86-9893-cd5fdcfd8ac9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Privacy in Qubes

[Alex Dubois]

On Tuesday, 26 September 2017 03:10:37 UTC+1, Drew White  wrote:
> On Saturday, 23 September 2017 11:39:31 UTC+10, Person  wrote:
> > These are all very good tips, but to be honest, I'm not actually doing 
> > anything too serious on Qubes so tracking is not that bad (but privacy is 
> > still valuable). 
> > 
> > How would changing the web user agent fare? I tried it, and I believe it 
> > works well, but I am not sure what happens to the tracking. Of course, 
> > adding another OS in a Qubes VM would work well too, but it takes much more 
> > effort.
> 
> There is so much more that one would need to do to protect privacy.
> 
> Either you want privacy and do everything within your power, or else you 
> don't.
> 
> User Agent, doesn't mean much these days, they can still query the browser 
> directly, unless you change all that information too.
> Tracking.. not everyone obeys the "do not track me" settings.
> 
> I have one guest for this forum. I have one guest for another thing, and so 
> on.
> 
> I have multiple NetVMs and multiple ProxyVMs.
> 
> I run anywhere between 5 and 25 guests at any one time.
> I run Debian, Slackware, CentOS, Windows 3.11,95,98,2000,xp,7,8,10 (32 and 64 
> bit versions of available). I run OSX, ESXi, PFSense, Android 4, 5, 6, 7, 
> Qubes 1,2,3, XEN, PASOS, COFFEE, OS/2, Also many many tools that I run for 
> attaching external HDDs and running tools on them.
> 
> I keep privacy between them, but I also try to keep my privacy online by 
> running VPNs and TOR and VPN through TOR. All for different tasks and 
> accesses and security requirements.

Would having 2 APP VMs, each connecting to ProxyVM and VPNVM, connecting to 
FirewallVM be OK with you? (The VPN VM "exiting" the internet not from your 
home router)?

-- 
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/5e46da95-5aef-44e0-8274-dbf6dfa5b438%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes R4 rc4 - Lenovo T430 - 1st boot - Blackscreen after "Xen is reliquishing VGA console."

[Alex Dubois]

On Thursday, 8 February 2018 19:27:20 UTC, Alex Dubois  wrote:
> On Thursday, 8 February 2018 17:50:15 UTC, Alex Dubois  wrote:
> > Hi,
> > 
> > After successful install of R4 rc4, on 1st boot I do not get any error 
> > message.
> > 
> > Last line displayed is
> > (XEN) Xen is reliquinshing VGA console.
> > 
> > I was not able to find a thread with the same problem.
> > 
> > Would someone be able to point me to a thread explaining what I could try 
> > or give me some hints.
> > 
> > Thanks,
> > Alex
> 
> Was "fixed" by a re-install with different Bios options. I'll clarify.

On boot...
Press Enter to go into ThinkPad Setup
in section Startup -> UEFI/Legacy Boot select Legacy Only

-- 
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/1597d5aa-abc6-4261-b98c-ee5b51299888%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes R4 rc4 - Lenovo T430 - 1st boot - Blackscreen after "Xen is reliquishing VGA console."

[Alex Dubois]

On Thursday, 8 February 2018 17:50:15 UTC, Alex Dubois  wrote:
> Hi,
> 
> After successful install of R4 rc4, on 1st boot I do not get any error 
> message.
> 
> Last line displayed is
> (XEN) Xen is reliquinshing VGA console.
> 
> I was not able to find a thread with the same problem.
> 
> Would someone be able to point me to a thread explaining what I could try or 
> give me some hints.
> 
> Thanks,
> Alex

Was "fixed" by a re-install with different Bios options. I'll clarify.

-- 
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/3ffc72dc-474a-47cb-ae7b-b32c88013acb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes R4 rc4 - Lenovo T430 - 1st boot - Blackscreen after "Xen is reliquishing VGA console."

[Alex Dubois]

Hi,

After successful install of R4 rc4, on 1st boot I do not get any error message.

Last line displayed is
(XEN) Xen is reliquinshing VGA console.

I was not able to find a thread with the same problem.

Would someone be able to point me to a thread explaining what I could try or 
give me some hints.

Thanks,
Alex

-- 
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/684b2a44-da75-493c-a8ef-610340141663%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GPU Passthrough Status - (Purely a meta-discussion, no specifics)

[Alex Dubois]

On Sunday, 17 December 2017 12:16:04 UTC, Tom Zander  wrote:
> On Saturday, 16 December 2017 03:25:46 CET Yuraeitha wrote:
> > Initially, this is all the reasons I can think of for wanting V-GPU.
> ...
> > - Extending a single Qubes machine around the house or company, using
> > multiple of screens, keyboards/mouses or other thinkable means.
> 
> This sounds inherently unsafe.
> Not sure what your usecase is, but there has to be a better way than 
> allowing a multitude of foreign, not-directly-connected hardware from 
> accessing various very security sensitive channels.
> 
> ...
> > - Cryptocoin miners who wish to utilize a single machine
> > for all round purposes. 
> 
> To build a proper crypto-mining rig based on GPUs, you would not run an OS 
> on the machine. It literally drains money out of your system to use it on 
> the same hardware as you main desktop.
> If you install 8 GPUs on a mainboard, you have to realize that the mainboard 
> ends up costing a fraction of the total.
> Reusing it for non-mining purposes (while mining) just doesn't make any 
> sense. Both from an economics as well as a security point of view.

I think it makes sense it you are on a budget. But you do not need GPU 
path-through, you only need CUDA interface, so I believe it is already feasible 
today.

Use the integrated GPU for Dom0 and all your work VMs.
Have a MiningVM with all the other GPU attached to it.
However ,you probably want a kvm switch to distance yourself from your new 
radiator and noise generator.
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/13948b3c-f21f-45ae-ae87-20593c6d424e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?

[Alex Dubois]

On Tuesday, 6 February 2018 23:22:26 UTC, awokd  wrote:
> On Tue, February 6, 2018 11:09 pm, Alex Dubois wrote:
> 
> > I do not address the main part because I believe there is a bug with
> > /rw/config/qubes-firewall-user-script not triggering on network change
> > that I want to report and get an understanding on how it will be
> > addressed.
> 
> This one? https://github.com/QubesOS/qubes-issues/issues/3260

Yes thanks found it and commented on my needs in this type of context. for 
example, I spin up a web server, I need the FirewallVM to get a hook to update 
it's firewall rules accordingly.

-- 
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/f1526012-cfa2-44bd-9165-7bdfffdd464f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?

[Alex Dubois]

On Tuesday, 6 February 2018 15:04:52 UTC, Alex Dubois  wrote:
> On Tuesday, 6 February 2018 10:32:16 UTC, awokd  wrote:
> > On Mon, February 5, 2018 6:18 pm, 'awokd' via qubes-users wrote:
> > > On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote:
> > 
> > >> If someone can figure out how to port-forward in 4.0, please do update
> > >> the docs. I never managed to get that working.
> > 
> > I see what you mean. If I follow
> > https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
> > on R4.0, I'm not getting past the first step of:
> > 
> > Verify you are cutting through the sys-net VM firewall by looking at its
> > counters (column 2)
> > 
> > iptables -t nat -L -v -n  [counters increasing]
> > 
> > iptables -L -v -n [not]
> > 
> > I wonder if it's an nft vs. iptables thing? Interestingly, this procedure
> > works fine:
> > https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
> > .
> 
> I did this doc long long ago. 4.0 has a new networking model. I've just 
> upodated to v4, I'll review it... sorry...

OK, networking is working in R4rc4, I have it working fine with a dozen of VM + 
my intranet traffic at home routing through QubesOS.

I've started to update the doc here: 
https://github.com/adubois/qubes-doc/blob/master/security/firewall.md

I am about to do a pull request for this first update.

I do not address the main part because I believe there is a bug with 
/rw/config/qubes-firewall-user-script not triggering on network change that I 
want to report and get an understanding on how it will be addressed.

-- 
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/4fd5212e-bf60-4216-b84c-2cf0d00f844c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?

[Alex Dubois]

On Tuesday, 6 February 2018 10:32:16 UTC, awokd  wrote:
> On Mon, February 5, 2018 6:18 pm, 'awokd' via qubes-users wrote:
> > On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote:
> 
> >> If someone can figure out how to port-forward in 4.0, please do update
> >> the docs. I never managed to get that working.
> 
> I see what you mean. If I follow
> https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
> on R4.0, I'm not getting past the first step of:
> 
> Verify you are cutting through the sys-net VM firewall by looking at its
> counters (column 2)
> 
> iptables -t nat -L -v -n  [counters increasing]
> 
> iptables -L -v -n [not]
> 
> I wonder if it's an nft vs. iptables thing? Interestingly, this procedure
> works fine:
> https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
> .

I did this doc long long ago. 4.0 has a new networking model. I've just 
upodated to v4, I'll review it... sorry...

-- 
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/83343bc4-e65f-42e8-be2b-426bd8f54ace%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?

[Alex Dubois]

On Monday, 5 February 2018 00:26:36 UTC, Tom Zander  wrote:
> On Monday, 5 February 2018 00:55:34 CET Unman wrote:
> > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users 
> wrote:
> > > * Having nothing but python APIs for your operating system is something
> > > that makes no sense. Python was never meant for servers, or even big
> > > applications. Finding a full-stack python developer is more rare than
> > > finding a Bitcoin C++ developer.
> > 
> > I'm not sure how much of this is just trolling.
> 
> It is not trolling.
> 
> > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc.
> > Perhaps you dont know about Eve Online? Mercurial? Blender?
> 
> Absolutely none of these use python for anywhere near the same percentage of 
> components as Qubes does.

Having developed a Yubikey component for Qubes, I prefer to use Python when 
possible for transparency. The C bit I've done are opaque to the user (unless 
he compiled his install of Qubes, and reviewed the code). Not saying it is the 
default choice but pointing that Python has this benefit.

> Google is a good example, for instance they shipped proto-buffers. Which 
> have bindings in a long list of languages (20 or so).

True that API use should be easy at least with Python and C. But C should only 
be used for core protocols.

> 
> Check wikipedia for those examples, reality is much more sobering that you 
> think.
> 
> > There are exceptional developers working in many companies -Google,
> > NASA, Astra Zeneca, to name a few, all using python. The fact that
> > you arent comfortable with it is fine, but not a reason to reject it.
> 
> Thats moving the goalpost. Naturally there are many experienced python 
> developers.
> 
> Let me re-state the point for your benefit;
> 
> Having nothing but python bindings and having practically all your 
> components written in python is without a doubt very realistically limiting 
> the amount of people you can get hacking on Qubes. Add on top of that the 
> content matter, which is highly complex and in many cases includes 
> networking or cross-VM communication or hard-core linux components and you 
> limit the amount of people even more, to the extend I mentioned above.
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/8ae3abf0-1e0a-42ac-9891-babd9d3042b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Trouble with enabling networking between two Vms

[Alex Dubois]

On Sunday, 23 October 2016 10:11:48 UTC+1, Max  wrote:
> Hi,
> 
> I am a new user of Qubes OS so apologies in advance if the question here has 
> been answered already in a separate topic (there are similar issues) and I 
> haven’t discovered this or it is not one suited to this mailing list. I am 
> running Qubes 3.2 and attempting to ping from one VM to another VM, 
> specifically from a Standalone Windows 7 VM to a Qubes VM based on the Debian 
> 8 template.
> 
> All my VM’s were initially connected in the default manner i.e. to a 
> sys-firewall and through to the sys-net VM, both of which are Fedora 23. 
> There are no firewall rules on these VMs restricting which IP addresses can 
> be accessed.
> 
> Current status:
> - I am able to ping from my Windows 7 VM (10.137.2.19) to the Firewall VM 
> (10.137.1.8) using the IP address visible in the VM Manager
> 
> - I am unable to ping the Debian 8 VM (10.137.2.18) from my Windows VM. 
> 
> Steps taken:
> 1) I followed the instructions here 
> (https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms)
>  and in the firewall VM’s terminal enter the following iptables rule...
> 
> sudo iptables -I FORWARD 2 -s  -d  Debian 8 VM> -j ACCEPT
> 
> … In VM B’s terminal (Debian 8) I entered the following iptables rule...
> 
> sudo iptables -I INPUT -s  -j ACCEPT
> 
> ...but from here when using the ping function to my Debian 8 VM in the cmd 
> prompt in Windows, all packets were lost.
> 
> 2) As this was not successful I attempted to see if I could connect to VMs 
> from an external machine and followed the instructions here 
> https://www.qubes-os.org/doc/qubes-firewall/#port-forwarding-to-a-vm-from-the-outside-world.
> 
> The Eth0 IP address (192.168.1.6) appeared to be what I should expose the 
> service to.
> 
> I put the below rule in the sys-net VM’s Terminal...
> 
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.x -j 
> DNAT --to-destination 10.137.1.x
> 
> ...and this rule into the sys-firewall VM’s Terminal
> 
> iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack 
> --ctstate NEW -j ACCEPT
> 
> But using ping or Telnet resulted in lost packets and failed to increase the 
> counters when using the iptables -t nat -L -v -n command in the sys-firewall 
> VM's terminal.
> 
> 3) With this not being successful either I attempted to add a “sys-proxy” VM 
> as described here 
> https://groups.google.com/forum/#!searchin/qubes-users/intervm%7Csort:relevance/qubes-users/lA2SgPcV9fU/U969uapYAAAJ
>  and entered the following in the new sys-proxy VM's terminal:
> 
> iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d 
> $intervm_internalnet/24 -m state --state NEW -p tcp -m tcp -j ACCEPT
> 
> iptables -I FORWARD 1 -i vif+ -o vif+ -s $intervm_internalnet/24 -d 
> $intervm_internalnet/24 -p udp -m udp -j ACCEPT
> 
> After this, I was still unable to ping the Debian 8 VM from my Windows VM.
> 
> Questions:
> 
> 1) Are there any obvious errors in the steps I took and does anyone have any 
> suggestions how I can resolve this issue?
> 
> 2)  There are a number of other incidences of what seemed to be a similar 
> issue here: 
> https://groups.google.com/forum/?nomobile=true#!msg/qubes-users/59kOjfQFBI4/bjS47-jJJgAJ,
>  https://groups.google.com/forum/#!msg/qubes-users/vSyUaOSloYU/ONZNJlhrBAAJ. 
> Are the enabling networking between VMs steps described here still correct 
> and applicable for Qubes 3.2?
> 
> 3) The IP address assignment suggests that the VMs are on the same network – 
> the Subnet Mask is 255.255.255.0 so surely any devices with an IP address of 
> 10.137.2.x would be able to communicate with each other? What is unique in 
> Xen / Qubes that stops this?
> 
> 4) Is there a way in which the current routing rules can be displayed and 
> reset back to the default if required?

Hi Max,

The documentation on how to open networking between 2 qubes is misleading as it 
probably open much more than required and incomplete.
Could you please specify what you want to do between these 2 VM (which port you 
want to open)? as I suppose you want more than pinging...

-- 
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/085ef9b6-1377-4ef2-8212-5798a62b8866%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > > On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > > Not familiar with this ... Will need procediure to follow.
> > > > 
> > > > 
> > > > Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > > > On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > > > > No, I am still under R3.2
> > > > > > 
> > > > > > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > > > > >
> > > > > > > >
> > > > > > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > > > > >
> > > > > > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > > > > >>
> > > > > > > >>> Nobody ?
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit 
> > > > > > > >>> :
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>> Hi,
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> I am going to install a new sys-usb.
> > > > > > > >>>> I have before to install all what I need to the template 
> > > > > > > >>>> (fedora-26)
> > > > > > > >>>>  first. When following your procedure:
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> ykpers has been installed but: I cannot do the same for
> > > > > > > >>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > > > > >>>>
> > > > > > > >>>> no match for argument
> > > > > > > >>>>
> > > > > > > >>>> ideas ?
> > > > > > > >>
> > > > > > > >> Not quite sure what you are trying to do here. What procedure? 
> > > > > > > >> What
> > > > > > > >> command are you entering?
> > > > > > > 
> > > > > > > Are you trying this on Qubes 4.0? Those Yubikey packages might 
> > > > > > > not be in
> > > > > > > the Qubes repo yet.
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I have not maintained this for some time. So long that I can't 
> > > > > remember if the packages had been created/tested, I don't think they 
> > > > > have.
> > > > > 
> > > > > Best is you follow the steps to build it on a new temporary VM, don't 
> > > > > be afraid it should not be too hard:
> > > > > - Execute the yum command in "Build dependancies"
> > > > > - Also install pam-devel
> > > > > - Follow the steps in preparing the build and build
> > > > > - Deploy the code in Dom0 and the USB VM.
> > > > > 
> > > > > I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> > > > > probably be able to help until this is done.
> > > > > 
> > > > > Any help from someone who is used to packaging under Fedora would be 
> > > > > nice.
> > > > > 
> > > > > Alex
> > > 
> > > Sure, I'll update the doc and post here. However as I said don't want to 
> > > touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 
> > > 2-3weeks
> > 
> > Did you upgrade to Q4R4 ?
> 
> I'm in the process. Having issues with PCI path-through of my second NIC that 
> I need to solve. I have to use PV mode for now and not too happy to have too. 
> I'll open another thread if I can't find a way...

Stupid error... My VM had both a NIC in pass-through and a netVM assigned which 
was the problem. So I am not stuck on this any more.

However I have a lot of VM to put back on track (IP scheme has changed, and 
probably few other small issues will crop up) and will be off for 2 weeks.

But I have not forgotten...

-- 
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/fd0bad58-87a2-4b32-ab63-6ac00e56bc2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > Not familiar with this ... Will need procediure to follow.
> > > 
> > > 
> > > Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > > On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > > > No, I am still under R3.2
> > > > > 
> > > > > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > > > >
> > > > > > >
> > > > > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > > > >
> > > > > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > > > >>
> > > > > > >>> Nobody ?
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>> Hi,
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> I am going to install a new sys-usb.
> > > > > > >>>> I have before to install all what I need to the template 
> > > > > > >>>> (fedora-26)
> > > > > > >>>>  first. When following your procedure:
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> ykpers has been installed but: I cannot do the same for
> > > > > > >>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > > > >>>>
> > > > > > >>>> no match for argument
> > > > > > >>>>
> > > > > > >>>> ideas ?
> > > > > > >>
> > > > > > >> Not quite sure what you are trying to do here. What procedure? 
> > > > > > >> What
> > > > > > >> command are you entering?
> > > > > > 
> > > > > > Are you trying this on Qubes 4.0? Those Yubikey packages might not 
> > > > > > be in
> > > > > > the Qubes repo yet.
> > > > 
> > > > Hi,
> > > > 
> > > > I have not maintained this for some time. So long that I can't remember 
> > > > if the packages had been created/tested, I don't think they have.
> > > > 
> > > > Best is you follow the steps to build it on a new temporary VM, don't 
> > > > be afraid it should not be too hard:
> > > > - Execute the yum command in "Build dependancies"
> > > > - Also install pam-devel
> > > > - Follow the steps in preparing the build and build
> > > > - Deploy the code in Dom0 and the USB VM.
> > > > 
> > > > I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> > > > probably be able to help until this is done.
> > > > 
> > > > Any help from someone who is used to packaging under Fedora would be 
> > > > nice.
> > > > 
> > > > Alex
> > 
> > Sure, I'll update the doc and post here. However as I said don't want to 
> > touch my Qubes set-up before my upgrade to 4.0 rc4. So might be in 2-3weeks
> 
> Did you upgrade to Q4R4 ?

I'm in the process. Having issues with PCI path-through of my second NIC that I 
need to solve. I have to use PV mode for now and not too happy to have too. 
I'll open another thread if I can't find a way...

-- 
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/ea2f1c06-b609-4e95-bad5-51ed3b6b9226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Slow network speed outside netvm

[Alex Dubois]

On Wednesday, 31 January 2018 12:15:01 UTC, Jarle Thorsen  wrote:
> Alex Duboise:
> > Interested to find out too. Have you tried from FirewallVM?
> 
> Same slow performance when iperf is run from a FirewallVM that is connected 
> to the netvm.
> 
> > Could you also test what happen when during the load test you start a 
> > disposable VM? Does it drop 
> 
> Running iperf in the netvm, and starting a disposable vm using the same netvm 
> there is no performance drop. (I get 8+ Gbit running one thread, and about 
> 9,5Mbit when using multiple threads)

Thanks for testing and for the SG module I didn't know before this thread. I'll 
have to dig into my pb...

-- 
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/4752302e-276b-4c1d-a60f-a7fc76a1830e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Networking unavailable on Dell XPS 9350, QubesOS 4

[Alex Dubois]

On Wednesday, 31 January 2018 08:28:01 UTC, jay...@gmail.com  wrote:
> So... no go?

For the wireless you could check support for it with Fedora community (netVM 
runs Fedora 26).

-- 
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/c740537f-a1cc-4d47-a037-b9b08d9efee8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 Documentation

[Alex Dubois]

On Friday, 26 January 2018 03:36:33 UTC, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-01-25 12:28, awokd wrote:
> > Resuming working my way through splitting up the documentation now 
> > that the 3.2 vs. 3.3 question has been mostly settled. Some
> > general questions:
> > 
> > 1. Should I open an issue for tracking and move the discussion
> > over there? Move to qubes-devel? Keep here?
> 
> Please open an issue in qubes-issues.
> 
> (Doing so does not preclude discussion here or on qubes-devel.)
> 
> > 2. The command line tools in particular 
> > (https://www.qubes-os.org/doc/vm-tools/ and 
> > https://www.qubes-os.org/doc/dom0-tools/) seem Wrong to try to 
> > share the same pages for 3.2 and 4.0. Not only is the selection of 
> > commands slightly different between versions, but many have 
> > slightly different options ("-a" vs. "a"). I'm thinking of copying 
> > all the existing pages, appending "4" so they can be linked to 
> > directly, and putting in their own section. Thoughts?
> 
> Those pages are automatically generated from the man pages stored with
> the tools' source code in their own respective repos, so any changes
> to those pages in qubes-doc will be overwritten. Changes should be
> made to the original files instead. That way, the changes will persist
> when the qubes-doc versions are automatically generated.
> 
> I agree that the tool man pages should not be shared between 3.2 and
> 4.0 (but they probably wouldn't be anyway, due to the nature of the
> system just described).
> 
> > 3. Some of these documents are pretty outdated. Should we have an 
> > Archive link and move stuff like 
> > https://www.qubes-os.org/doc/template/fedora/upgrade-18-to-20/ to 
> > it so it doesn't clutter up the main Docs page?
> > 
> There are two categories of outdated documents:
> 
> 1. Documents that we want updated (but that no one has updated yet).
> 2. Documents that are about old topics (but are otherwise good).
> 
> I don't think it would make sense to move documents of category 1 into
> an archive section, since that would incorrectly suggest that we don't
> want or expect them to be updated.
> 
> The old Fedora upgrade documents fall into category 2. However, it
> looks like they (and perhaps the release notes for unsupported Qubes
> versions) are the only major offenders visible in the main table of
> contents. This is understandable, since a new version of the document
> gets added each time there's a new version of the corresponding
> software. I think it makes sense to handle these cases specifically,
> by creating a page that collects all the versions of each one. I'll do
> this now.
> 
> In general, it's worth thinking about whether we even want to keep
> severely outdated category 2 documentation around. Does it have any
> value anymore, or will it just produce misleading search results?
> (Note that it will all remain permanently archived in the git revision
> history, so it's mainly a question of visibility on the website.)
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpqojUACgkQ203TvDlQ
> MDDG4Q//Q6ND5fzToFv6KKQn4SzkcUSIIZQKtMPTlG9BkC7UCgjFZ+7sxrLA1N5X
> H+9Z88+QNRL6FBOa6DHpFZOOA6vomzw0HXkTF+g9VcplsJIFZh6iB7lpSta1XwKU
> 1DG+ayF0oDd8PxKtSjaslMWRsr9p9cApPM7G+z6sGLB34LLZfolx19FRhwcpfBBK
> 09wyaAzmr5sF9oO8rSxC1llz5u75GatXUu+tHIc3Jh9C4hBtX7MSwyoq7eTkXnKQ
> VpS35O8thmhm6cEuyNQsUD7ia853lWRcdTur1Am7GIx3jwl7VBQ6YCqanLRLueaI
> tm4LbBfNrZcxFexHp0mB+veDeIfkC4cJZm8/sbjrHEicK6Cuvp5E0E6iLOaMw9gI
> y3D1ypbEwMXyYQFPWW0h488pNow9RCrTHTcvBhgyIBw0xhCe0j89RZpbV3UB79k1
> n5YRoj36XXRmHho/KVIlFMrzsXE6q9sawU8P1/Q7mBjX3fQLDoOEwFMtHRZTiFLk
> NOkqv328xsqJy1smKgfFI4cpNMa1+Be0zGjqRWjBFNTqWEoNPkAbDbhbiwYPZYop
> CW0lDS6b6dc2KCMcxlP+3BwuFC+pS9Yw/Qw2B0yceVjrH0YnLoVkOaqC6ojGx6DH
> JAFtJLB6FbXssbK3JASOvGKpMxcktfQe3quJZmTaMY2yLkBaomA=
> =8MfO
> -END PGP SIGNATURE-

Happy to contribute. maybe we can have a direct conversation so that we can 
discuss what is needed and where I feel comfortable...

-- 
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/134582e1-f89b-47d3-8176-68de4fd88851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] my mouse is dead

[Alex Dubois]

On Wednesday, 24 January 2018 15:26:05 UTC, Ivan Mitev  wrote:
> On 01/24/18 12:06, Alex Dubois wrote:
> > On Tuesday, 23 January 2018 20:34:20 UTC, Ivan Mitev  wrote:
> >> On 01/23/18 21:52, evo wrote:
> >>> Hey!
> >>>
> >>> my mouse doesn't react, nothing happens.
> >>> Can somebody help please?
> >>
> >> external mouse ? laptop's track{pad,point} ? never worked at all or
> >> stopped working ?
> >>
> >> if external mouse: restart sys-usb and/or make sure that sys-usb has the
> >> qubes-input-proxy-sender rpm package installed (dom0 should have
> >> qubes-input-proxy installed by default).
> > 
> > Mouse should not use sys-usb, this USB should be for untrusted usb devices. 
> > The mouse should be on a dedicated controller.
> 
> err ??
Dom0 does not have access to sys-usb, so this is why your mouse does not work.

> 
> I don't see what kind of security gain you get from using your mouse on 
> a different controller (if you have the chance to have several ones, 
> that is). The worst cases would be that:
> 
> - you use your mouse to enter sensitive stuff on a virtual keyboard; but 
> 1- the attacker has no way to know the screen location and layout of 
> your virtual keyboard, and 2- even if he managed to understand what you 
> "typed" it would be very difficult for him to get that info back because 
> sys-usb isn't networked.



> 
> - your compromised external mouse advertises itself as a keyboard and 
> issue commands on your behalf (is that even possible?). But the mouse 
> doesn't know which window is focused, what app you're using, etc., so 
> the chance that its "commands" ever do something bad to your system 
> without you noticing anything is close to 0.
[Ctrl] + [Esc]
6x [Down]
your mouse can play around ;) (on XFCE)

My point was that you have trusted IHM devices (Keyboard, Mouse, Graphics card) 
that Dom0 connect to and non-trusted (such as sys-net sys-usb). Apologies if it 
came across badly.

> 
> 
> > In Dom0:
> > lsusb
> > should give you the controller bound to it. The mouse (and possibly 
> > keyboard) needs to be attached to one of the port of that controller. The 
> > other ports should be bound to controllers attached to sys-usb.
> > But in general the keyboard and mouse are PS2 attached I think...
> 
> The OP mentioned having a problem with his mouse, hence the question 
> about external vs. integrated. If it is integrated, then the problem is 
> likely not sys-usb (except if his laptop's keyb/mouse is USB but I 
> haven't seen this yet). If it is external, then either the mouse is 
> broken or something's amiss with qubes' input proxy.

-- 
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/54b1b391-00c3-444e-b15e-e4d741eaea62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] my mouse is dead

[Alex Dubois]

On Tuesday, 23 January 2018 20:34:20 UTC, Ivan Mitev  wrote:
> On 01/23/18 21:52, evo wrote:
> > Hey!
> > 
> > my mouse doesn't react, nothing happens.
> > Can somebody help please?
> 
> external mouse ? laptop's track{pad,point} ? never worked at all or 
> stopped working ?
> 
> if external mouse: restart sys-usb and/or make sure that sys-usb has the 
> qubes-input-proxy-sender rpm package installed (dom0 should have 
> qubes-input-proxy installed by default).

Mouse should not use sys-usb, this USB should be for untrusted usb devices. The 
mouse should be on a dedicated controller.

In Dom0:
lsusb
should give you the controller bound to it. The mouse (and possibly keyboard) 
needs to be attached to one of the port of that controller. The other ports 
should be bound to controllers attached to sys-usb.
But in general the keyboard and mouse are PS2 attached I think...

-- 
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/0a892b66-09c3-4c58-ab25-9fe296b442e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

[Alex Dubois]

On Wednesday, 24 January 2018 04:30:08 UTC, Syd Brisby  wrote:
> some considerations:
> 
> * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in 
> both CPU & RAM). So running Qubes software on them at a productive speed will 
> be a challenge.

Perfectly fine as a USB decryptionVM or as a Split PGP with the benefit of not 
have your keys in CPU cache.

> 
> * You're saying that laptop hardware specs are a problem for users. But 
> remember we had the problem of wireless modules still broadcasting after 
> being turned "off". So we needed laptops with wireless hardware switches to 
> be more certain that we couldn't be hacked. But now you are asking us to 
> again trust ordinary laptops and tablets that may not have hardware switches. 
> 
> * In reality, you are also changing from "deployment and virtualization" as a 
> single point of failure to "wireless" as the single point of failure. For 
> example, WPA2 has been declared insecure (hackable), with WPA3 being 
> necessary as a replacement. But, amazingly, WPA2 is still being "patched" by 
> manufacturers who think it's still acceptable - so how long will it take for 
> WPA3 to become ubiquitous?

On the Raspberry side, wireless is a no go. Secure wired connection will be 
required (to mitigate L2 and below attacks).

On the laptop side, sys-net will mitigate L2 and lower attacks. so your GUI 
connect to your QubesAIR by connecting to sys-firewall... nothing is changing 
(with the assumption that the protocol for remoting between Qubes is secure).

-- 
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/e467b8dd-f3c6-4633-b6c6-5bcc33bae388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb

[Alex Dubois]

On Monday, 22 January 2018 21:36:46 UTC, Yuraeitha  wrote:
> The purpose is to narrow down access to an AppVM based on /dev/xvdb, keeping 
> more of the AppVM in the read-only /dev/xvda template partition. 
> 
> For example, to make an AppVM which only preserves bookmarks in /dev/xvdb 
> that normally keeps /rw /home and /usr files, where everything else is swept 
> away upon restarting the AppVM. There are other use-cases than for bookmarks, 
> whatever project one may have in mind.
> 
> For those who may need the reference, the Qubes partition read-only and 
> write-access scheme is explained here 
> https://www.qubes-os.org/doc/template-implementation/ Essentially the 
> /dev/xvda is like the template, and /dev/xvdb is like the AppVM.
> 
> It may possibly be a bit difficult to split up the path to the firefox files, 
> away from the remaining /home files, and further splitting up the firefox 
> files to only preserve the bookmarks and not the remaining firefox files. 
> This presumably complicates everything, however similar approaches can be 
> seen with /dev/xvdc which holds any modified read-only /dev/xvda files, which 
> are then discarded upon shutting down the AppVM. The other example is how the 
> Whonix AppVM is handled, which only preserves a few things, like bookmarks, 
> and erases everything else. However the Whonix approach while similar, is 
> fundamentally different too, since this process is being handled inside the 
> VM, and not outside the VM.
> 
> So the question is, can the borderline between which Linux paths are saved in 
> the read-only partition /dev/xvda and the write-access to /dev/xvdb, be 
> changed in any specific pre-installed template? And further, can everything 
> be moved back to /dev/xvda, without removing firefox folder from the 
> /dev/xvdb, or better yet, only allowing edits to the bookmarks directory only 
> while keeping the remaining firefox folder in /dev/xvda?
> 
> Whould splitting of files here require using a similar approach like the one 
> used with /dev/xvda and /dev/xvdc for system-files? Can this be done with 
> current means in Qubes?
> 
> Ideas or suggestions on if this is feasible or maybe even undesirable for any 
> unseen reason?

Could you have a process to backup your bookmarks in /home/user (i.e. every 10 
min)
And have a process on start-up to load them up?

If you are OK to create the bookmarks elsewhere you could create them in a 
"bookmark vault" and get them pushed on start-up (from Dom0, start bookmark 
vault, start browsing VM, initiate transfer of bookmarks from vault to browsign)

-- 
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/5d2f9f89-3bdd-4ae7-a966-7859c5d2a6ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes and Whonix now have next-generation Tor onion services!

[Alex Dubois]

On Tuesday, 23 January 2018 07:26:09 UTC, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> The Qubes and Whonix projects now have next-generation Tor onion
> services [1] (a.k.a. "v3 onion services"), which provide several
> security improvements [2] over v2 onion services:
> 
> Qubes:
> http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion

Is it https://www.qubes-os.org/ over tor? or is it to get Qubes updates?

> 
> Whonix:
> http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion
> 
> These services run alongside our existing ("v2") onion services:
> 
> Qubes:
> http://qubesos4z6n4.onion
> 
> Whonix:
> http://kk63ava6.onion
> 
> For instructions on accessing the new addresses and further details,
> please see the Whonix announcement [3]. Our sincere thanks go to the
> Whonix team, and especially fortasse, the Whonix server
> administrator, for doing this.
> 
> 
> [1] 
> https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services
> [2] https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
> [3] https://www.whonix.org/blog/whonix-new-v3-onion-address
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpm44UACgkQ203TvDlQ
> MDBlMg//T7lj6NCoy8YNNKDSjtkoe6WIcfdvoLFxQrIy+fmEJMQKTgKBb18kFxH4
> Q67+iyL+hvhFOCb3ss98Xj2ogrRvv4VkPypPRmmMRx7dJChpCdBylRNtx0rPslw9
> OUNHw3mj3frXjAbw4cOb2Tlsd8ANKDrQoFMaADKfenLCQnMzPpqMx4rt0Rw912Jn
> +wShCF6RM0gyUFTiqxYrPgJn0RHvSUVKlWwFCUXWVnGmvdwRy7G5bqb6/a6RrV8p
> CO3zXHM+/pclfK4ls61FyseYY2iIOLCqVid7Oez/BWqVS4ckmQWknK1juo2/Qzwm
> exNCSF2+nzGfg9v15LiOKDP/35hiqvh04y1JPUf2WbivWGUfkOpNt1rvdSHa/wjH
> f6y42Dqq5GYfcz9XGmehazKCI4/usXOpa+eH3Uar3hJD5AIe0f/3URe9LrdUgp68
> bN0WLcu9ctpAXtufhbgf2KcPwhrsB9uBqG4fBgHl9YLRgppv8tiuteKosFuhDOGE
> CpskV3izqmyLYIQ1P9u3wvM4/MZ652fBZKUD/4PNrEQuW8g6Nmv0dFD/KE2V/72G
> TME+YKVSB8Rs8Q3dfgVLw5gnF5Z3p/0i0EfM0m5LuBF4ScFGAMAVnZ+Ax61ESNkD
> 1Bv0+xS3lpTHs05Qw/MY8ecSbcZTHPqF9a8jTUmc1CMJNm5EceI=
> =cwtv
> -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/b078ded5-569d-4873-829f-de46e798bb90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

[Alex Dubois]

On Tuesday, 23 January 2018 11:57:44 UTC, Andrew Clausen  wrote:
> Hi all,
> 
> 
> 
> 
> Joanna Rutkowska has just published a new article titled "Qubes Air:
> 
> Generalizing the Qubes Architecture." The article is available both on
> 
> Joanna's blog:
> 
> 
> 
> https://blog.invisiblethings.org/2018/01/22/qubes-air.html
> 
> 
> 
> And on the Qubes website:
> 
> 
> 
> https://www.qubes-os.org/news/2018/01/22/qubes-air/
> 
> 
> I confess I found the writing a bit difficult to understand this time.  I 
> suggest adding some more example use cases.
> 
> 
> Consider the following use case -- is this what Joanna had in mind?
> 
> 
> Suppose you are a journalist, and you have received a PDF document on a USB 
> stick from an anonymous source.  Given all the recent 
> meltdown/rowhammer/spectre/xen debacles, you aren't thrilled about plugging 
> in the USB stick into your Qubes laptop.  And even if you did plug it in, you 
> wouldn't be thrilled about running the Qubes PDF converter on it either.
> 
> 
> So what do you do?
> 
> 
> On the USB front, you might buy a Raspberry Pi, and plug the USB stick into 
> that instead.  You could then scp the PDF document from the Rasbperry Pi onto 
> the Qubes laptop.  Qubes Air would make this easier by making using the 
> Raspberry Pi appear just like another USB VM (like sys-usb).
> 
> 
> You could also do the PDF conversion on the same Raspberry Pi (specifically 
> the half of the conversion that would normally run inside a disposable VM).  
> Qubes Air would also make this work smoothly, as if the disposable VM were 
> running on the Qubes laptop.
> 
> So, what are the security trade-offs?
> 
> 
> First, this Raspberry Pi arrangement means that both steps are better 
> isolated from the Qubes laptop.  Previously, a successful attack on the 
> sys-usb VM or the disposable VM could be escalated via Meltdown et al to take 
> over the whole laptop.  Now they can't.
> 
> 
> Second, the Raspberry Pi has inferior isolation within itself (e.g. no 
> IOMMU).  This means that if the journalist re-uses the same Raspberry Pi for 
> several different sources, those sources could interfere with each other.  
> For instance, if source A is malicious, it could reprogram the Raspberry Pi 
> to destroy all data from source B.
> 
> Are you hoping that Qubes Air could overcome this obstacle?  For example, are 
> you hoping that a dedicated Raspberry Pi just for disposable VMs would be 
> able to isolate all disposable VMs from each other?
> 
> Kind regards,
> Andrew

My understanding is that this paper did not explore this type of exposure. It 
is mainly focused on GUI "remoting" and compute "remoting".

The risk you exposed with the USB front-end and the lack of 
compartmentalization are a problem you are right. So the right way is still to 
put the USB stick in the laptop, however the USB VM would run in the 
RaspberryPi (a FileSystem "remoting" would be required). And for example the 
decryption of the docs in the USBVM would be protected from shared CPU cache 
types of attacks. This is my understanding... 

-- 
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/e288fe06-4474-4a37-9ded-c564dabf3d13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

[Alex Dubois]

On Monday, 22 January 2018 15:35:47 UTC, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> Joanna Rutkowska has just published a new article titled "Qubes Air:
> Generalizing the Qubes Architecture." The article is available both on
> Joanna's blog:
> 
> https://blog.invisiblethings.org/2018/01/22/qubes-air.html
> 
> And on the Qubes website:
> 
> https://www.qubes-os.org/news/2018/01/22/qubes-air/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpmBMEACgkQ203TvDlQ
> MDC02A//Qjy5eAxiUSY6ZOlTQ6zDlilXtBTbSH4ig3Wa1DL9Jg3vHnR955LP9snP
> 40ZEIIc+cACis25g61SySbzkZUHXKW1cqfQCv/mjQAApWlFxQexIhX5WpS/u8RKB
> PhNdgQVH+JYPOQZCidFAdkeSnBM+XFyxflPaCE1j1zisnTliH/Lwdl6xxEVht4nb
> XglIZZz6D6PEQIouvM3qdsqi9DUY7Nc6AC5cLsI5NbVAcYtIVILxiSlxAM2OM/SL
> k7rIoLnFGmgdmMJl5pInzy/b/SJvNmy70HjKRfg5y+EP9Wm024WaZQStacWmSfWa
> x//plXVY/AuRWycyEtWLEdIhWNw4ZBV2CGkw72IxIN2SmJ+IfDA4N0fO81WZBJxo
> gdH4Y/fkKZyUJ1/cKfttwt6jU8AOx8MZwmoh1tMjZbXuVPOoGgqBR0aXPAzAUcE2
> 5IpviczQZ0Ng9ZHyITZthiUO08nyqqJS8AH9UU4e2uDDq53TCXQa8pNzqgWtipY7
> BkGwNY+PZaf3dAfYgEyAh+IFnHRI6e38Ej0pysHSGM386B4n19tmhEf9zLjXc+oU
> 2KUQJjOTp4ISfqNDYe3HpYsMR3RrqMWyMt3h4zG1gKPLhxAjAfdzVRq+Z0sBtJya
> 2begkIa7u91kJlta2/T4N6E2bqpe9tdAzsy/StqRBnnjIsRjYlE=
> =y84I
> -END PGP SIGNATURE-

As always fantastic article and work by your team.

One point about the RDP security concerns... You could have (if 2 zones and 4 
VM in each):
2x4x AppVM --> 2x4x CouldGUI+RDPd > 2x4x RDPc+DesktopGUI --> 1 QubesGUI

--> local fast secure UI
---> compressed stream (RDP or other)

You could possible have 2x RDPc+DesktopGUI (one per zone if this is your 
security/performance model).

One point about Application as a service: I agree about browser isolation not 
being able to secure users (and certainly not able to manage privacy).
Let's just ignore user isolation in Office265 ;-)

Looking forward to what will come out. Devil is in the details.

-- 
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/77558918-6b13-4c73-ad70-867511df8699%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] Qubes Controller as the new Qubes-Manager

[Alex Dubois]

On Saturday, 6 January 2018 00:07:00 UTC, Tom Zander  wrote:
> On Friday, 5 January 2018 23:43:58 GMT Zrubi wrote:
> > > I'll attach two sceenshots of the tool, to give you a bit of an
> > > idea of what it already does and maybe if its worth your time to
> > > compile 
> > 
> > Probably this is very subjective, but:
> > For me, the most important parts/feature of the current Qubes Manager
> > are (in order of importance):
> > 
> > - Full overview of the state of the VMs in ONE screen, without clicking.
> > The new widget is failing on this badly, just as your proposal.
> 
> My aim has so far been to show which VMs are there, which type they are and 
> if they are running. This is visible in one go. Including even which VM has 
> a high CPU usage.
> I'm not happy yet with the way that the netVM is visualized, as you say it 
> costs clicks on each VM.
> 
> > - Changing the NetVM of a given VM.
> 
> Great idea!

Tom, Thanks for putting time into this. It will be greatly appreciated by many.
On that specific point, the disposable template could have the start icons with 
the program you want, and maybe a drop down for the netVM, or tab, or just for 
a given program you can select the netVM (i.e. firefox, tor (via whonix), 
openoffice (no netvm)...
>  
> > - Starting programs from a given VM.
> 
> Fully agreed, this is what I added last week. I'm using it all the time. 
> Much more convenient than the start menu.
> 
> > - start/stop VMs
> 
> Present :)
>  
> > - attaching/detaching devices.
> 
> Yes, definitely.
> 
> > - reading VM logs.
> 
> Good to know.
> 
> > Probably these are only my personal preferences. Hence I have no time
> > to write a new manager for the Qubes 4.x I just shared my use case.
> > Feel free to ignore them if you don't like 'em 
> 
> They are excellent ideas, thanks!

Not sure if feasible but:
- launch it with a shortcut key
- execute the task (i.e. select VM, select program to launch, or command to 
execute on that VM)
- minimize automatically on task execution (plus same shortcut if no action)

> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/0b59f740-a1be-4dd2-b543-4a43766ce474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GPU?

[Alex Dubois]

On Saturday, 20 January 2018 09:40:36 UTC, Foppe de Haan  wrote:
> On Saturday, January 20, 2018 at 9:38:06 AM UTC+1, Alex Dubois wrote:
> > On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> > > On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > > > Is qubes able to use the computing power of the gpu or is the type of 
> > > > gpu
> > > > installed a waste in this issue?
> > > 
> > > Relevant here is an email I wrote recently;
> > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > 
> > I'll reply in that thread about this to stay in topic.
> > 
> > But in few words: Not possible until GPU virtualization to have a trustable 
> > solution.
> > 
> > > 
> > > The context is a GSoC proposal proposal to modernize the painting 
> > > pipeline of Qubes.
> > > 
> > > Today GL using software uses [llvmpipe] to compile and render GL inside 
> > > of 
> > > a Qube, completely in software and then push the 2d image to dom0.
> > > This indeed wastes the GPU.
> > > 
> > > 
> > > [llvmpipe]: 
> > > https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> > > 
> > > -- 
> > > Tom Zander
> > > Blog: https://zander.github.io
> > > Vlog: https://vimeo.com/channels/tomscryptochannel
> 
> Since I am unable to estimate the security aspects of any given approach, and 
> you do, have you seen this approach? 
> https://forum.level1techs.com/t/looking-glass-guides-help-and-support/122387

I am not member of the Qubes core team, I am an avid user/developer and 
believer :) so my view is only mine...
The project you mention is doing a great job (for a VMWare workstation type 
set-up), however as far as I understood the copy is from/to the same GPU. This 
is where I am NOT comfortable with. As explained the client VM would issue 
processing requests to the GPU (and may abuse it).

However, using their work to copy from one GPU (assigned to ONE VM) to Dom0 GPU 
could be good. However you still have the problem with the BW on the bus 
(luckily depending on your hardware build 2 different buses (your 2 cards are 
on different PCIe lines). You will not get 144Hz but 60Hz is within reach. 
Temptation to compress the stream will be there, the decompression code will be 
in the attack surface.

-- 
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/553b21c0-cc0c-47f6-b9e1-2ba03762164f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Moving dom0 screenshots immediately to VMs

[Alex Dubois]

On Saturday, 20 January 2018 06:21:36 UTC, Jean-Philippe Ouellet  wrote:
> On Fri, Jan 19, 2018 at 3:55 AM,   wrote:
> > I've been working on a solution for this, but unfortunately there are too 
> > many factors that I'm not familiar with.
> >
> > My goal is to to able to:
> >
> > 1) Take a screenshot using the dom0 hotkey
> > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
> > option
> > 3) A text entry box that prompts me for the destination VM
> > 4) The screenshot is sent to the indicated VM
> >
> > I think this can be accomplished with
> >
> > .desktop application file
> > zenity
> > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
> >
> > but I'm lost in the details.
> >
> > Current problems
> >
> > - I can't get dom0 to include my .desktop application files as "Open with:" 
> > options in the "Screenshot" dialogue
> > - I'm not sure what format the screenshot is in initially... will the 
> > .desktop application receive a bunch of bits? Or the path to a temporary 
> > file?
> > - I can figure out how to pipe the screenshot if it's a file, but I don't 
> > know how to handle a "bunch of bits" scenario
> >
> > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> > looks great, but the code is too complicated for me to review and I just 
> > need basic functionality anyway. 
> > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
> 
> This problem has already been solved, but upstreaming it was stalled
> for some policy reasons. See here:
> https://github.com/QubesOS/qubes-issues/issues/953
> 
> My implementation can be found here:
> https://github.com/jpouellet/qubes-screenshot-helper
> 
> Regards,
> Jean-Philippe

Ah great. I like this implementation. Reviewing the code it does not seem to 
introduce any risk and provide all the functionality required.

Could you explain briefly the steps to install (after the git pull).

May I also ask you for some help/pointer on a yubikey package I've done. I just 
need to do the packaging and it may save me some time if you were to give me 
few pointers...

Project is here... the doc state that it is packages, but it is not (yet)...
https://github.com/adubois/qubes-app-linux-yubikey

Please reply in that thread if you want:
https://groups.google.com/forum/#!topic/qubes-users/BkdTuXZZnwE

-- 
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/7ee007f3-e478-469b-90f5-f3f140275fa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GPU?

[Alex Dubois]

On Thursday, 18 January 2018 22:56:10 UTC, Tom Zander  wrote:
> On Sunday, 14 January 2018 08:12:24 CET r...@tuta.io wrote:
> > Is qubes able to use the computing power of the gpu or is the type of gpu
> > installed a waste in this issue?
> 
> Relevant here is an email I wrote recently;
> https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ

I'll reply in that thread about this to stay in topic.

But in few words: Not possible until GPU virtualization to have a trustable 
solution.

> 
> The context is a GSoC proposal proposal to modernize the painting 
> pipeline of Qubes.
> 
> Today GL using software uses [llvmpipe] to compile and render GL inside of 
> a Qube, completely in software and then push the 2d image to dom0.
> This indeed wastes the GPU.
> 
> 
> [llvmpipe]: 
> https://groups.google.com/forum/#!msg/qubes-devel/40ImS390sAw/Z7M0E8RiAQAJ
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/bde05d64-6516-432a-8a2b-120ee64797cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Moving dom0 screenshots immediately to VMs

[Alex Dubois]

On Friday, 19 January 2018 19:37:43 UTC, Yethal  wrote:
> W dniu piątek, 19 stycznia 2018 20:00:27 UTC+1 użytkownik Alex Dubois napisał:
> > On Friday, 19 January 2018 17:52:41 UTC, Alex Dubois  wrote:
> > > On Friday, 19 January 2018 12:05:36 UTC, Tom Zander  wrote:
> > > > On Friday, 19 January 2018 12:48:27 CET wordswithn...@gmail.com wrote:
> > > > > Qubes already has built-in the capability to screenshot the entire 
> > > > > desktop
> > > > > (Printscreen)  or the current window (Ctrl+Printscreen).
> > > > 
> > > > Yes, it does.
> > > > 
> > > > But this is not something you should use and then send to a VM becuase 
> > > > that 
> > > > VM then suddenly gets knowledge about all the other windows on screen 
> > > > that 
> > > > may be from another VM.
> > > 
> > > Default should prevent, but user should have choice.
> > > 
> > > > 
> > > > Imagine having your Vault VM window open with all your passwords and 
> > > > then 
> > > > you auto-upload a screenshot of that into a compromised VM which then 
> > > > causes 
> > > > the screenshot to be uploaded to a server.
> > > > 
> > > > I'm not aware of any way to avoid this data-leakage using the 
> > > > screenshot 
> > > > application in dom0.
> > > > -- 
> > > > Tom Zander
> > > > Blog: https://zander.github.io
> > > > Vlog: https://vimeo.com/channels/tomscryptochannel
> > > 
> > > XFCE (default Qubes Windows manager) provides a screenshot application 
> > > (Menu/System Tools/Screenshot activated with the PrintScreen Key as well)
> > > This launch a windows with:
> > > - Region to capture (radio selection)
> > >   - Entire screen (selected by default)
> > >   - Active window
> > >   - Select a region
> > > - Delay before capturing
> > >   - X seconds (default is 1)
> > > - Capture mouse pointer
> > >   - Y/N (default Y)
> > > 
> > > What I think needs to be done:
> > > - Change the default for region to capture to "active window"
> > > - Also
> > >   - hook into screenshot so that either
> > > - when OK (or Enter key) is pressed
> > >   - the Save As dialog is replace by another one where you put the VM 
> > > name (and it goes into QubesIncoming in that VM, for Dom0 into 
> > > /home/user/screenshots)
> > > - Dom0 Confirmation pop-up appear (same as usual copy/move file) 
> > > with a preview (TBC)?
> > >OR - the Save As dialog has a kind of "network drive list" which is 
> > > the list of VMs that are running, and saving there save to QubesIncoming 
> > > for that VM. You have to prevent the create directory and other stuff 
> > > probably. Benefit is that it is probably re-usable for any Dom0 apps 
> > > which use the Save As window.
> > 
> > OK for the impatient, this will send a screenshot of the current window to 
> > a VM (no selection of target VM for the moment):
> > 
> > 1- Bind shortcut key:
> > Click on: Menu/System Tools/Keyboard
> > Click on: Application Shortcuts tab
> > Click on Add
> > Command: xfce4-screenshooter -w -o /usr/local/bin/screenshooter.sh
> > Bind to Ctrl + Shift + PrintScreen (or whatever you want)
> > 
> > 2- Create script that will copy the file to the target VM
> > in Dom0 terminal
> > sudo vi /usr/local/screenshooter.sh
> > 
> > #!/bin/bash
> > cat $1  qvm-run --pass-io  "cat > /home/user/`echo $1 | awk -F'/' 
> > '{print $3}'`"
> > 
> > where  is the started VM that will receive the screenshot. You can 
> > obviously choose a path that user has write access to. You may want to 
> > clean the file that is save by default in /tmp by adding this line
> > rm /tmp/`echo $1 | awk -F'/' '{print $3}'`"
> > 
> > 3- Make the script executable
> > sudo chmod a+x /usr/local/bin/screenshooter.sh
> 
> there is the qvm-screenshot-tool. Is that not enough?

Never heard of it. In which package is-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/6eee5e16-6440-428a-82ac-919ed3f7405a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Moving dom0 screenshots immediately to VMs

[Alex Dubois]

On Friday, 19 January 2018 17:52:41 UTC, Alex Dubois  wrote:
> On Friday, 19 January 2018 12:05:36 UTC, Tom Zander  wrote:
> > On Friday, 19 January 2018 12:48:27 CET wordswithn...@gmail.com wrote:
> > > Qubes already has built-in the capability to screenshot the entire desktop
> > > (Printscreen)  or the current window (Ctrl+Printscreen).
> > 
> > Yes, it does.
> > 
> > But this is not something you should use and then send to a VM becuase that 
> > VM then suddenly gets knowledge about all the other windows on screen that 
> > may be from another VM.
> 
> Default should prevent, but user should have choice.
> 
> > 
> > Imagine having your Vault VM window open with all your passwords and then 
> > you auto-upload a screenshot of that into a compromised VM which then 
> > causes 
> > the screenshot to be uploaded to a server.
> > 
> > I'm not aware of any way to avoid this data-leakage using the screenshot 
> > application in dom0.
> > -- 
> > Tom Zander
> > Blog: https://zander.github.io
> > Vlog: https://vimeo.com/channels/tomscryptochannel
> 
> XFCE (default Qubes Windows manager) provides a screenshot application 
> (Menu/System Tools/Screenshot activated with the PrintScreen Key as well)
> This launch a windows with:
> - Region to capture (radio selection)
>   - Entire screen (selected by default)
>   - Active window
>   - Select a region
> - Delay before capturing
>   - X seconds (default is 1)
> - Capture mouse pointer
>   - Y/N (default Y)
> 
> What I think needs to be done:
> - Change the default for region to capture to "active window"
> - Also
>   - hook into screenshot so that either
> - when OK (or Enter key) is pressed
>   - the Save As dialog is replace by another one where you put the VM 
> name (and it goes into QubesIncoming in that VM, for Dom0 into 
> /home/user/screenshots)
> - Dom0 Confirmation pop-up appear (same as usual copy/move file) with 
> a preview (TBC)?
>OR - the Save As dialog has a kind of "network drive list" which is the 
> list of VMs that are running, and saving there save to QubesIncoming for that 
> VM. You have to prevent the create directory and other stuff probably. 
> Benefit is that it is probably re-usable for any Dom0 apps which use the Save 
> As window.

OK for the impatient, this will send a screenshot of the current window to a VM 
(no selection of target VM for the moment):

1- Bind shortcut key:
Click on: Menu/System Tools/Keyboard
Click on: Application Shortcuts tab
Click on Add
Command: xfce4-screenshooter -w -o /usr/local/bin/screenshooter.sh
Bind to Ctrl + Shift + PrintScreen (or whatever you want)

2- Create script that will copy the file to the target VM
in Dom0 terminal
sudo vi /usr/local/screenshooter.sh

#!/bin/bash
cat $1  qvm-run --pass-io  "cat > /home/user/`echo $1 | awk -F'/' 
'{print $3}'`"

where  is the started VM that will receive the screenshot. You can 
obviously choose a path that user has write access to. You may want to clean 
the file that is save by default in /tmp by adding this line
rm /tmp/`echo $1 | awk -F'/' '{print $3}'`"

3- Make the script executable
sudo chmod a+x /usr/local/bin/screenshooter.sh


-- 
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/476d0c3b-7cff-4245-802f-a77815f15cbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Moving dom0 screenshots immediately to VMs

[Alex Dubois]

On Friday, 19 January 2018 12:05:36 UTC, Tom Zander  wrote:
> On Friday, 19 January 2018 12:48:27 CET wordswithn...@gmail.com wrote:
> > Qubes already has built-in the capability to screenshot the entire desktop
> > (Printscreen)  or the current window (Ctrl+Printscreen).
> 
> Yes, it does.
> 
> But this is not something you should use and then send to a VM becuase that 
> VM then suddenly gets knowledge about all the other windows on screen that 
> may be from another VM.

Default should prevent, but user should have choice.

> 
> Imagine having your Vault VM window open with all your passwords and then 
> you auto-upload a screenshot of that into a compromised VM which then causes 
> the screenshot to be uploaded to a server.
> 
> I'm not aware of any way to avoid this data-leakage using the screenshot 
> application in dom0.
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

XFCE (default Qubes Windows manager) provides a screenshot application 
(Menu/System Tools/Screenshot activated with the PrintScreen Key as well)
This launch a windows with:
- Region to capture (radio selection)
  - Entire screen (selected by default)
  - Active window
  - Select a region
- Delay before capturing
  - X seconds (default is 1)
- Capture mouse pointer
  - Y/N (default Y)

What I think needs to be done:
- Change the default for region to capture to "active window"
- Also
  - hook into screenshot so that either
- when OK (or Enter key) is pressed
  - the Save As dialog is replace by another one where you put the VM name 
(and it goes into QubesIncoming in that VM, for Dom0 into 
/home/user/screenshots)
- Dom0 Confirmation pop-up appear (same as usual copy/move file) with a 
preview (TBC)?
   OR - the Save As dialog has a kind of "network drive list" which is the list 
of VMs that are running, and saving there save to QubesIncoming for that VM. 
You have to prevent the create directory and other stuff probably. Benefit is 
that it is probably re-usable for any Dom0 apps which use the Save As window.

-- 
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/debe5877-ca0e-4d90-a4d4-f637f82c395d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Moving dom0 screenshots immediately to VMs

[Alex Dubois]

On Friday, 19 January 2018 08:55:27 UTC, wordsw...@gmail.com  wrote:
> I've been working on a solution for this, but unfortunately there are too 
> many factors that I'm not familiar with.
> 
> My goal is to to able to:
> 
> 1) Take a screenshot using the dom0 hotkey
> 2) In the "Screenshot" dialogue, select a script from the "Open with:" option
> 3) A text entry box that prompts me for the destination VM
> 4) The screenshot is sent to the indicated VM
> 
> I think this can be accomplished with
> 
> .desktop application file
> zenity
> qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
> 
> but I'm lost in the details.
> 
> Current problems
> 
> - I can't get dom0 to include my .desktop application files as "Open with:" 
> options in the "Screenshot" dialogue
> - I'm not sure what format the screenshot is in initially... will the 
> .desktop application receive a bunch of bits? Or the path to a temporary file?
> - I can figure out how to pipe the screenshot if it's a file, but I don't 
> know how to handle a "bunch of bits" scenario
> 
> Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
> looks great, but the code is too complicated for me to review and I just need 
> basic functionality anyway. 
> https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh

This could be useful feature. Happy to help for the dev part...

What do you think about the default behavior being to:
- screen-shot only a VM window? Is it available?
- screen-shot an area that you lasso?

I'm suggesting these because the Qubes default should always be the safest that 
can be implemented...

-- 
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/356b8415-4788-4b7e-bc7d-6a552706fb47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> Not familiar with this ... Will need procediure to follow.
> 
> 
> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > > No, I am still under R3.2
> > > 
> > > Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > > > >
> > > > >
> > > > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > > >
> > > > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > > >>
> > > > >>> Nobody ?
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
> > > > >>>
> > > > >>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> I am going to install a new sys-usb.
> > > > >>>> I have before to install all what I need to the template 
> > > > >>>> (fedora-26)
> > > > >>>>  first. When following your procedure:
> > > > >>>>
> > > > >>>>
> > > > >>>> ykpers has been installed but: I cannot do the same for
> > > > >>>> qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > >>>>
> > > > >>>> no match for argument
> > > > >>>>
> > > > >>>> ideas ?
> > > > >>
> > > > >> Not quite sure what you are trying to do here. What procedure? What
> > > > >> command are you entering?
> > > > 
> > > > Are you trying this on Qubes 4.0? Those Yubikey packages might not be in
> > > > the Qubes repo yet.
> > 
> > Hi,
> > 
> > I have not maintained this for some time. So long that I can't remember if 
> > the packages had been created/tested, I don't think they have.
> > 
> > Best is you follow the steps to build it on a new temporary VM, don't be 
> > afraid it should not be too hard:
> > - Execute the yum command in "Build dependancies"
> > - Also install pam-devel
> > - Follow the steps in preparing the build and build
> > - Deploy the code in Dom0 and the USB VM.
> > 
> > I am about to upgrade to Qubes 4.0 rc4 (when released) so won't probably be 
> > able to help until this is done.
> > 
> > Any help from someone who is used to packaging under Fedora would be nice.
> > 
> > Alex

Sure, I'll update the doc and post here. However as I said don't want to touch 
my Qubes set-up before my upgrade to 4.0 rc4. So might be in 2-3weeks

-- 
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/3db55a51-80e2-4c00-94ba-5d3938bc3e95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: GPU?

[Alex Dubois]

On Thursday, 18 January 2018 21:00:19 UTC, Alex Dubois  wrote:
> On Sunday, 14 January 2018 07:12:24 UTC, ro...@tuta.io  wrote:
> > Is qubes able to use the computing power of the gpu or is the type of gpu 
> > installed a waste in this issue?
> 
> You can use GPU computing in Dom0 with the assumption that:
> - You trust the software you plan on using
>- 3D design software such as Blender
>- GPU compute such as CUDA libs, Tensorflow, Keras, etc..
> - You only create assets/code and export them out of Dom0
> 
> If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen 
> to do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
> - It is far from trivial and only limited setups are known to work
> - The security of it is not as robust (I can't remember where I read that, I 
> think it was in the GPU Pass-through page of the Xen wiki)
> 
> I have tried with limited success few years back (only one boot and was never 
> able to get it back after)...

Sorry forgot to mention that GPU pass-through also require another monitor (or 
switch input...).
It may also be much easier to only use it as a Compute GPU (you keep the UI via 
Qubes-Dom0)

-- 
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/039bb36d-c45a-44bc-8479-0db627db2cc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: GPU?

[Alex Dubois]

On Sunday, 14 January 2018 07:12:24 UTC, ro...@tuta.io  wrote:
> Is qubes able to use the computing power of the gpu or is the type of gpu 
> installed a waste in this issue?

You can use GPU computing in Dom0 with the assumption that:
- You trust the software you plan on using
   - 3D design software such as Blender
   - GPU compute such as CUDA libs, Tensorflow, Keras, etc..
- You only create assets/code and export them out of Dom0

If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen to 
do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
- It is far from trivial and only limited setups are known to work
- The security of it is not as robust (I can't remember where I read that, I 
think it was in the GPU Pass-through page of the Xen wiki)

I have tried with limited success few years back (only one boot and was never 
able to get it back after)...

-- 
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/a9604c45-de67-4a9c-94cd-6b85735f6159%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

[Alex Dubois]

On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> No, I am still under R3.2
> 
> Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > "https://github.com/adubois/qubes-app-linux-yubikey;
> > >
> > >
> > > Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > >
> > >> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > >>
> > >>> Nobody ?
> > >>>
> > >>>
> > >>>
> > >>> Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a écrit :
> > >>>
> > >>>
> >  Hi,
> > 
> > 
> > 
> >  I am going to install a new sys-usb.
> >  I have before to install all what I need to the template (fedora-26)
> >   first. When following your procedure:
> > 
> > 
> >  ykpers has been installed but: I cannot do the same for
> >  qubes-yubikey-vm and qubes-yubikey-dom0 :
> > 
> >  no match for argument
> > 
> >  ideas ?
> > >>
> > >> Not quite sure what you are trying to do here. What procedure? What
> > >> command are you entering?
> > 
> > Are you trying this on Qubes 4.0? Those Yubikey packages might not be in
> > the Qubes repo yet.

Hi,

I have not maintained this for some time. So long that I can't remember if the 
packages had been created/tested, I don't think they have.

Best is you follow the steps to build it on a new temporary VM, don't be afraid 
it should not be too hard:
- Execute the yum command in "Build dependancies"
- Also install pam-devel
- Follow the steps in preparing the build and build
- Deploy the code in Dom0 and the USB VM.

I am about to upgrade to Qubes 4.0 rc4 (when released) so won't probably be 
able to help until this is done.

Any help from someone who is used to packaging under Fedora would be nice.

Alex



-- 
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/24175c57-8792-4beb-b1b4-ab96f9beccdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dom0 terminal color is blue?

[Alex Dubois]

On Monday, 8 January 2018 17:02:15 UTC, Yuraeitha  wrote:
> On Sunday, January 7, 2018 at 9:18:54 PM UTC+1, bow...@gmail.com wrote:
> > Stupid question, I rarely fire dom0 terminal... is the color blue? I 
> > remember it being grey long ago...
> 
> Which Qubes system version are you on, and also the version of the one you 
> refer to into the past, if you remember? 
> 
> Qubes 3.2. dom0 terminal is blue (or was until Qubes 4 RC-2 was released at 
> least, as that was when I moved away from 3.2 and never looked back).
> 
> Qubes 4.0 has a gray dom0 terminal. 
> 
> I never used Qubes previous to version 3.2, maybe it was gray before 3.2, and 
> became gray once more in Qubes 4.0?
> 
> I'm guessing you're using Qubes 3.2. currently, or earlier, if you rarely use 
> the dom0 terminal to the extent you refer to. Because currently Qubes 4 
> requires you to update dom0 through the dom0 terminal, including handling the 
> backup-create and backup-restore in the dom0 terminal. I suspect a GUI might 
> come in the future though, when more developer time can be focused on it, as 
> they're quite busy with Qubes 4. But this is just speculation on my part.


Yes correct I am on 3.2. I thought someone had me swallow the blue pill ;)

I don't mind terminal at all, it is just that after setting all my 18 VMs, I 
did not have a use.

I use it mainly as a personal cloud (Atlassian stack hosting) + firewall, so 
this may explain.

-- 
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/f25f709f-67eb-4176-bd93-2192ec22a7b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.