Re: [qubes-users] XL VM connectivity to Qubes Network

2018-10-08 Thread 3mptyy
On Tuesday, September 25, 2018 at 9:24:08 PM UTC+2, 3mp...@gmail.com wrote:
> > Some obvious questions.
> > 
> > You say the interface is correctly configured.
> > Do you have any routes set in the Windows box?
> > Do you see traffic outbound on the 10.137.0.50 iface?
> > 
> > If you sniff traffic inbound on the vif attached to the Windows HVM, do
> > you see anything there? (I mean sniff on the proxyVM)
> 
> Hi Unman, thanks for your help.
> 
> To eliminate some potential Windows issues I chose to boot on a fedora 28 
> live cd in this HVM.
> 
> I configured the eth0 interface with the following command to copy a normal 
> qubes configuration :
> 
> ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast 
> 10.255.255.255
> route add -host 10.137.0.10 (ProxyVM IP) dev eth0
> route add default gw 10.137.0.10 eth0
> 
> I identified vif14 on ProxyVM, it corresponds to the HVM interace.
> 
> I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) 
> to 10.137.0.8 port 8080 (web server on qube I'm trying to reach, working 
> great from a third qube)
> 
> telnet doesn't connect but here's the result of tcpdump :
> 
> https://pastebin.com/QXhyBx4Z
> 
> Any help appreciated

Could someone help me on this issue ? Or explain the right network 
configuration in Qubes 4.0 ? The 255.255.255.255 netmask seems strange to me... 
Is the idea to block all kind of traffic except to the gateway with the route 
add -host commmand ?

-- 
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/9724addd-d087-4f64-ab60-32ce5b7a9437%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] XL VM connectivity to Qubes Network

2018-10-08 Thread unman
On Mon, Oct 08, 2018 at 03:27:43AM -0700, 3mp...@gmail.com wrote:
> On Tuesday, September 25, 2018 at 9:24:08 PM UTC+2, 3mp...@gmail.com wrote:
> > > Some obvious questions.
> > > 
> > > You say the interface is correctly configured.
> > > Do you have any routes set in the Windows box?
> > > Do you see traffic outbound on the 10.137.0.50 iface?
> > > 
> > > If you sniff traffic inbound on the vif attached to the Windows HVM, do
> > > you see anything there? (I mean sniff on the proxyVM)
> > 
> > Hi Unman, thanks for your help.
> > 
> > To eliminate some potential Windows issues I chose to boot on a fedora 28 
> > live cd in this HVM.
> > 
> > I configured the eth0 interface with the following command to copy a normal 
> > qubes configuration :
> > 
> > ifconfig eth0 10.137.0.200 (HVM IP) netmask 255.255.255.255 broadcast 
> > 10.255.255.255
> > route add -host 10.137.0.10 (ProxyVM IP) dev eth0
> > route add default gw 10.137.0.10 eth0
> > 
> > I identified vif14 on ProxyVM, it corresponds to the HVM interace.
> > 
> > I launched tcpdump -n -i vif14.0 on ProxyVM, telnet from 10.137.0.200 (HVM) 
> > to 10.137.0.8 port 8080 (web server on qube I'm trying to reach, working 
> > great from a third qube)
> > 
> > telnet doesn't connect but here's the result of tcpdump :
> > 
> > https://pastebin.com/QXhyBx4Z
> > 
> > Any help appreciated
> 
> Could someone help me on this issue ? Or explain the right network 
> configuration in Qubes 4.0 ? The 255.255.255.255 netmask seems strange to 
> me... Is the idea to block all kind of traffic except to the gateway with the 
> route add -host commmand ?
> 

I believe that is indeed the aim.
You can either set to 255.255.255.0 or add specific route, as you have
done. (Did you set a return route on the destination also?)

The next step would be to examine the rules on the proxy to make sure
that you are allowing the traffic through the ProxyVM. You could listen
on the interface that's attached to 10.137.0.8 to see if traffic is
outbound from there.

unman

-- 
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/20181008135548.g4wsss6ld25qfvg3%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Android Studio AVD emulate

2018-10-08 Thread pixel fairy
On Thursday, September 13, 2018 at 9:27:09 AM UTC-7, Andrzej Andrzej wrote:
> Any idea?

If you really want to do it on your own host, AVD manager / create virtual 
device / choose device / select system image / Other Images / click "download" 
on an android image and finish.

but thats very slow and tends to be error prone. take advantage of our 
networked world, and run a vagrant server. host os linux, with vagrant-libvirt 
(which uses kvm) and make sure nested virtualization is enabled, which is why 
your not going to use virtualbox for this. then grab this script, 
https://gist.github.com/xahare/1db2970b7b684c0d54c0c15cc32afb98 and set a 
VAGRANTHOST in your .bashrc
also, vagrant plugin install vagrant-sshfs

