date:20180206

On Tuesday, February 6, 2018 at 3:48:26 PM UTC-8, Tim W wrote:
> Are you running the ./setup or using the build.conf example?  If the later 
> look at awokd's link and follow those steps.  
> 
> https://github.com/QubesOS/qubes-issues/issues/3426
> 
> 
> That is how I have been building qubes iso and separate templates since ver 
> 3.1.  Do not follow any of the steps to edit conf files etc in the linked 
> instructions above.  Just follow the cmds as those issues have been fixed.   
> 
> Pick fc26 (optional fc26minimal) stretch (optional stretch minimal) and the 2 
> whonix templates.  You tech can add all the fc26 and Stretch template choices 
> as they all should build based off my tests results.  You would need more 
> disk space though.  I could be off but I think adding 5 gig per extra 
> template you add should keep you with enough build space.  Start at 60 gig 
> for standard build and go up from there.  They build in fc23 fc25 i have seen 
> people post issues using fc27 but have no idea if its version related or not.


I was building with ./setup, I'm just trying to get a new kernel into a 3.2 iso 
so I can install qubes on my Thinkpad. 

-- 
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/1370ee6e-35cf-40e5-b655-098a4c7f1301%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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] Can't seem to build qubes 3.2

2018-02-06 Thread Tim W

Are you running the ./setup or using the build.conf example?  If the later look 
at awokd's link and follow those steps.  

https://github.com/QubesOS/qubes-issues/issues/3426


That is how I have been building qubes iso and separate templates since ver 
3.1.  Do not follow any of the steps to edit conf files etc in the linked 
instructions above.  Just follow the cmds as those issues have been fixed.   

Pick fc26 (optional fc26minimal) stretch (optional stretch minimal) and the 2 
whonix templates.  You tech can add all the fc26 and Stretch template choices 
as they all should build based off my tests results.  You would need more disk 
space though.  I could be off but I think adding 5 gig per extra template you 
add should keep you with enough build space.  Start at 60 gig for standard 
build and go up from there.  They build in fc23 fc25 i have seen people post 
issues using fc27 but have no idea if its version related 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/b392158d-f3a4-4d31-a80f-d2a9a1ade1ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping

2018-02-06 Thread Tim W

5he nice thing going forward is most newer processors are coming with the iommu 
etc where just 2 years ago it was at least 2x less choices.   The real issue 
these days is making sure the bios/efi software is supporting it to the 
standard and not some half baked abortion of what it should be.   Its one of 
the reasons the lenovo thinkpads are the first choice.  If they had not 
switched away from coreboot or allowing it to be swapped in it would be about 
as good as you could get with an current cpu.  

My 440p has been great running qubes and fully supports 4.0 as well.  16g ram 
has been plenty  for a laptop (not workstation replacement).

For a workstation I would rather build one so I could have as close to an ideal 
config as possible but certainly not cheap $ option.

-- 
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/19c78800-bc6a-49e3-b674-9af1b8bb5bbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

On Tuesday, February 6, 2018 at 3:23:37 PM UTC-8, Unman wrote:
> On Tue, Feb 06, 2018 at 03:06:32PM -0800, Alchemist wrote:
> > On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote:
> > > On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote:
> > > > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote:
> > > > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
> > > > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
> > > > > > > So I follow the build guide instructions, I have No_Sign=1, but 
> > > > > > > for some reason the build script fails by telling me that the 
> > > > > > > package is unsigned.
> > > > > > > 
> > > > > > > Fedora 27 is my build system. 
> > > > > > > 
> > > > > > > Any ideas?
> > > > > > > 
> > > > > > You'll really have to give us a clue - which package is unsigned?
> > > > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't 
> > > > > > already
> > > > > > have them.
> > > > > > Then check the logs in build-logs and see exactly what is happening.
> > > > > 
> > > > > Sorry about that, 
> > > > > 
> > > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is 
> > > > > not signed.  Exiting!
> > > > > make[1]: *** 
> > > > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86:
> > > > >  /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] 
> > > > > Error 1
> > > > > 
> > > > > is the error I get, I turned on Debug and Verbose, but there's 
> > > > > nothing in build-logs. 
> > > > > 
> > > > Ok, so that's an issue with that package from Fedora. It isn't to do 
> > > > with
> > > > signing or not signing the packages that you are building.
> > > > Just delete that rpm and try the build again.
> > > 
> > > I deleted it, and it still is giving me the same error.
> > 
> > Here's the entire area of the log:
> > 
> > [SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded 
> >
> > (154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s |  77 kB 00:01 
> >
> > 
> > Total38 kB/s |  77 kB 00:02 
> > 
> > Complete!
> > The downloaded packages were saved in cache until the next successful 
> > transaction.
> > You can remove cached packages by executing 'dnf clean packages'.
> > + rm -f /tmp/tmp.q6KHM6Y1gW
> > + echo '-> Verifying signatures...'
> > -> Verifying signatures...
> > + set +x
> > Filename: 
> > /home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is 
> > not signed.  Exiting!
> > make[1]: *** 
> > [/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
> > /home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1
> > make[1]: Leaving directory '/home/x/qubes-builder'
> > make: *** [Makefile:224: vmm-xen-dom0] Error 1
> > 
> 
> Can you go to cache and test it:
> rpm -qpi should show you the details

[x@localhost base_rpms]$ rpm -qpi acl-2.2.52-10.fc23.x86_64.rpm 
warning: acl-2.2.52-10.fc23.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 
34ec9cba: NOKEY
Name: acl
Version : 2.2.52
Release : 10.fc23
Architecture: x86_64
Install Date: (not installed)
Group   : System Environment/Base
Size: 187824
License : GPLv2+
Signature   : RSA/SHA256, Tue 08 Sep 2015 08:24:19 AM PDT, Key ID 
32474cf834ec9cba
Source RPM  : acl-2.2.52-10.fc23.src.rpm
Build Date  : Tue 08 Sep 2015 04:47:35 AM PDT
Build Host  : buildvm-17.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://acl.bestbits.at/
Summary : Access control list utilities
Description :
This package contains the getfacl and setfacl utilities needed for
manipulating access control lists.

-- 
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/840608cf-d3fb-49fd-a344-a06f554f4c7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

2018-02-06 Thread Unman

On Tue, Feb 06, 2018 at 03:06:32PM -0800, Alchemist wrote:
> On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote:
> > On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote:
> > > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote:
> > > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
> > > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
> > > > > > So I follow the build guide instructions, I have No_Sign=1, but for 
> > > > > > some reason the build script fails by telling me that the package 
> > > > > > is unsigned.
> > > > > > 
> > > > > > Fedora 27 is my build system. 
> > > > > > 
> > > > > > Any ideas?
> > > > > > 
> > > > > You'll really have to give us a clue - which package is unsigned?
> > > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already
> > > > > have them.
> > > > > Then check the logs in build-logs and see exactly what is happening.
> > > > 
> > > > Sorry about that, 
> > > > 
> > > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is 
> > > > not signed.  Exiting!
> > > > make[1]: *** 
> > > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86:
> > > >  /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] 
> > > > Error 1
> > > > 
> > > > is the error I get, I turned on Debug and Verbose, but there's nothing 
> > > > in build-logs. 
> > > > 
> > > Ok, so that's an issue with that package from Fedora. It isn't to do with
> > > signing or not signing the packages that you are building.
> > > Just delete that rpm and try the build again.
> > 
> > I deleted it, and it still is giving me the same error.
> 
> Here's the entire area of the log:
> 
> [SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded   
>  
> (154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s |  77 kB 00:01   
>  
> 
> Total38 kB/s |  77 kB 00:02   
>   
> Complete!
> The downloaded packages were saved in cache until the next successful 
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> + rm -f /tmp/tmp.q6KHM6Y1gW
> + echo '-> Verifying signatures...'
> -> Verifying signatures...
> + set +x
> Filename: 
> /home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is 
> not signed.  Exiting!
> make[1]: *** 
> [/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
> /home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1
> make[1]: Leaving directory '/home/x/qubes-builder'
> make: *** [Makefile:224: vmm-xen-dom0] Error 1
> 

Can you go to cache and test it:
rpm -qpi should show you 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/20180206232333.uui7dpgjllu6kaos%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

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

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


-- 
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/243e6bcc7071c0525b75d8421aee99a7.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

On Tue, February 6, 2018 10:47 pm, Unman wrote:
> On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote:
>
>> On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
>>
>>> On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
>>>
 So I follow the build guide instructions, I have No_Sign=1, but for
 some reason the build script fails by telling me that the package
 is unsigned.

 Fedora 27 is my build system.

Might want to try Fedora 25 instead?


-- 
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/daff058c02b869866d7eade50ad0a15d.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

2018-02-06 Thread Tim W

I have been having isses with fedoras repo over the last few days while 
compiling both 3.2 and 4.0.   I have stopped using make qubes all together and 
instead compile the packages in small groups or individually.  I can then redo 
a package a few times without starting over.  I have been able to compile a 
number of different template configs.

So far it seems the non standard templates fail with python script or config 
errors.  Fedora 25 works other than the fc25fullyloaded template.   Centos 
fails as does Xenial Ubuntu.  I had issues with archlinux as well but have not 
tried it package by package so it might work.   They may build fine as 
templates only but they do not when rolled into a qubes os iso build.  

Im putting together a list of the failures to post once Im done so we can look 
over and fix the issues.  

-- 
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/731060d9-fbfc-45db-b97a-89beee2b245d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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] Can't seem to build qubes 3.2

On Tuesday, February 6, 2018 at 3:00:39 PM UTC-8, Alchemist wrote:
> On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote:
> > On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote:
> > > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
> > > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
> > > > > So I follow the build guide instructions, I have No_Sign=1, but for 
> > > > > some reason the build script fails by telling me that the package is 
> > > > > unsigned.
> > > > > 
> > > > > Fedora 27 is my build system. 
> > > > > 
> > > > > Any ideas?
> > > > > 
> > > > You'll really have to give us a clue - which package is unsigned?
> > > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already
> > > > have them.
> > > > Then check the logs in build-logs and see exactly what is happening.
> > > 
> > > Sorry about that, 
> > > 
> > > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not 
> > > signed.  Exiting!
> > > make[1]: *** 
> > > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86:
> > >  /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 
> > > 1
> > > 
> > > is the error I get, I turned on Debug and Verbose, but there's nothing in 
> > > build-logs. 
> > > 
> > Ok, so that's an issue with that package from Fedora. It isn't to do with
> > signing or not signing the packages that you are building.
> > Just delete that rpm and try the build again.
> 
> I deleted it, and it still is giving me the same error.

Here's the entire area of the log:

[SKIPPED] libusbx-1.0.21-0.1.git448584a.fc23.x86_64.rpm: Already downloaded
(154/154): acl-2.2.52-10.fc23.x86_64.rpm 44 kB/s |  77 kB 00:01

Total38 kB/s |  77 kB 00:02 
Complete!
The downloaded packages were saved in cache until the next successful 
transaction.
You can remove cached packages by executing 'dnf clean packages'.
+ rm -f /tmp/tmp.q6KHM6Y1gW
+ echo '-> Verifying signatures...'
-> Verifying signatures...
+ set +x
Filename: 
/home/x/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not 
signed.  Exiting!
make[1]: *** 
[/home/x/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
/home/x/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1
make[1]: Leaving directory '/home/x/qubes-builder'
make: *** [Makefile:224: vmm-xen-dom0] Error 1

-- 
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/545d3975-8ac1-4466-b032-7fa73a48b138%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

On Tuesday, February 6, 2018 at 2:47:29 PM UTC-8, Unman wrote:
> On Tue, Feb 06, 2018 at 02:27:57PM -0800, Alchemist wrote:
> > On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
> > > On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
> > > > So I follow the build guide instructions, I have No_Sign=1, but for 
> > > > some reason the build script fails by telling me that the package is 
> > > > unsigned.
> > > > 
> > > > Fedora 27 is my build system. 
> > > > 
> > > > Any ideas?
> > > > 
> > > You'll really have to give us a clue - which package is unsigned?
> > > You can turn on DEBUG and VERBOSE in builder.conf if you don't already
> > > have them.
> > > Then check the logs in build-logs and see exactly what is happening.
> > 
> > Sorry about that, 
> > 
> > /qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not 
> > signed.  Exiting!
> > make[1]: *** 
> > [/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
> > /home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1
> > 
> > is the error I get, I turned on Debug and Verbose, but there's nothing in 
> > build-logs. 
> > 
> Ok, so that's an issue with that package from Fedora. It isn't to do with
> signing or not signing the packages that you are building.
> Just delete that rpm and try the build again.

I deleted it, and it still is giving me the same error. 

-- 
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/2d2ac64b-a3cf-4d5d-82da-059d44a63a6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] Qubes OS 4.0-rc4 has been released!

2018-02-06 Thread pixelfairy

strange. starting VMs is much slower for me and a minion than 4rc3 or 3.2
were. even vm performance seems slower. for example typing in and scrolling
in windows in firefox is slower, though videos on youtube still play fine,
even in full screen. we expected a performance hit for mitigating the
recent flaws.

blender is much slower. i know blender is outside of qubes domain, but it
shows the performance difference.

On Tue, Feb 6, 2018 at 11:53 AM David Hobach  wrote:

> On 02/01/2018 03:44 AM, Andrew David Wong wrote:
> > We're pleased to announce the fourth release candidate for Qubes 4.0!
>
> A big thanks for that!
>
> So far it seems more stable than the previous RCs and PVH doesn't only
> provide the mentioned security gain, but also provides much better
> performance over HVM on older machines.
>
> 4.0rc1 felt twice as slow as 3.2 and now rc4 feels like the same level
> of speed as 3.2.
>
> --
> 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/57reYSQsB00/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/47ae1411-c153-7f19-bebf-bcda284ee628%40hackingthe.net
> .
> 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/CACr%3DtZcjH%2BKL0dkREW%2B6L-UYA2%3DAwf3fmipfD6z-zpH%2BcqK8Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

On Tuesday, February 6, 2018 at 5:15:34 PM UTC-5, Unman wrote:
> On Tue, Feb 06, 2018 at 02:02:47PM -0800, Alchemist wrote:
> > So I follow the build guide instructions, I have No_Sign=1, but for some 
> > reason the build script fails by telling me that the package is unsigned.
> > 
> > Fedora 27 is my build system. 
> > 
> > Any ideas?
> > 
> You'll really have to give us a clue - which package is unsigned?
> You can turn on DEBUG and VERBOSE in builder.conf if you don't already
> have them.
> Then check the logs in build-logs and see exactly what is happening.

Sorry about that, 

/qubes-builder/cache/fc23/base_rpms/acl-2.2.52-10.fc23.x86_64.rpm is not 
signed.  Exiting!
make[1]: *** 
[/home/liveuser/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
/home/liveuser/qubes-builder/chroot-fc23/home/user/.prepared_base] Error 1

is the error I get, I turned on Debug and Verbose, but there's nothing in 
build-logs. 

-- 
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/86b451a0-bd54-4f57-965b-f7d774a43468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Can't seem to build qubes 3.2

So I follow the build guide instructions, I have No_Sign=1, but for some reason 
the build script fails by telling me that the package is unsigned.

Fedora 27 is my build system. 

Any ideas?

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

[qubes-users] Re: [qubes-devel] Qubes OS 4.0-rc4 has been released!

2018-02-06 Thread David Hobach


On 02/01/2018 03:44 AM, Andrew David Wong wrote:

We're pleased to announce the fourth release candidate for Qubes 4.0!


A big thanks for that!

So far it seems more stable than the previous RCs and PVH doesn't only 
provide the mentioned security gain, but also provides much better 
performance over HVM on older machines.


4.0rc1 felt twice as slow as 3.2 and now rc4 feels like the same level 
of speed as 3.2.


--
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/47ae1411-c153-7f19-bebf-bcda284ee628%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping

2018-02-06 Thread Utility Panel

On Monday, February 5, 2018 at 10:34:34 AM UTC-5, Utility Panel wrote:
> I installed Qubes 4.0-rc4 on a machine with hardware that cannot support the 
> following two features
> 
> IOMMU/VT-d/AMD-Vi
> Interrupt Remapping
> 
> The installation went fine. I simply continued installing after the error 
> message appeared just after the installation ISO completed its hardware check.
> 
> After installation, I was able to boot up to the desktop without any errors. 
> I didn't do much additional testing because I thought that there might be a 
> way to configure the BIOS on my machine to support the missing features; but 
> alas, there is no such way.
> 
> Consequently, if I ever want to run 4.0, I am left with the following two 
> choices: 
> 
> A) Install 4.0 on this machine and live without the missing features.
> B) Get a new computer that supports the missing features.
> 
> I prefer option A. Can anyone tell me what I might expect without 
> IOMMU/VT-d/AMD-Vi and Interrupt Remapping? 
> 
> I've heard that PCI passthrough won't work, but I could live without it. 
> 
> What other problems might I encounter? Will 4.0 work without those features, 
> or must I get a new machine to run 4.0?

Thank you for the confirmation, @awokd!

Thanks also to @Brendan & @Taiidan for the laptop recommendations as well. I've 
known about the G505S for a while now, but the W520 is a new option for me to 
consider. 

Meanwhile, the machines I'm currently replacing are both server workstations 
with 96 gigs of EEC RAM. I'm looking to upgrade to something comparable, and 
I'm pretty certain at this point that I'll start building with either the 
KCMA-D8 or KGPE-D16. I've got one year after the release of 4.0 to make the 
transition, so I've got time to collect all the bits before 3.2 reaches 
end-of-life.

It's just too bad that the Z800 turns out to have a manufacturing defect. I 
bought them last year because they meet the minimum requirements for Qubes 4.0; 
or, they would have if they hadn't been borked at the chip factory.

-- 
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/82e771f9-6801-466a-a5c2-cb5fd550f23f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] firefox addons in offline template VMs

2018-02-06 Thread David Hobach


Dear all,

does anyone have a good solution for offline firefox addon installation 
& regular updates to template VMs?


If so, I'd be delighted if you shared your idea or code.

Otherwise I'd probably write a few lines to download the addons in a 
separate VM, pass it to the offline template via qvm-copy and update the 
respective firefox folders there. [1]


[1] 
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Alternative_distribution_options/Sideloading_add-ons#Installation_using_the_standard_extension_folders


KR
David

--
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/89a2dd3f-7850-0aa3-e4df-f178ec4b81ef%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Fedora-minimal und Q. 4.0

2018-02-06 Thread Jo

Apologizes for being so unspecific, i actually meant missing both.T
The command qvm-convert-pdf is not recognized.
I found the pdf-converter on github, therefore, i will manually install
it within the template.

Another thing/bug i noticed actually right now: My sys-vpn
(fedora-26-minimal) are missing the options "Copy/move to vm" and "open
in Dispvm" in the GUI-context menu.However, the command qvm-copy-to-vm
is recognized and working.
Im unsure what is triggering this bug, since my usb-vm is also based on
a fedora-26-minimal template but does have the gui-entrys/the qvm-copy
function

cheers

On 02/06/18 02:21, Andrew David Wong wrote:
> On 2018-02-05 08:47, Jo wrote:
> > Cheers folks,
>
> > because of the switch to 4,0 im currently setting up a complete new
> > system-structure, and therefore, i wanted to base all the sys-vms
> > on fedora minimal templates.
>
> > However, im missing a few qubes-specific  functions and couldnt
> > find informations on what to install to get them. Ive installed
> > all the necessary packages mentioned in the Documentation, but the
> > "convert to trusted PDF/IMG function" is still missing.
>
> > Any hints which package i need to add?
>
>
> When you say that it's "missing," does you mean that the CLI tool is
> missing, or the option is missing from the GUI context menu, or both?
>
> In either case, this sounds like this might be an oversight. Tracking:
>
> https://github.com/QubesOS/qubes-issues/issues/3543
>
> >

-- 
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/1ef6285d-42a9-4ec7-cf58-592f8aac0d0d%40seefelder-web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 - Inbound port forwarding

On Tue, February 6, 2018 11:35 am, 'awokd' via qubes-users wrote:
> [Re-titling this sub-thread]

> Anyone out there intimate with nft/iptables? My PR went through so the
> document is up for grabs again if you want it! (Or please give suggestions
>  here and I can document it too.)

For anyone coming across this without reading the entire thread- Alex
grabbed it. Thank you, 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/4c3fa114b7bf17d5305398eda3956333.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Yubikey with smartcard and HOTP together

2018-02-06 Thread Konstantin Ryabitsev

Hi, all:

This is a different and a more nuanced problem than recently discussed,
and I'm not sure if there's a solution, but I wanted to ask. :)

Yubikey-4 can act in multiple capacities:

- Smartcard
- U2F device
- HOTP

HOTP functionality is really just a keyboard and registers with Linux as
such (USB keyboard). With 3.2 I was attaching the USB controller
directly to the VM where I was doing the work that required the
smartcard/HOTP functionality and both worked just fine. With 4.0 I
created a separate sys-usb VM and it seems I can use only one or the
other, not both.

When I plug in the yubikey, it registers correctly and I get a pop-up
notification that it's available to be used. At that point, I am able to
use HOTP-press without needing to attach the device to my work vm
(because it's a "keyboard"). However, if I want to use the smartcard
functionality, I have to assign the device to the work VM -- and gnupg
interacts with it correctly. However, once I do that, I am no longer
able to use HOTP -- pressing the button does nothing.

Any ideas if this is fixable at all, or is it the downside of the way
USB devices are assigned with usb-proxy?

Best,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation

--
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/0f889341-850c-23ba-8286-4b091bd2529b%40linuxfoundation.org.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

[qubes-users] template debian-9 no network (Q4r4) ?

2018-02-06 Thread Connor Page

you probably ticked update over Tor option when installing.
templates do not connect to network directly, they use an updates proxy.
I' not sure it can be changed in GUI, but you can find the appropriate rpc 
policy in /etc/qubes-rpc
alternatively you can temporarily set template vm's network provider, but that 
is considered less 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/d3845366-0dc3-4751-a377-83e1e97f4a80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2018-02-06 Thread Max

On Tuesday, 6 February 2018 21:21:31 UTC+8, dba...@gmail.com  wrote:
> Le jeudi 10 novembre 2016 18:09:30 UTC+1, Max a écrit :
> > On Thursday, 10 November 2016 07:34:06 UTC+8, Drew White  wrote:
> > > On Thursday, 10 November 2016 04:36:18 UTC+11, Max  wrote:
> > > > Brief update on this. After attempting to use the Qubes Network Server 
> > > > from Manuel Amador (Rudd-O) to solve this issue with no luck I have 
> > > > gone back to looking at solving this by adjusting the iptables rules.
> > > > 
> > > > I ran through the steps listed here again: 
> > > > https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms
> > > >  but instead of trying to ping my Debian 8 VM (10.137.2.18) from the 
> > > > Windows VM (10.137.2.19), I did this from a new Fedora VM (10.137.2.16) 
> > > > to test the results.
> > > > 
> > > > I simply did the following:
> > > > 
> > > > Firewall
> > > > sudo iptables -I FORWARD 2 -s 10.137.2.16 -d 10.137.2.18 -j ACCEPT
> > > > 
> > > > work-apps
> > > > iptables -I INPUT -s 10.137.2.16 -j ACCEPT
> > > > 
> > > > This enabled me to ping from Fedora to the Debian VM. No additional 
> > > > rules were required such as adding ports or adding an ACCEPT FORWARD 
> > > > rule in the Debian VM with the destination and source reversed.
> > > > 
> > > > Given the ease of achieving this, it seems that the issue here stopping 
> > > > me pinging my Debian VM from Windows is specific to Windows being an 
> > > > HVM. Pinging from an HVM to a PVM does not seem to work but PVM to PVM 
> > > > networking does. Please note that the HVM can ping the firewall and 
> > > > vice versa.
> > > > 
> > > > Does anyone have any suggestions given this information?
> > > > 
> > > > Many thanks.
> > > 
> > > As I have said in other places, including his qubes network server post, 
> > > I too use IPTables, because it's much simpler and cleaner.
> > > 
> > > I have a dedicated ProxyVM that is my inter-vm network.
> > > 
> > > 
> > > These are the 2 rules...
> > > $intervm_internalnet = '10.137.2.0';// this can be generated from the 
> > > ifconfig if required. But conditions apply for success.
> > > 
> > >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
> > > 
> > > 
> > > 
> > > This has worked for me always. Never missed a beat. And it allows for 
> > > inter-vm comms, as well as it communicating to the outside world.
> > 
> > Thanks Drew, unfortunately I tried this at the beginning (my step 3). It 
> > didn't work for me.
> > 
> > Have you tried pinging from a Windows HVM to another Debian or Fedora AppVM?
> 
> Hello Max,
> 
> I am a newbie on Qubes, and i've the same issue on 3.2 version.
> Did you finally succeeded in having interconnect between two HVM ?
> Thanks for your feedback.
> 
> Regards
> 
> Mc

Hi Mc,

I was able to connect between Linux AppVMs only, not HVMs.

To solve my particular issue, I went with syncthing to transfer a text file 
between VMs which was very straightforward as the Windows and Linux clients are 
very easy to install.

Thanks

-- 
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/6d822ee3-0d14-49c9-a2f2-b2bdea20653f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2018-02-06 Thread Max

On Tuesday, 6 February 2018 22:49:31 UTC+8, Alex Dubois  wrote:
> 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  > of 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...

Hi Alex

Yes, I wanted to do a little more than pinging. For this particular issue, I 
wanted to be able to query a database connection between the two VMs.

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

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

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 ?

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

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.

[qubes-users] template debian-9 no network (Q4r4) ?

2018-02-06 Thread ThierryIT

Hi,
qvm-
I have installed the debian-9 template on dom0 using: sudo qubes-dom0-update 
qubes-template-debian-9.
When running this template to make it up to date, the network is not working.
Even if using the same proxyVM and netVM than the other VMs, it still start 
sys-whonix ... 
Any idea ?

-- 
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/277d0104-7378-43ea-bc50-9b5eb401037b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 4.0-rc4 Install Help

2018-02-06 Thread Mike Keehan

On Sat, 3 Feb 2018 09:22:08 -0800 (PST)
Shashank  wrote:

> I guess I’ll not jump into booting into legacy mode and having to
> mess up all the boot options again. If you do find a way to install
> it in uefi mode like 3.2 please do post the solution. 
> 

HI again.

Well I have managed to get rc4 installed in UEFI mode, but it's not 
a nice process :)

The Qubes iso seems to contain two menus for EFI booting, but the
Dell XPS15 won't display them at all, hence there is no possibility
to edit the boot line and add the modprobe.blacklist option at bootup.

There are two ways I've found to overcome this - in one, I edited the
Qubes iso file before writing it to a usb stick, and the other was by
following the Lenovo troubleshooting link, 
https://www.qubes-os.org/doc/thinkpad-troubleshooting/

1. Binary edit the Qubes iso (I used gvim as plain vim could not
   handle the temp file!?!).
   Search for "i915.preliminary_hw_support=1" and REPLACE it with
   the string "modprobe.blacklist=nouveau   ".  This MUST be exactly
   the same length as the i915 string, so it add three spaces at its
   end.  ANY change in the length of the text line will damage the
   iso and it definitely won't work.

   This probably only needs to be done for the "qubes-verbose" menu
   options, but I didn't check this, I just replaced all the repeats
   of the string in the two menus.  There is a third menu for GRUB
   legacy, but I did not bother replacing them there.

   Then write out the iso to usb, and reboot.  Interrupt the Dell boot
   screen with F2 and select the UEFI usb boot option.  All should work
   OK.  (Qubes-check will fail because the iso has been edited, but
   the check option only appears when legacy booting.)

2. Or, follow the Lenovo troubleshooting guide at the link above, and
   create the usb and change the Label to BOOT and mount it.  I could
   not find the xen.cfg file, but there was a ".cfg" (can't remember
   the name) that contained the bootup command lines.  I replaced the
   option "quiet" with the modprobe.blacklist=nouveau string.  Length
   of the string does not matter in this case. Save the file, unmount
   the usb and try to boot from the it.

   It didn't provide an UEFI boot option on my DELL, but I was able to
   boot the "fallback boot on Anaconda" from my boot manager "refind".
   You may not want to go to the trouble of installing that if you are
   not multi-booting your laptop.  In which case, you only have option
   1.

Some of the problems with the Dell (apart from the nVidia device), are
that it seems to require that any EFI partition must have both the
correct partition type (EFI) and the specific EFI disk identifier,
otherwise its bios does not recognise an EFI boot partition.

Mike.

-- 
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/20180206134312.4462d32d.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

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

2018-02-06 Thread dba972

Le jeudi 10 novembre 2016 18:09:30 UTC+1, Max a écrit :
> On Thursday, 10 November 2016 07:34:06 UTC+8, Drew White  wrote:
> > On Thursday, 10 November 2016 04:36:18 UTC+11, Max  wrote:
> > > Brief update on this. After attempting to use the Qubes Network Server 
> > > from Manuel Amador (Rudd-O) to solve this issue with no luck I have gone 
> > > back to looking at solving this by adjusting the iptables rules.
> > > 
> > > I ran through the steps listed here again: 
> > > https://www.qubes-os.org/doc/qubes-firewall/#enabling-networking-between-two-vms
> > >  but instead of trying to ping my Debian 8 VM (10.137.2.18) from the 
> > > Windows VM (10.137.2.19), I did this from a new Fedora VM (10.137.2.16) 
> > > to test the results.
> > > 
> > > I simply did the following:
> > > 
> > > Firewall
> > > sudo iptables -I FORWARD 2 -s 10.137.2.16 -d 10.137.2.18 -j ACCEPT
> > > 
> > > work-apps
> > > iptables -I INPUT -s 10.137.2.16 -j ACCEPT
> > > 
> > > This enabled me to ping from Fedora to the Debian VM. No additional rules 
> > > were required such as adding ports or adding an ACCEPT FORWARD rule in 
> > > the Debian VM with the destination and source reversed.
> > > 
> > > Given the ease of achieving this, it seems that the issue here stopping 
> > > me pinging my Debian VM from Windows is specific to Windows being an HVM. 
> > > Pinging from an HVM to a PVM does not seem to work but PVM to PVM 
> > > networking does. Please note that the HVM can ping the firewall and vice 
> > > versa.
> > > 
> > > Does anyone have any suggestions given this information?
> > > 
> > > Many thanks.
> > 
> > As I have said in other places, including his qubes network server post, I 
> > too use IPTables, because it's much simpler and cleaner.
> > 
> > I have a dedicated ProxyVM that is my inter-vm network.
> > 
> > 
> > These are the 2 rules...
> > $intervm_internalnet = '10.137.2.0';// this can be generated from the 
> > ifconfig if required. But conditions apply for success.
> > 
> >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
> > 
> > 
> > 
> > This has worked for me always. Never missed a beat. And it allows for 
> > inter-vm comms, as well as it communicating to the outside world.
> 
> Thanks Drew, unfortunately I tried this at the beginning (my step 3). It 
> didn't work for me.
> 
> Have you tried pinging from a Windows HVM to another Debian or Fedora AppVM?

Hello Max,

I am a newbie on Qubes, and i've the same issue on 3.2 version.
Did you finally succeeded in having interconnect between two HVM ?
Thanks for your feedback.

Regards

Mc

-- 
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/317d2d23-cfe3-4326-b5b7-371875bbf9ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 - Inbound port forwarding

[Re-titling this sub-thread]

On Tue, February 6, 2018 11:12 am, 'Tom Zander' via qubes-users wrote:
> On Tuesday, 6 February 2018 11:32:07 CET 'awokd' via qubes-users wrote:
>
>> 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)
>
> Yes, that sounds familiar.
>
>
> The problem isn't limited to sys-net either, using netcat to listen on
> any port on any (fedora based) appvm I could not get anything to connect
> to those ports. So, for instance, starting netcat on sys-firewall I could
> not connect to it from sys-net. Similarly, listening on a random VM and
> connecting to it from sys-firewall failed too. And I tried a lot of ways to
> convince the iptables to accept it...
>
> I mostly used archlinux templates for appvms, which do not have the qubes
>  networking packages and thus the iptables list is empty. [1] Listening
> there and connecting from it worked fine.
>
> Hope that helps.