you can install virt-manager in the fedora-28 templatevm, and set it to your 
vagranthost. you'll have to remove its connection to localhost (xen).


in my case, i added src to .gitignore (so it doesnt get clobbered) and rsync 
that code as needed. rvagrant uses .gitignore, but you dont need a git repo 
there. you can make your git repos in your studio projects instead.

if you do a vagrant halt and up, (like after software updates) run vagrant 
provision to fix the permissions of /dev/kvm (it will complain about snap 
installing an existing package. you can ignore that)

the first time the emulator runs, it will be slow, but after that, its fast 
enough that all this trouble is worth it.

heres my Vagrantfile. my vagrant host only has 2 cores, but i suggest 4 if you 
have the hardware. and yes, you really want 10 gigs of ram in it. android 
studio is a hog.

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

setup = <<-SCRIPT
apt-get -y install vim-gtk3 git openjdk-8-jdk openjdk-8-jre 
snap install android-studio --classic
chgrp vagrant /dev/kvm
chmod g+rw /dev/kvm
SCRIPT

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "peru/ubuntu-18.04-desktop-amd64"
  config.vm.synced_folder "src", "/home/vagrant/src", type: "sshfs"
  config.vm.provider "libvirt" do |lv|
lv.nested = true
lv.cpus = 2
lv.memory = 10240
  end
  config.vm.provision "shell", inline: setup
end

-- 
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/3d5dc716-8234-4526-930a-d8bbbcfc658e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Changing USB Controllers

2018-10-08 Thread unman
On Sun, Oct 07, 2018 at 06:31:04PM -0700, alexw8...@gmail.com wrote:
> Hello, I have qubes (r4.0) installed on a USB.  I have 3 USB Controllers on 
> my laptop.  When I am running qubes and try attaching a USB device,  it 
> always uses the same USB Controller(the usb qubes is installed/dom0) 
> regardless of the USB port I am using.
> 
> Is there a way to switch this?  I wanted to try and create a USB qube just 
> for untrusted usb devices.  I know I cant use the one dom0 is on but I have 
> two more controllers I would like to utilize if possible for this. 
> 

Are you sure you have 3 controllers? Many laptops only have one.
It sounds as if you have 1 controller and 3 attached ports. You can't
change this without hardware modification. 
Some laptops have controllers allocated to "internal" devices like
mouse/keyboard, but not to external ports. Not much use to you.
Check the output of 'sudo lsusb -v' and 'sudo lspci -v'

unman

-- 
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/20181008134111.zd6wv4wff6tzzqrc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] nftables vs iptables

2018-10-08 Thread mfreemon

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
  > On 01/10/2018 03:47 PM, Connor Page wrote:
  >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
  >
  > Hmmm, I was just thinking how Qubes' own guest scripts still use
  > iptables even in fedora-26.
  >
  > IIUC, iptables and nft are two different interfaces to netfilter. I
  > don't know if it really matters, at least for the R4.0 window. I'd
  > prefer to put the syntax change (for docs) off until a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The upgrade
instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in Fedora
Qubes code, but Debian Qubes is still using iptables. That still appears
to be the case since nftables is not installed in my debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it took
me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have spent
a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500


I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that 
software such Qubes needs to be solid on (in both design approach and 
implementation detail).


Is the Qubes team confident in the current situation, such that users of 
Qubes should not be concerned?


nb.  This is not meant to be a criticism at all.  I very much appreciate 
the hard (and complicated) work going into Qubes.  I'm just looking to 
understand the current situation better so as to judge whether my 
concern is warranted 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/730fa03d-d105-ab76-6297-21039ebb584a%40zoho.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Installing qr-exec on HVM

2018-10-08 Thread Will Dizon
Update:

Got all services to run, including qubes-gui-agent.  Turns out the dependency 
it was failing on was meminfo-writer which was enabled in the 
/usr/lib/qubes/init/qubes-sysinit.sh script, but promptly disabled because it 
wasn't "checkmarked" in dom0's VM settings page.

That said, with all services running, still same behavior of getting no replies 
to "qvm-run --pass-io" nor does any qvm-run for executing commands, e.g., touch.

  qubes-db.service
  qubes-early-vm-config.service 
  qubes-meminfo-writer.service  
  qubes-mount-dirs.service
  qubes-qrexec-agent.service 
  qubes-sysinit.service 

-- 
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/5027edf3-e726-47c5-b75e-b6e95428baa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Is it possible to install Qubes OS on another Internal Hard Drive partition?