I'm using the Debian-9 template, maybe that's why I was able to get
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
working first try. Doesn't explain sys-net though which is using it too.

Anyone out there intimate with nft/iptables? My PR went through so the
document is up for grabs again if you want it! (Or please give suggestions
here and I can document it too.)



-- 
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/f876b8dbafa5d60e8ac109f2b1225fa5.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Please help with Qubes 4.0 rc4 on 8th Generation Intel

On Mon, February 5, 2018 2:13 pm, Krišjānis Gross wrote:
> Hi,
>
>
> I have recently installed Qubes 4.0 rc4 on a new 8th generation Intel
> hardware and have an issue that I would like to get help with.
>
> The issue is that graphics appear to be very very slow. Each time there
> is some visual activity on the screen it is vary 'laggy'. I noticed that
> whenever there is a GUI action, the process called Xorg is using 100% of
> one of the processor cores.

Haha I can definitely see it's using software rendering on that video.

The Xorg.0.log file confirms it with "[   131.769] (EE) AIGLX: reverting
to software rendering"

Looks like the kernel option got renamed. In your kernel command line, can
you try replacing "i915.preliminary_hw_support=1" with
"i915.alpha_support=1"?

-- 
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/417e96ea8a25bea123dcba85043116ce.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

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

2018-02-06 Thread 'Tom Zander' via qubes-users

On Tuesday, 6 February 2018 11:32:07 CET 'awokd' via qubes-users wrote:
> 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)

Yes, that sounds familiar.

The problem isn't limited to sys-net either, using netcat to listen on any 
port on any (fedora based) appvm I could not get anything to connect to 
those ports.
So, for instance, starting netcat on sys-firewall I could not connect to it 
from sys-net.
Similarly, listening on a random VM and connecting to it from sys-firewall 
failed too.
And I tried a lot of ways to convince the iptables to accept it...

I mostly used archlinux templates for appvms, which do not have the qubes 
networking packages and thus the iptables list is empty. [1]
Listening there and connecting from it worked fine.

Hope that helps.

1) Personally I would say that simpler is better, or least surprises is 
better. The current design where any appvm gets those complex firewall rules 
is a bug. Only VMs that expose their network (providing) should run it.
-- 
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/2307203.OnATnpnmTp%40strawberry.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] size difference between 4.9 and 4.14 kernels

2018-02-06 Thread Holger Levsen

hi,

on 3.2 I ran "sudo qubes-dom0-update" this morning, followed by "sudo
qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade 
kernel-qubes-vm"
which then prompted me with this:

 Installing:
  kernel   x86_64  1000:4.14.13-3.pvops.qubes
qubes-dom0-cached46 M
  kernel-qubes-vm  x86_64  1000:4.14.13-3.pvops.qubes