2018-10-08 Thread mirtilloazedo
If so, how do you do 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/3f51bf4d-3a0a-4164-bf44-48bd3bd918e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Changing USB Controllers

2018-10-08 Thread Alex Winter
Here are the usb controllers when I type in 'sudo lspci -v' 

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb xHCI (Rev 05) (prog-if 30 [XHCI])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 57
 Memory at f7b0 (64-bit, non-prefetchable) [size=64k]
 Capabilities: [70] Power Management version 2
 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb EHCI #2 (Rev 05) (prog-if 20 [EHCI])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 16
 Memory at f7b18000 (32-bit, non-pcopy and pasterefetchable) [size=1k]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci
 Kernel modules: ehci_pci

00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family 
USb EHCI #1 (Rev 05) (prog-if 20 [EHCIReciever])
 Subsystem: Micro-Star International Co., Ltd. [MSI] Device 10ec
 Flags: bus master, medium devsel, latency 0, IRQ 23
 Memory at f7b17000 (32-bit, non-prefetchable) [size=1k]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci
 Kernel modules: ehci_pci

when I type in 'sudo lsusb -v' Here are the buses.  

Bus 002 Device 002: ID 8087:8000 Intel Corp.

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iProduct 2 EHCI Host Controller
iSerial  1 :00:1d.0

Bus 001 Device 002: ID 8087:8008 Intel Corp.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iproduct 2 EHCI Host Controller
iSerial  1 :00:1a.0

Bus 004 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
iProduct 2 xHCI Host Controller
iSerial  1 :00:14.0

Bus 003 Device 007: ID 1770:ff00

Bus 003 Device 005: ID 8087:07dc Intel Corp.

Bus 003 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 
receiver

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
iProduct 2 xHCI Host Controller
iSerial  1 :00:14.0



-- 
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/cc49162d-7fc8-4064-8b25-edece724e1e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Celeron N3350 and VT-d

2018-10-08 Thread newpath7
On Monday, October 8, 2018 at 8:10:17 AM UTC-6, awokd wrote:
> 
> 
> > Now, for the actual question. :) The installer reports missing 
> > IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron 
> > N3350 which, according to 
> > https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-,
> >  should have VT-d (unless it needs a specific kind of VT-d?). I am not sure 
> > about IOMMU, perhaps it is missing. Does the error message list those as 
> > alternatives of the same thing? Or is it that I may have VT-d but not 
> > IOMMU, and the error just lists them all if just one has not been detected?
> 
> Did you enable the possibly multiple virtualization options in your UEFI 
> config?

There are actually no virtualization options in my UEFI config. I do get to 
turn off secure boot and some TSC stuff, but not much else. There's no vmx flag 
in /proc/cpuinfo (less that file after ctrl+f2 during installation), but 
apparently Qubes is not complaining about a lack of VT-x. There is a hypervisor 
flag, however. 

-- 
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/4840c644-5351-45ba-8e0b-270ff1adad14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Celeron N3350 and VT-d

2018-10-08 Thread 'awokd' via qubes-users




newpa...@gmail.com:

On Monday, October 8, 2018 at 8:10:17 AM UTC-6, awokd wrote:




Now, for the actual question. :) The installer reports missing 
IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron N3350 
which, according to 
https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-,
 should have VT-d (unless it needs a specific kind of VT-d?). I am not sure 
about IOMMU, perhaps it is missing. Does the error message list those as 
alternatives of the same thing? Or is it that I may have VT-d but not IOMMU, 
and the error just lists them all if just one has not been detected?


Did you enable the possibly multiple virtualization options in your UEFI
config?


There are actually no virtualization options in my UEFI config. I do get to 
turn off secure boot and some TSC stuff, but not much else. There's no vmx flag 
in /proc/cpuinfo (less that file after ctrl+f2 during installation), but 
apparently Qubes is not complaining about a lack of VT-x. There is a hypervisor 
flag, however.


It's possible your CPU supports the features, but not your motherboard's 
chipset and/or UEFI. Not having any options in the config for it is 
generally a bad sign. Check to see if there's a firmware update 
available for your board. VT-d implies there's at least one IOMMU, and 
VT-x is present on everything with VT-d.


--
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/bd3c38d2-e1b7-eaef-5bf7-800a1308708c%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Celeron N3350 and VT-d

2018-10-08 Thread 'awokd' via qubes-users

newpa...@gmail.com wrote on 10/8/18 5:42 AM:


Now, for the actual question. :) The installer reports missing 
IOMMU/VT-d/AMD-Vi, however the machine's motherboard is an Intel Celeron N3350 
which, according to 
https://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2-4-GHz-,
 should have VT-d (unless it needs a specific kind of VT-d?). I am not sure 
about IOMMU, perhaps it is missing. Does the error message list those as 
alternatives of the same thing? Or is it that I may have VT-d but not IOMMU, 
and the error just lists them all if just one has not been detected?


Did you enable the possibly multiple virtualization options in your UEFI 
config?


--
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/c57dbe5d-74d3-fa00-6a0b-73df45e68ce0%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Ubuntu templates

2018-10-08 Thread unman
It's now straight forward to build templates for bionic as well as xenial,
using qubes-builder.

If you want to try them out before building, I've uploaded freshly built
templates for 4.0, including a fairly hefty xenial-desktop template.
You can find details at https://qubes.3isec.org 

Updated packages are available from the repositories there, if you
already have a working template.

unman

-- 
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/20181008142823.si4a2aw7i5fhifch%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Open in Qube 3.0.1 beta released!

2018-10-08 Thread 'Raffaele Florio' via qubes-users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes community,
I've released a new version of "Open in Qube" (aka qubes-url-redirector) 
[v3.0.1_beta] because I fixed a bug in a function (makeUrl) that simplify the 
build process of a whitelisted entry. The announce about the previous release 
is at [v3.0_beta post].

### Upgrade
The upgrade process is the same of installation (on the updated repo).
## Firefox
On Firefox every entry is preserved. Furthermore each entry affected by this 
bug will be converted to the correct one. So no user interaction is needed.
## Chrome/ium
Unfortunately on Chrome/ium you need to repopulate the whitelist (due to the 
packaging process, I also fixed this behavior for future release).

[v3.0_beta post] = 
https://groups.google.com/forum/#!topic/qubes-users/gcKkbJ8EaXA
[v3.0.1_beta] = 
https://github.com/raffaeleflorio/qubes-url-redirector/releases/tag/v3.0.1_beta

Best Regards,
Raffaele.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXw2ov1HEFPFo+AVy07vJZYtrAOMFAlu7klUACgkQ07vJZYtr
AOPGXA//YekM5JcC00OGHFhdxyLzt3fgrclEXv3t8xlFlZAaSMjdBaNrdmWmNTnr
yKgBBQqIFlORlz9TMnzuIWZqoKcVeFabVxTTqFGvXIYWGLRy4UKA/dnnjQQP6fzI
npON7gD6+Jwt/DzyoVlRmmU99TAQ7Ow26rxrZuh5/8AaDNtCzIJSQeLejHima0ri
Z745t1kpkCtb9GTIyHBvrGrFPwL5hZs9gypLAE3XJe4gWr1L9m58XlUtF+7xut0v
hmx+YdH77Y5XBksAF3NKZYl9a1BW34VjqNnecucgljTu9kfeeqaQH7Xzixrkkc8W
VslRBTidKYK6UodhrbgPxXDSmCU4LgPbz7Wp4NTLXOgZs6xtVjSOcTpC1TRFHH5x
fJOpZ6/dMyJpw3VxyIXQGKfE+kKx+2//DMG22gEKydmXqtQVmbXeMUOfeHKJ7sZz
PqpwAbjBJB5JWr+XBZQopR8nBQfMKgpVq1H3GmywQ7bbPtw8rnPKIaEUNotZ2UhO
QlFEF+djF9nViY7MUOMM0mJy1j5Y4CbDFThEIA/jJOQpwjm7RlUn3T+xxMlRqLlD
NyJhclxdHsr1wpgNthrTFaCjHrKD0okkyH1qP2dB4d9gdv8cUNltrm62NDx0/nKZ
OGocfydEngupWLCA2xnXE1q814ec44x3YddcomiE3lypuSkYS1A=
=HvpF
-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/S7pDYIFm2JQ_ocVzcRUnjxDd47zgW5959IsveNZKPf-9G4UPDjzeW6lCujEq7Reqij49wOUnxh5ElB22rU7H85jM38mMhRlJT3trUbiIqyE%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Mouse driver xorg (evdev)

2018-10-08 Thread Marc Coenegracht
I'm using multiple usb mouses/trackballs which need an  
section with the options for the evdev driver specified to make them 
function properly.


Where to put these .conf files?
I can only think of /etc/X11/xorg.conf.d in either dom0 or the template on 
which the sys-usb VM is based.


Or is this all wrong?
I searched the docs and mailing list for the Qubes way to do this, but 
couldn't find an answer.


Best,
Marc

--
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/alpine.DEB.2.20.1810082104380.1261%40localhost.
For more options, visit https://groups.google.com/d/optout.