qubes-dom0-cached62 M
 Removing:
  kernel   x86_64  1000:4.9.35-20.pvops.qubes
@qubes-dom0-cached  179 M
  kernel-qubes-vm  x86_64  1000:4.9.35-20.pvops.qubes
@qubes-dom0-cached  206 M

Is that really expected and correct that the new kernels are that much
smaller?


-- 
cheers,
Holger

-- 
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/20180206110441.u47kzgpfwfzibgki%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

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

2018-02-06 Thread nicklas . aven

On Saturday, December 16, 2017 at 3:25:46 AM UTC+1, Yuraeitha wrote:
> Aight, so the idea of this thread, is to get an overview of where we stand, 
> that is, how far are we away from archiving GPU Passthrough on Qubes. 
> 
> The underlying reason it's currently not working, appears to be because of 
> its current state a virtual GPU for a specific VM, would require direct 
> access to dom0. This is deemed a serious security threat breaking a central 
> pillar of what Qubes is all about, attempting to isolate dom0 as far as 
> possibly possible. Therefore, from what I can gather, what we need is virtual 
> GPU operating from an underlying DomU stub-domain, preferably, one separated 
> from another DomU stub-domain, which holds the important and critical VM data 
> and user operations. Thereby it's not only about single virtualization 
> anymore, but also about group segmenting and isolating entire virtual 
> stub-domains. That means, one group of VM's is isolated from another group of 
> VM's. Please correct me if I'm wrong here, it's great for the discussion to 
> have the most accurate information.
> 
> Here is a scenario that stresses the above, 
> https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA
> Managing to make GPU passthrough work, but only by passing it directly to 
> Xen, instead of Libvirt, which in turn, exposes dom0.
> 
> Initially, this is all the reasons I can think of for wanting V-GPU. 
> - Heavy graphic designer job or hobby (movies, animations, etc.).
> - Running Qubes on many screens at desk. 
> - Extending a single Qubes machine around the house or company, using 
> multiple of screens, keyboards/mouses or other thinkable means.
> - Gamers who take security and privacy seriously (there is surprisingly many 
> of them out there).
> - Cryptocoin miners who wish to utilize a single machine for all round 
> purposes.
> - Using a qube as a streaming TV, and want good graphics for the specific 
> TV-VM. For example 4k or even 8k+ or more on multiple tied screens.
> 
> Some of these are exotic and probably not many around use them, however, 
> others are quite common. Whichever the case, it's all scenarios with a common 
> problem. The point here, is to underpin the possible use-cases.
> 
> 
> 
> I must be tired, I initially wrote 'qubestions' instead of 'questions' 
> here... 
> aight, so possible questions for the discussion.
> 
> - What would it take for Qubes to obtain stubdomains in a feasible means to 
> allow safe GPU Passthrough? 
> - Are there other problems that needs solving too? If so, which ones? 
> - What is the grand big picture status between the above two questions? 
> - Are there currently any plans for any of these required implementations? 
> For example Qubes stub-domains in Qubes 4.1? Qubes 5? or are they still 
> unplanned? If planned, or in part planned, like only halfway there, then, 
> what are these plans? Please elaborate. 
> - Other possible questions you can think of. 
> 
> 
> I'm sure there are aspects I did not think of, but that's fine, after all, 
> this is a discussion. This initial post is just to kick it off. The purpose 
> is to combine information that a few selected individuals might be sitting 
> on, with the many users who do not know about the current state. Thereby, 
> building community awareness of the current situation. Whatever you got to 
> say, or ask, about GPU Passthrough, this thread can be used for that! The 
> only limitation, is that it is a discussion, and not a place to ask how to 
> get your own specific case of GPU Passthrough to work. It's a general, meta 
> discussion. 
> 
> What is your thoughts on the matter?

Just to add a use case is all developers doing something including the gpu.

I found Qubes OS the other day and installed it on a secondary pc. It seems 
great, and besides the security concerns it also gives a great way to organize 
the computer. To keep work, private and open source projects separated.

I work on TilelessMap, an open source project to keep huge amounts of map data 
locally (linux, windows or android). Can be view as a privacy project since it 
makes you independent of connection which reveals what maps you are interested 
in (where you are in other words).

https://github.com/TilelessMap

It renders the map in openGL som I have a problem adopting Qubes OS on my 
primary laptop. But I would really love to do it.

 write this just to point out that it isn't just gaming that is the use case. 
Anyway, Qubes OS looks fantastic, for more or less anything else. 

Thanks !

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

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

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
.



-- 
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/4532ba5292b7dff28452fe49ae0d30ad.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 3.2 after patching