Re: [qubes-users] Management of salt configs: Syncing from dom0 to a git-repository harboring vm?

2021-05-02 Thread Manuel Amador (Rudd-O)

On 03/04/2021 18.42, balin wrote:

Hi,
I urgently need to backup (and version control) my by now relative 
elaborate salt config.



You could try this: https://github.com/Rudd-O/git-remote-qubes 



--

Rudd-O
https://rudd-o.com/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cb8870e8-4c9d-68b0-f5ba-7b9351f5ccf0%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] Re: Introducing: Qubes Video Companion v1.0

2021-05-02 Thread Manuel Amador (Rudd-O)

On 21/04/2021 07.41, 'Elliot Killick' via qubes-users wrote:

Hello, everyone!

Starting this past early September, I've been working on and off to 
create a new tool for secure webcam integration in Qubes OS out of 
/absolute necessity/ for remote work at both my (new) job and school 
at the university I'm newly attending. The tool is called Qubes Video 
Companion and I'm proud to announce that it's evolved far past that 
basic requirement and at version 1.0.4 is now publicly available for 
testing!



This is truly amazing!  Thank you!

--
Rudd-O
https://rudd-o.com/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d33dff25-56a7-b786-d7ac-3aadf4c9f55a%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] Custom LAN Network with dhcpd

2021-03-28 Thread Manuel Amador (Rudd-O)

On 28/03/2021 00.24, Ulrich Windl wrote:

On 3/16/21 4:59 PM, Manuel Amador (Rudd-O) wrote:

I have the treat for you!

https://github.com/Rudd-O/qubes-arbitrary-network-topology


Sounds nice, but maybe the README should contain shot instructions how 
to undo "attach-network-to".


Done.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eb6dc255-ee30-7d0b-5552-a51f98492839%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] A start job is running for Start Qubes VM sys-net. FOREVER.

2021-03-16 Thread Manuel Amador (Rudd-O)

You can mask the unit in the GRUB kernel command line with the parameter:

systemd.mask=qubes-vm@sys-net.service

And then you will be able to log in and fix the kernel issue (without 
networking, of course).


You can also choose the older kernel in the GRUB menu.

On 16/03/2021 16.49, Fabrizio Romano Genovese wrote:
As the title says. I've upgraded to the latest kernel (5.11) on qubes 
4.0 and now boot is stuck. How do I get out of this? :)


Fab
--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7ba1ae0f-4037-4a47-9bf4-aa9eae652a7dn%40googlegroups.com 
.



--
Rudd-O
https://rudd-o.com/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bbc147a8-4fa0-2f74-9227-23f24b1a19ce%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] ANN: Qubes arbitrary network topology

2021-03-16 Thread Manuel Amador (Rudd-O)

Hello, folks!  I'm here to share this:

https://github.com/Rudd-O/qubes-arbitrary-network-topology 



This software lets you turn your Qubes OS 4.0 machine into an arbitrary 
network topology host. It is ideal to create networks of interconnected 
VMs with arbitrary pathways between them, and minimal effort compared to 
manually setting everything up using xl attach in your dom0 as root.



   How to use

Suppose you have two VMs, which you want to be interconnected via 
(virtualized) Ethernet. VM F (for frontend) will be attached to VM B 
(for backend).


With this software, all you have to do is attach a feature 
attach-network-to onto B, like so:


# Run me on dom0 as your regular Qubes login user. qvm-features B 
attach-network-to F # You can add multiple VMs to attach to, by 
separating them with newlines like so: # [user@dom0]$ qvm-features B 
attach-network-to 'F # G # H'


And that's it. As soon as both B and F are running, network interfaces 
will appear on each one; if you set the feature while the VMs were 
running, the interfaces will appear instantly. The network interface in 
F will generally be named eth0 (or eth1 or other name increasing in 
value). The network interface in B will be named after F. IP networking 
on none of the network interfaces will be configured by the system.


From this point on, all you have to do is configure the network 
interfaces — e.g. using NetworkManager — on those two VMs, then adjust 
the firewall rules on both VMs to permit input from one VM to the other, 
or even forwarding through them. You could build a bridge, or set IP 
configuration to your liking.


Here is a sample IP configuration file for NetworkManager (to follow our 
example, stored in B under /rw/config/NM-system-connections/F.nmconnection):


[connection]
id=B
uuid=bb88cc30-1bcd-40bf-97f2-013626692bd1
type=ethernet
autoconnect-priority=-999
interface-name=F
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
address1=10.250.9.26/30
dns=10.250.7.2
dns-search=
method=manual
route1=10.250.0.0/20,127.0.0.1,1000
route2=10.250.8.0/24,10.250.9.25,1
route3=0.0.0.0/0,10.250.9.25,101

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=disabled

[proxy]

Judicious use of the qvm-features command will allow you to have 
arbitrarily connected VMs on your system, directly testing a panoply of 
network topologies.



   How it works

A small Qubes extension running under qubesd in dom0 monitors VMs as 
they start and stop. If a VM starts and it has the attach-network-to 
feature, all VMs named in the feature will get Xen Ethernet frontends 
attached, with the backends attached to the VM that just started. The 
converse is also true — if a VM starts, and it is mentioned in the 
attach-network-to feature of another VM, the frontend is attached to the 
VM that just started, and the backend is attached to the VM with the 
feature.


It's very simple, no magic involved.


   How to install

Build the two necessary RPM packages and then install them to the 
respective VMs:


1. The qubes-arbitrary-network-topology RPM: use the command make rpm
   on a VM with the same Fedora version as your TemplateVM. Then
   install the RPM in the TemplateVM, and power off the Template VM, as
   well as any other VMs you plan to attach networking to.
2. The qubes-core-admin-addon-arbitrary-network-topology RPM: use the
   command make rpm on a VM or a chroot with the same Fedora version as
   your dom0 (that's Fedora 25 for Qubes 4.0). Then copy the RPM into
   your dom0, and install the RPM.


You should now be good to go.


   Licensing

This software is shared under the GNU GPL v2. You can find the text of 
the GNU GPL in the COPYING file distributed with the source.


--
Rudd-O
https://rudd-o.com/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8efc0a20-1105-bafe-fb45-15d3a1373ec2%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] Custom LAN Network with dhcpd

2021-03-16 Thread Manuel Amador (Rudd-O)

I have the treat for you!

https://github.com/Rudd-O/qubes-arbitrary-network-topology

I'm updating the readme in the next few minutes.  More info there.

On 15/03/2021 12.40, 'Nyx' via qubes-users wrote:

Hello,

I am trying to implement an internal Qubes LAN with HVMs that receive 
dhcp from a netvm using dhcpd. A classical network layout sort of 
speak. Reading Xen Networking makes it look possible but Qubes auto 
configuring the VM networking is being a bit troublesome for what I am 
trying to setup. Note that the entire network will be on Qubes only 
with no internet access.


The reason I am trying to set this up is I have some HVMs that are not 
getting an ip through dhcp and I cannot access them to set ip manually 
(they are vulnhub vms). I was thinking of just running an hvm with 
virtualbox but the limits of emulation only wont work. I read that 
qubes can be recompiled to enable nested virtualization to get that 
working but if there is a way to create a custom network that would be 
preferred.


Is there a way to allow a set of HVMs to get ip from a netvm running 
dhcp and communicate like a classic network?

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/IUbiSSRQZ-eNLCIZh5y-81UZrPRnit3Onx2J81ZIoyhYIs0tFpNLfCPuarHsrZ2WYDKBPYpQlKCXm_-xZ5-rXJfC36oAzaMUB3Sa24YLkyk%3D%40protonmail.com 
.



--
Rudd-O
https://rudd-o.com/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b1b435e4-c2ac-17e6-f5e4-42d2d8ab64bd%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] Any Advantage to using OpenHAB on qubes?

2020-10-05 Thread Manuel Amador (Rudd-O)
On 30/09/2020 15.35, Stumpy wrote:
>
> I want OpenHAB to stay up to date but do not want it to be accessible
> via the internet so i was thinking if I have a template with OpenHAB
> installed that would install OpenHAB and hopefully plugins?
> The thing is I am hoping to have wifi cameras, or at least PoE cameras
> connected so it was less clear to me if i would be able to have an
> OpenHAB appvm that was not connected to the internet, or blocked from
> the network, but able to communicate with these various wireless devices?
>
Qubes can support restrictions on outbound traffic of your OpenHAB
instance by using the firewall rules built into the qube settings screen.

If you want to support inbound traffic you can use
https://github.com/rudd-o/qubes-network-server but you will then have to
manage your firewall rules on your own directly in the OpenHAB qube.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e83e72eb-9bdb-06ef-0c4e-2e739de87319%40rudd-o.com.


Re: [qubes-users] Firewall issue

2020-10-05 Thread Manuel Amador (Rudd-O)
On 22/09/2020 07.05, 'src11' via qubes-users wrote:
> When I go into any qube settings for the firewall there is only an
> option to create and edit rules for outgoing traffic, nothing at all
> for incoming connections. Is that right? When I look at screenshots
> online it shows options for creating both outgoing and incoming
> connection rules. Latest version of Qubes. 

To support inbound connections you will need
https://github.com/rudd-o/qubes-network-server and after installing it
as per the instructions you will have to adjust nftables / iptables
rules in the target VM.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a67d8ab0-b363-2f9d-5a71-6751594e6fe5%40rudd-o.com.


Re: [qubes-users] Qubes 4.1 audio latency after latest update today

2020-07-08 Thread Manuel Amador (Rudd-O)
On 14/06/2020 17.56, 'TQ1' via qubes-users wrote:
> I've been running Qubes 4.1 since the upgrade to fedora 32 in dom0.
> Everything has been fine up until updating dom0 with current-testing
> earlier today (14/6/2020).
> This has introduced audio latency while watching any video in any vm
> whether straming or from a file.
> I was using kernel-5.6.16-1 (kernel-latest) in dom0 before the problem
> started & now I have tried booting with kernel-5.4.44-1 & the same
> problem occurs. I have also tried running various appvms with those 2
> corresponding qubes-vm-kernels & the lag persists.

Might have to enable low audio latency in /etc/qubes/guid.conf on dom0,
then restart the box.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6a713840-3cf1-3a6b-7c45-517a588d09d9%40rudd-o.com.


Re: [qubes-users] Getting to the bottom of screenshots in Qubes OS

2020-07-07 Thread Manuel Amador (Rudd-O)
On 20/06/2020 10.29, Logan wrote:
> Hi Everyone,
>
> Speaking with a colleague earlier today, I heard "Qubes is great, but
> the no screenshots problem makes it a 'hard' no for me".
>
> As a Qubes user and advocate, this stung.

Yeah, it's hard.

Honestly, in my humble opinion, the secure copy and paste keyboard
shortcuts should work with image data as well, not just text data.  That
way the screenshot problem is solved -- I can screenshot in one VM, copy
directly from that app (usually Firefox), and paste in another VM at will.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5982d535-1466-c687-1891-109f20c146a1%40rudd-o.com.


Re: [qubes-users] Speed up a VM

2020-07-07 Thread Manuel Amador (Rudd-O)
On 19/06/2020 01.42, Franz wrote:
> Hello,
> I need to do some video editing and my multimedia VM is too slow,
> video-audio is broken.
>
> Is there some easy way to speed this up?
> Perhaps does it make sense to assign 4 CPUs rather than default 2? 
> Or closing other VMs?
> Or may it be related to little memory (4GB)
> Any experience?
> Best
> Franz
> -- 
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAPzH-qCmshHBtPtbE8SGbzzAE32Qm6b-BV-j%3D6oNFuO_vCSQ%2BA%40mail.gmail.com
> .

You probably will have to enable low-latency audio in dom0's
/etc/qubes/guid.conf for the VM where you're doing audio editing.  If
you don't, there will be a desynchronization of audio and video (this is
deliberate).

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/30ad0ea7-1548-43b1-da50-e81218108418%40rudd-o.com.


Re: [qubes-users] salt - dependencies in scripts

2020-05-28 Thread Manuel Amador (Rudd-O)
You can't use a `require` statement in the top file.  They only work in
SLS files.

On 23/05/2020 01.19, lik...@gmx.de wrote:
> Hi!
>
> As salt is the recommended way to manage the Appms and templates, I'm
> trying to do so.
>
> I successfully managed to create a top-script:
>
> base:
>  dom0:
>   - match: nodegroup
>   - create-template
>   - create-appvm-for-template
>
>  'created-template':
>    - install-pkgs
>    - modify_config
>    - require: dom0
>
> Unfortunately, the script fails on the first run, because step 2.
> requires step 1. done. "Require" seems not to work here. After the
> second run, everything is fine.
>
> Any hints highly appreciated. :)
>
> Best, P
>

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1df190a5-333d-61f1-4a5c-914f1d8932e3%40rudd-o.com.


Re: [qubes-users] How to use pass with split gpg ?

2020-05-24 Thread Manuel Amador (Rudd-O)
Have you tried https://github.com/Rudd-O/qubes-pass ?

On 23/05/2020 17.09, Christophe wrote:
> Hi all, 
>
> Does anyone know how to use pass with split gpg ? 
>
> I found this, but I could not get it working.
> https://github.com/kulinacs/pass-qubes/blob/master/qubes.bash
>
> I also tried to replace gpg by qubes-gpg-client-wrapper in /usr/bin/pass
> but without success, I get an error 
>
> gpg: decrypt_message failed: Unknown system error
>

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b43a6c8-49ac-3ebe-8790-68192f9cba6f%40rudd-o.com.


Re: [qubes-users] Salt worm

2020-05-08 Thread Manuel Amador (Rudd-O)
On 06/05/2020 12.02, haaber wrote:
>> did any of you actually bother to look at the problem?
>> because i am 99% sure this doesnt apply to qubes. at all.
>> (also you are several days late on this...)
>>
>> this seems to be the original source and contains a fairly
>> good writeup:
>>
>> https://labs.f-secure.com/advisories/saltstack-authorization-bypass
>
> Thanks for the source. How do you infer that this "doesn't apply" (and
> maybe "did never apply") to qubes? Recall my question:  where does salt
> appear "under the hood" in qubes? This question seems relevant, since at
> least I (almost) never invoke salt by hand. Is that not a reasonable
> question? Explain.
>
No Salt master in Qubes -> no remoting exploit.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a58f9ab-de85-c992-6e9b-207cfc524211%40rudd-o.com.


Re: [qubes-users] Salt worm

2020-05-08 Thread Manuel Amador (Rudd-O)
On 06/05/2020 10.41, haaber wrote:
>> Qubes uses Salt, and there's something nasty going around:
>> https://saltexploit.com/
>
>    Risk = (probability of an event)  x   (consequences of the event).
>
> At which levels is salt used in qubes? I remember my last "active" use
> >1 year ago to get hopefully clean templates after the apt-"crisis".
> But maybe is is "under the hood" at each qubes-dom0-update? If it were
> to be used "by hand only" we could enforce risk = 0 by the above formula
> and keeping fingers off salt for a while.   Thanks!
>
>
Salt in Qubes OS does not use the Salt master.  It is therefore
unaffected by this issue.

I have now become accustomed to receiving notifications from Qubes OS
saying "XSA-xxx does not affect Qubes security".  There should be a
similar one for the Salt CVE.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/084a45d8-58c2-0834-35e6-03bed6110b55%40rudd-o.com.


Re: [qubes-users] Qubes with limited user authority

2020-05-05 Thread Manuel Amador (Rudd-O)
On 27/04/2020 20.50, mark.russ...@net-c.com wrote:
> I'm trying to get my head around possible use of Qubes in small/medium
> enterprise environments, where the system is maintained by an admin
> and the user freedom is limited by the company policies. I understand
> that the current Qubes design does not account for any threat coming
> for dom0's user,

By design, a user already has root in the machine where Qubes is installed.

If you want to grant users, say, locked remote access to certain AppVMs,
you will have to do so remotely by installing something like Qubes
network server, and making some of those AppVMs available through
encrypted VNC.  Then, by default, they will not be able to copy things
between qubes on the same machine.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e9bc173-37c6-8f91-eb6d-7f38479985d0%40rudd-o.com.


Re: [qubes-users] external CD writer

2020-05-05 Thread Manuel Amador (Rudd-O)
On 02/05/2020 01.23, Olaf Klinke wrote:
> (Apologies for pestering this list with another newbie question.)
>
> So I have this external DVD-RW drive (Asus SDRW-08U7M-U to be
> specific). On my Debian stretch laptop, plugging in the USB drive
> creates /dev/sr0 as well as several symlinks to it, e.g. /dev/cdrw,
> /dev/dvd etc.
>
> Plugging the drive into my Qubes desktop, I get notified of the
> availability of this drive and can attach /dev/sr0 to a Debian buster
> AppVM qube as /dev/xvdi. I can mount /dev/xvdi and read data from a CD
> allright. 
>
> However, in contrast to my Debian laptop, brasero does not recognize
> the drive as a writer, not even when I create the same /dev/cdrw
> symlink. In addition to that, both commands 
> dvd+rw-mediainfo /dev/xvdi
> cd-info -C /dev/xvdi
> exit with an error (details below). Thus it seems that some crucial bit
> did not get forwarded to/is not installed in the AppVM. Probably I'm
> just lacking the knowledge how different writing to a CD is from
> reading from CD, on the hardware level. Is there more to burning a CD
> than a single block special device?
>  
> Any hints welcome.
> Olaf

You must attach your drive via USB to the target VM, rather than as a
block device.  When attached as a block device, the Xen block device
driver does /not/ make your drive visible /as a DVD/RW drive/.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2ceff03b-d4b4-2cb8-f305-fbd612fc1d22%40rudd-o.com.


Re: [qubes-users] Pulseaudio update error - fedora-31

2020-04-23 Thread Manuel Amador (Rudd-O)
On 22/04/2020 21.54, 'Max Andersen' via qubes-users wrote:
>
> Hi everyone,
>
> I remember some time ago we had issues with pulseaudio on earlier
> templates, and I believe a reinstall of pakages fixed the issue. I
> can't  seem to get myself out of trouble with this one on fedora-31.
>
> When doing update I get:
>
> user@fedora-31 ~]$ sudo dnf update
> Last metadata expiration check: 0:50:13 ago on Wed Apr 22 20:44:57 2020.
> Dependencies resolved.
>
>  Problem 1: package pulseaudio-qubes-4.0.27-1.fc31.x86_64 requires
> pulseaudio = 13.0, but none of the providers can be installed
>   - cannot install both pulseaudio-13.99.1-3.fc31.x86_64 and
> pulseaudio-13.0-1.fc31.x86_64
>   - cannot install both pulseaudio-13.0-1.fc31.x86_64 and
> pulseaudio-13.99.1-3.fc31.x86_64
>
...

This happens probably because we don't have automatic builds of
pulseaudio-qubes packages when upstream releases new packages.

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/46ee7908-f053-7e17-feac-4180866bea09%40rudd-o.com.


Re: [qubes-users] Qubes 4.0-rc3

2020-04-16 Thread Manuel Amador (Rudd-O)
On 13/01/2018 03.34, Andrew David Wong wrote:
> On 2018-01-12 08:00, 'awokd' via qubes-users wrote:
> > On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote:
>
> >> I'm not so sure, why not use git branches?
>
>
> One reason that comes to mind:
>
> Segregating the documentation into two different branches would mean
> that contributions that apply to both Qubes versions would only end up
> in one branch, unless someone remembers to manually submit the same
> thing to the other branch and actually makes the effort to do so. Most
> of the time, this won't happen. When it does, it means a second pull
> request that has to be reviewed. Over time, the different branches
> will diverge in non-version-specific content. Good general content
> that was submitted only to the 3.2 branch will effectively disappear
> once 3.2 is deprecated. (Even if it's still on the website, no one
> will look at it, since it'll explicitly be in the subdirectory of a
> deprecated version. And there will be a motivation to remove it from
> the website so that search results aren't populated with out-of-date
> information.)

That ought to be part of the review process, don't you think?  ("Have
you opened PRs for these other branches?")


-- 

    Rudd-O
    http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ae6779fd-2cfb-bcbb-273e-2c8536cf0fb0%40rudd-o.com.


Re: [qubes-users] Qubes 4.0-rc3

2020-04-16 Thread Manuel Amador (Rudd-O)
On 12/01/2018 14.09, Holger Levsen wrote:
> On Fri, Jan 12, 2018 at 01:04:23PM +, 'Tom Zander' via qubes-users wrote:
>> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote:
>>> Would it be of value if I went through the published Docs and added these
>>> version headers? Should newer versions be added at the top (so 4.0 before
>>> 3.2 content)? 4.0 might just be "TBD".
>> I think that would be wonderful,
> I'm not so sure, why not use git branches?

This ought to be the chosen solution.  Mount the release 4.0 branch on
doc/ and the older releases on doc/, then provide links at the
top (Doc for  / <3.2>).

-- 
Rudd-O
http://rudd-o.com/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e04b5cb-6366-e1de-4c27-2218f522e02a%40rudd-o.com.


[qubes-users] ANN: Qubes network server available for Qubes OS release 4.0.x

2020-04-14 Thread Manuel Amador (Rudd-O)
Hello, folks!

After a long hiatus because of reasons, I'm happy to announce Qubes
network server -- an add-on to Qubes OS that allows you to expose
selected AppVMs to other VMs and to other machines in your LAN as well. 
The latest tagged release is compatible with Qubes 4.0.

The URL to check is: https://github.com/Rudd-O/qubes-network-server

An excerpt from the README.md file follows here.  I hope this helps you
understand what possibilities Qubes network server opens up for you.

I'm happy to report that, with a minor readjustment (attaching my
networked AppVMs to NetVMs instead of ProxyVMs), this functions as an
adequate replacement for Qubes network server from release 3.2.

--


  QUBES NETWORK SERVER

This software lets you turn your [Qubes OS
4.0](https://www.qubes-os.org/) machine into
a network server, enjoying all the benefits of Qubes OS (isolation, secure
inter-VM process communication, ease of use) with none of the drawbacks
of setting up your own Xen server.


WHY?

Qubes OS is a magnificent operating system, but there are so many use
cases that its networking model cannot crack:

  * As an automated integration testing system.  Qubes OS would be
phenomenal for this, and its automation tools would make it
extremely easy to bring up and tear down entire environments.
  * If only those environments could network with each other securely!*
Remote management of Qubes OS instances.  Vanilla Qubes OS cannot
easily be managed remotely.  A better networking model would allow
for orchestration tools such as [Ansible
Qubes](https://github.com/Rudd-O/ansible-qubes)  to manage entire
Qubes OS deployments, all of their VMs, and even minutiae within
each VM.
  * Anything that involves a secure server, serving data to people or
machines, simply cannot be done under vanilla Qubes OS.


ENHANCED NETWORKING MODEL

The traditional Qubes OS networking model contemplates a client-only use
case.  User VMs (AppVMs or StandaloneVMs) are attached to ProxyVMs,
which give the user control over outbound connections taking place from
user VMs.  ProxyVMs in turn attach to NetVMs, which provide outbound
connectivity for ProxyVMs and other user VMs alike.

No provision is made for running a server in a virtualized environment,
such that the server's ports are accessible by (a) other VMs (b)
machines beyond the perimeter of the NetVM.  To the extent that such a
thing is possible, it is only possible by painstakingly maintaining
firewall rules for multiple VMs, which need to carefully override the
existing firewall rules, and require careful thought not to open the
system to unexpected attack vectors.  The Qubes OS user interface
provides no help either.

Qubes network server changes all that.

With the Qubes network server software, it becomes possible to make
network servers in user VMs available to other machines, be them peer
VMs in the same Qubes OS system or machines connected to a physical link
shared by a NetVM.  Those network server VMs also obey the Qubes OS
outbound firewall rules controls, letting you run services with outbound
connections restricted.

This is all, of course, opt-in, so the standard Qubes OS network
security model remains in effect until you decide to enable the feature
on any particular VM.

The only drawback of this method is that it requires you to attach VMs
meant to be exposed to the network directly to a NetVM, rather than
through a ProxyVM.  VMs exposed through a ProxyVM will not be visible to
machines on the same network as the NetVM.


HOW TO USE THIS SOFTWARE

Once installed (see the full README.md at the URL posted above), usage
of the software is straightforward.

These sample instructions assume you already have an AppVM VM set up,
named /testvm/, and that your /sys-net/ VM is attached to a LAN with
subnet 192.168.16.0/24.

First, attach the VM you want to expose to the network to a NetVM that
has an active network connection:

qvm-prefs -s testvm netvm sys-net

Then, set an IP address on the VM:

qvm-prefs -s testvm ip 192.168.16.25

(The step above requires you restart the /testvm/ VM if it was running.)

Then, to enable the network server feature for your /testvm/ VM, all you
have to do in your AdminVM (/dom0/) is run the following command:

qvm-features testvm routing-method forward

Now testvm is exposed to the network with address 192.168.16.25, as well
as to other VMs attached to its /sys-net/ NetVM.

Do note that /testvm/ will have the standard Qubes OS firewall rules
stopping inbound traffic.  To solve that issue, you can [use the
standard rc.local Qubes OS mechanism to alter the firewall
rules](https://www.qubes-os.org/doc/firewall/#where-to-put-firewall-rules)
in your /testvm/ AppVM.

-- 
Rudd-O
http://rudd-o.com/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop 

Re: [qubes-users] Upgrading directly from Fedora 23 to 26 ?

2019-06-26 Thread Manuel Amador (Rudd-O)
Qubes 3 runs Fedora 23 as the dom0.  For this reason I assume you are
trying to upgrade from Qubes 3 to Qubes 4.

This configuration of upgrades is not supported.  You must reinstall
Qubes using the Qubes 4 installer, then restore your VMs from a backup
of your Qubes 3 install.



On 20/06/2019 09.14, polish farmer wrote:
> im still running fedora 23... is that bad?  haha im such a noob. what sort of 
> attack vectors do i open myself up to by doing this ?
>

-- 
Rudd-O
http://rudd-o.com/

-- 
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/a5ddde85-6cd7-b292-0d7d-f3701bc5144e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: automatic start dropbox in VM

2019-01-30 Thread Manuel Amador (Rudd-O)
On 30/01/2019 15.53, John Goold wrote:
>
> I simply put a symbolic link to dropbox.desktop in ~/.config/autostart
>
> Works perfectly. I also have links to slack.desktop and thunderbird.desktop.
>
> The .desktop files are located in /usr/share/applications/

This is the cleaner solution and I highly recommend it.  It's the best
way to get apps autostarted with the *right* environment variables for
your desktop environments, something that `sudo` in the context of
`rc.local` will *not* give you.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/321bfc4a-b130-cee7-4c12-a6896aca467f%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] session managers for VMs?

2018-10-04 Thread Manuel Amador (Rudd-O)
On 2018-09-22 07:13, Daniel Allcock wrote:
> Sometimes I need to shut down a qube I'm working in for some reason
> (changing out sys-net for a specialized sys-net, or closing sensitive
> material before working in a public place).  It would be nice to be
> able to come back to the same window setup I left, when restarting the
> qube.
>
> dom0 has this kind of session management via xfce.  Is it possible to
> run a session manager in another qube?  How would I do this? I know
> how to start a window manager using exec, but I haven't figured out
> the X startup files in the VMs yet.  Perhaps each vm already has a
> window manager running?  But if so then I still need to enable that
> wm's session manager.
>
> Even better would be to "hibernate" a qube by suspending it to disk,
> but I know the qubes team has other priorities. I'm hoping per-vm
> session management is something I could do right now.
>
> Thank you very much,
> Daniel
>
>
X11 session management is dead (as much as it pains me to say that), and
so is multiple sessions by a single user (thank systemd session
management and dconf for that).

Best bet would be to implement actual hibernate/thaw for VMs.  That's a
tall order though.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/58c468c1-f59b-3064-f3ac-9d7f44284f73%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] questions - InterVM directory bind

2018-05-05 Thread Manuel Amador (Rudd-O)
On 2018-04-22 12:26, trueriver wrote:
> The page https://www.qubes-os.org/doc/qfilecopy/ decribes how to copy a file 
> or directory to another domain. In the case of a directory the files can 
> later be copied back, in which case they end up in a different directory than 
> the original.
>
> This has the advantage that both copies are available in the original host 
> domain.
>
Someone was working on a FUSE driver that would work through qrexec /
Qubes services.  You might want to look into the mailing list archives
for that.  It seems very practical (if a bit insecure?) to share VM A's
folder /x/y/z with VM B so that it appears as a mounted drive in VM B.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/1c7620f3-69c8-5c47-4f2c-6403e8fc20dd%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] offlineimap with Split-GPG : get new email via cron doesn't work

2018-05-05 Thread Manuel Amador (Rudd-O)
On 2018-04-25 14:19, 799 wrote:
> Hello,
>
> I am using neomutt with offlineimap to get my corporate mail into an
> Email-AppVM.
> The current workflow is:
>
> 1) get email running offlineimap -o
> 2) start neomutt
>
> I'd like to have offlineimap check the mails in the background using cron.
> Thereof I have written a small script:
>
> /user/check-mail.sh
> #!/usr/bin/bash
> # Script will be run by cron
> #su user -c "/usr/bin/offlineimap -u quiet -f INBOX,INBOX.Inbox_CC"
> /usr/bin/offlineimap -u quiet -f INBOX,INBOX.Inbox_CC
> echo Cronjob run at: `date`>> /tmp/cron.log
>
> The last line is only for troubleshooting in order to see, if the
> cronjob has been run.
>
> The scripts is working when launched manually. It will open up the
> SplitGPG window to grant access to my GPG-key in my vault-VM.
> I need to enter the password once and if the next request is within a
> 300sec window access will be granted to th eGPG without further user
> interaction.
>
> I have installed cron and setup a cronjob which should run every 3 min
> in order to be below the 300sec time window when Spli-GPG is asking
> for a password. I have encrypted the password in my offlineimap-config
> and it can only be decrypted using my
>
> [user@my-mail]$ crontab -l
> # min  hr   day-of-month month day-of-week
> # 0-59 0-23 0-31 1-12  0-7
> # Check important mail folders every 3min
> */3 * * * * /home/user/bin/check-mail.sh
>
> unfortunately it seems that this script doesn't work via cron, do you
> have any idea what is wrong?
> If I look into the logfile the script is writing (/tmp/cron.log) I see
> that th ecronjob runs the script but no mails are downloaded.
> As mentioned running the script manually will work.
> Is cron running the job as "user" or as "root"?
>
> To all offlineimap / mutt users how are you auto-fetching new emails?
>
> [799]
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to qubes-users@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/CAJ3yz2tXWNz6Mst3PeUHtcPUj2EzAhH6vs7OUTg0tf8m_8LrAA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
Cron runs under a very different environment from your desktop session
-- the variables needed for GPG agent are not set in that environment. 
I wrote a program run-in-gui / run-in-env-of a while ago, that, while
needing root, starts your program in the same environment as your
desktop session.    Check my Github for them.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/ab00ceeb-a7af-a567-b42b-1b13799d93ce%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Remote Control Question

2018-05-05 Thread Manuel Amador (Rudd-O)
On 2018-04-29 00:50, Stuart Perkins wrote:
> Hi list.
>
> I'm considering setting up Qubes capable server at my home.  What I need, 
> however, is to be able to remotely control it. Updates...reboot/stop/start 
> system and app vm's etc.  Is this even possible with Qubes?  I currently run 
> a Ubuntu powered old laptop as a "server" and have it hosting a couple of 
> VM's with virtualbox.  I can ssh into it and even have an sshuttle setup for 
> VPN over SSH functionality for when I need to do something "gui" remotely.  
> One of my VM's is an old XP system which monitors my solar electric. One is a 
> ubuntu install hosting a Drupal website.  One is also installed which is a 
> full blow VPN server for when I need to do more than just simple things...I 
> rarely use this one.
>
Search for ansible-qubes on Github or Google.  Then search for
qubes-network-server on Github or Google.

I have your setup.  It ain't remote console, but it lets you do
everything you want (low-level) from another machine.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/cce3753c-4d50-7d91-4cd1-f6bcbe415986%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Move Firefox Bookmarks between AppVMs - Help with Script

2018-05-05 Thread Manuel Amador (Rudd-O)
On 2018-05-05 20:44, [799] wrote:
> Hello,
>
> following a recent discussion in the qubes-community github repository, Ivan 
> has written an interesting script for handling links and disposable VMs.
> This has inspired me to look how to move firefox bookmarks to other AppVMs.
> While disposable VMs are great, sometimes it is handy to have bookmarks 
> available in an AppVM.
>
> I was able to import bookmarks into other Appvms by transfering the 
> places.sqlite file which holds the bookmarks.
>
> In the target AppVM which has the bookmarks:
> qvm-copy-to-vm  
> /home/user/.mozilla/firefox/*.default/places.sqlite
>
> then in the destination VM you only need to move the file from QubesIncoming 
> to the profile path.
> While this works, I like to add some error checking and I would also like to 
> kill a running firefox in the destination AppVM.
>
> I was able to kill firefox running:
>
>kill `ps -A | grep firefox | gawk '{ print $1 }'`
>
> no I tried to run further command based on the fact if firefox is running or 
> not.
> I thereof tried to do something like this:
>
> if [`ps -A | grep firefox | gawk '{ print $1 }'` \> 0]; then
>echo "Run this when PID is > 0 and thereof Firefox is running"
> else
>echo "Run this when firefox is not running"
> fi
>
> Unfortunately this doesn't work. Can somone point me into the right direction?
> What is the right approach to run certain commands based on the fact that a 
> program is running or not?
>
> Sorry for this off-topic question but playing with Qubes gives so much 
> options for building own scripts and I am still a beginner here.
>
> [799]
>
You are probably better off writing something that will sync two
different .sqlite files by using SQL operations on both.  SQLite files
are safe to be accessed by two different programs at the same time, and
therefore you may not need to kill Firefox.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/31c51383-57c4-86f9-c0db-91b0dc8ccbf0%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Small Templates

2018-04-20 Thread Manuel Amador (Rudd-O)
On 2018-04-19 00:50, Drew White wrote:
> I don't want an insecure system that crashes every 5 seconds, so I
> want one hat has no SystemD. Until then, smaller template. 

It pisses me off whenever you post because you always post destructive /
nonconstructive nonsense such as this one post above this line (among
many).  You're using Fedora / Debian templates.  They use systemd (learn
to spell it, it isn't SystemD, that means a completely different thing
related to an economic population in Southeast Asia).  Deal with reality
or use something else.  And, quite frankly, I don't know what the fuck
is wrong with your computer -- I haven't had a system crash in months
while using Qubes OS, and I haven't had a systemd-related crash in Y E A
R S.  Literally YEARS since a systemd bug caused a kernel panic (because
that's how a systemd crash looks like, it's an init-related panic).

You, Drew, specifically you, always have complaints, but almost never
ever do you have solutions.  Most of your blame-assigning is entirely
fabricated and political.

So how about you start coding something that will replace the work
others have done, and then post it as a pull request?  Maybe if you
don't want to code, then you can plonk a good amount of cash for people
to code what you want.  But I, sure as iron, do not want you to continue
polluting and poisoning the environment with your useless complaints and
non-suggestions.  Every time I open the mailing list, you're there,
making useless comments or destructive quips.  I'm so, so turned off by
your destructive participation.

Thank you in advance for your courtesy in either stopping your posting
or contributing working code that (1) will be useful to others (2) will
be accepted either in Qubes OS or upstream (3) will be less whiny and
more constructive.

Enough!

-- 
Rudd-O
http://rudd-o.com/

-- 
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/a9ecfd21-8725-1da9-b880-ba41844294f8%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] minimum size for a qube image

2018-04-20 Thread Manuel Amador (Rudd-O)
On 2018-04-16 20:50, Jan Hustak wrote:
> Hello,
> I'm also open to discussing the basic concept: is it worth trying to
> keep, for example, Firefox and GIMP in separate qubes, or should I
> just relax and use one fat TemplateVM with the union of all packages I
> need?
>

Fat template with everything you got there, *so long as your fat
template does not have anything installed that installs systemd system
or user units that will start on boot or login*.  If you have a template
that runs some sort of package on boot or login, you can nuke it using a
systemd unit override ( in the right directory) so it
won't start.  Fedora is really good about not starting units by default
(except for SSHD, which is in fact disabled by default in Qubes templates).

Aaand then perhaps a thin template for things that could be your
service VMs.  (I'm really rooting for the MirageOS templates).

-- 
Rudd-O
http://rudd-o.com/

-- 
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/4cd3cd9c-23a4-9505-4c87-0852237afc13%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: Qubes network server

2018-01-17 Thread Manuel Amador (Rudd-O)
On 10/09/2017 04:49 PM, Thierry Laurion wrote:
>
> Considering Qubes 4.x has switched to HVM, what needs to be done to support 
> this mode of operation? 
> Opened a ticket to track this issue: 
> https://github.com/Rudd-O/qubes-network-server/issues/4
>

Thank you for opening the ticket.  It may be difficult for me to adapt
to 4.0, so I kindly request anyone with the required skillset to send a
pull request adapting it to 4.0.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/ae3a61fa-809e-d388-1358-25727847974a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Fedora minimal template users, watch out for updates

2017-07-26 Thread Manuel Amador (Rudd-O)
I had to restore my Fedora minimal template (now at release 25) from
backups after I performed a DNF update that updated the following packages:



  ↺ updates  update yum packages for non-qubes dom0s (task @
/home/user/Devops/ansible/external/roles/updates/tasks/main.yml:20):
fedora-service-tpl:
- 'Installed: perl-IO-1.36-387.fc25.x86_64'
- 'Installed: gnome-keyring-3.20.1-1.fc25.x86_64'
- 'Installed: xen-qubes-vm-2001:4.6.5-28.fc25.x86_64'
- 'Installed: poppler-glib-0.45.0-5.fc25.x86_64'
- 'Installed: json-c-0.12.1-2.fc25.x86_64'
- 'Installed: storaged-2.6.2-6.fc25.x86_64'
- 'Installed: libgcrypt-1.7.8-1.fc25.x86_64'
- 'Installed: hostname-3.15-8.fc25.x86_64'
- 'Installed: audit-2.7.7-1.fc25.x86_64'
- 'Installed: libproxy-0.4.15-2.fc25.x86_64'
- 'Installed: audit-libs-2.7.7-1.fc25.x86_64'
- 'Installed: dbus-1:1.11.14-1.fc25.x86_64'
- 'Installed: openvpn-2.4.3-1.fc25.x86_64'
- 'Installed: strace-4.18-1.fc25.x86_64'
- 'Installed: dbus-libs-1:1.11.14-1.fc25.x86_64'
- 'Installed: dbus-x11-1:1.11.14-1.fc25.x86_64'
- 'Installed: pcre-8.41-1.fc25.x86_64'
- 'Installed: libsndfile-1.0.28-3.fc25.x86_64'
- 'Installed: gsm-1.0.17-1.fc25.x86_64'
- 'Installed: python3-dnf-plugins-qubes-hooks-3.2.18-1.fc25.x86_64'
- 'Installed: libsolv-0.6.28-2.fc25.x86_64'
- 'Installed: dhcp-client-12:4.3.5-3.fc25.x86_64'
- 'Installed: acl-2.2.52-13.fc25.x86_64'
- 'Installed: libsoup-2.56.0-3.fc25.x86_64'
- 'Installed: poppler-0.45.0-5.fc25.x86_64'
- 'Installed: dhcp-libs-12:4.3.5-3.fc25.x86_64'
- 'Installed: mate-notification-daemon-1.18.0-1.fc25.x86_64'
- 'Installed: glibc-2.24-9.fc25.x86_64'
- 'Installed: glibc-all-langpacks-2.24-9.fc25.x86_64'
- 'Installed: qubes-core-vm-systemd-3.2.18-1.fc25.x86_64'
- 'Installed: glibc-common-2.24-9.fc25.x86_64'
- 'Installed: rsync-3.1.2-4.fc25.x86_64'
- 'Installed: libcrypt-nss-2.24-9.fc25.x86_64'
- 'Installed: libcurl-7.51.0-8.fc25.x86_64'
- 'Installed: qubes-db-3.2.4-1.fc25.x86_64'
- 'Installed: gnutls-3.5.14-1.fc25.x86_64'
- 'Installed: qubes-db-libs-3.2.4-1.fc25.x86_64'
- 'Installed: qubes-db-vm-3.2.4-1.fc25.x86_64'
- 'Installed: gstreamer1-1.10.5-1.fc25.x86_64'
- 'Installed: perl-Scalar-List-Utils-3:1.48-1.fc25.x86_64'
- 'Installed: libstoraged-2.6.2-6.fc25.x86_64'
- 'Installed: gstreamer1-plugins-base-1.10.5-1.fc25.x86_64'
- 'Installed: gdk-pixbuf2-2.36.7-1.fc25.x86_64'
- 'Installed: libdb-utils-5.3.28-24.fc25.x86_64'
- 'Installed: gdk-pixbuf2-modules-2.36.7-1.fc25.x86_64'
- 'Installed: openldap-2.4.44-11.fc25.x86_64'
- 'Installed: librsvg2-2.40.18-1.fc25.x86_64'
- 'Installed: python3-bind-32:9.10.5-2.P2.fc25.noarch'
- 'Installed: bind-libs-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: libdb-5.3.28-24.fc25.x86_64'
- 'Installed: bind-license-32:9.10.5-2.P2.fc25.noarch'
- 'Installed: hwdata-0.302-1.fc25.noarch'
- 'Installed: wpa_supplicant-1:2.6-3.fc25.x86_64'
- 'Installed: pango-1.40.7-1.fc25.x86_64'
- 'Installed: gtk-update-icon-cache-3.22.17-2.fc25.x86_64'
- 'Installed: bind-utils-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: libacl-2.2.52-13.fc25.x86_64'
- 'Installed: bind99-libs-9.9.10-2.P3.fc25.x86_64'
- 'Installed: bind99-license-9.9.10-2.P3.fc25.noarch'
- 'Installed: gtk3-3.22.17-2.fc25.x86_64'
- 'Installed: dhcp-common-12:4.3.5-3.fc25.noarch'
- 'Installed: libdrm-2.4.82-1.fc25.x86_64'
- 'Installed: expat-2.2.1-1.fc25.x86_64'
- 'Installed: tracker-1.10.5-2.fc25.x86_64'
- 'Installed: perl-libs-4:5.24.2-387.fc25.x86_64'
- 'Installed: perl-macros-4:5.24.2-387.fc25.x86_64'
- 'Installed: krb5-libs-1.14.4-8.fc25.x86_64'
- 'Installed: systemd-udev-231-17.fc25.x86_64'
- 'Installed: xen-libs-2001:4.6.5-28.fc25.x86_64'
- 'Installed: pciutils-3.5.5-1.fc25.x86_64'
- 'Installed: xen-licenses-2001:4.6.5-28.fc25.x86_64'
- 'Installed: pciutils-libs-3.5.5-1.fc25.x86_64'
- 'Installed: systemd-container-231-17.fc25.x86_64'
- 'Installed: qubes-core-vm-3.2.18-1.fc25.x86_64'
- 'Installed: vim-minimal-2:8.0.728-1.fc25.x86_64'
- 'Installed: systemd-libs-231-17.fc25.x86_64'
- 'Installed: systemd-pam-231-17.fc25.x86_64'
- 'Installed: graphite2-1.3.10-1.fc25.x86_64'
- 'Installed: bind-libs-lite-32:9.10.5-2.P2.fc25.x86_64'
- 'Installed: sqlite-3.14.2-2.fc25.x86_64'
- 'Installed: perl-Errno-1.25-387.fc25.x86_64'
- 'Installed: sqlite-libs-3.14.2-2.fc25.x86_64'
- 'Installed: systemd-231-17.fc25.x86_64'
- 'Installed: curl-7.51.0-8.fc25.x86_64'
- 'Installed: perl-4:5.24.2-387.fc25.x86_64'
- 'Installed: librsvg2-tools-2.40.18-1.fc25.x86_64'
- 'Installed: tar-2:1.29-4.fc25.x86_64'
- 'Installed: d-feet-0.3.11-3.fc25.noarch'
- 'Removed: qubes-core-vm-3.2.17-1.fc25.x86_64'
- 'Removed: qubes-core-vm-systemd-3.2.17-1.fc25.x86_64'
- 'Removed: 

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-13 Thread Manuel Amador (Rudd-O)
On 05/12/2017 03:02 PM, Tom Hutchinson wrote:
> Thanks for the contribution Manuel. I'll check it out.

My pleasure :-)

Agreed about the passwords thing!

-- 
Rudd-O
http://rudd-o.com/

-- 
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/b2aed9aa-0147-d008-ce2a-64e0d087afe2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] OpenWhisper Systems Signal not quite right in Qubes 3.2/Fedora23/Chromium

2017-05-08 Thread Manuel Amador (Rudd-O)
On 05/08/2017 02:05 AM, Neal Rauhauser wrote:
>
> I installed Qubes 3.2 on a Dell Precision M4600 (slick) and I've been trying 
> to migrate a portion of my day to day work to it.
>
>
> I have many contacts who use Open Whisper Systems Signal App for 
> communication. I've used the Google Chrome extension on both OSX and Linux 
> without any troubles.
>
> Using a Fedora 23 VM I found Chrome installs to be clumsy, while yum install 
> chromium just works. The Signal Chrome App installs and runs, but the 
> directory function is broke. Existing conversations are fine, but they are 
> with phone numbers rather than names, and I can't look up any other contacts 
> to initiate conversations, I have to wait for them to come to me.
>
> Has anyone else already resolved this problem? This is a "beachhead issue" 
> for me - if I can get Signal going, I can switch a good sized chunk of what I 
> do to Qubes.
>
Have you tried running an Android x86 distro as a VM?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/d528f7e4-9577-fe80-3002-cebf82b839fc%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Intel ME exploitable

2017-05-08 Thread Manuel Amador (Rudd-O)
On 05/08/2017 05:16 AM, Vít Šesták wrote:
> While I sometimes use the arguments “in such case e, attacker gains nothing, 
> because it assumes you are already compromised”, one has to be careful with 
> this, because compromise doesn't imply a total compromise.

True, yet see below.

>
> A simple example (unrelated to ME) of this catch: One might think that giving 
> user full permissions for all the files does not decrease the security if the 
> user can simply sudo anything. While this is not mostly true when considering 
> RCE vulnerabilities (or running a trojan), it doesn't apply to 
> path-traversal-like vulnerability – attacker is not automatically in the 
> position where she can simply call sudo.

True, yet nowhere near the gravity of access to ME.  ME is running an OS
that has effectively the security properties of MS-DOS.  Get some code
running in there, you're root.  Except you're root on the entire
machine.  Even if you don't get code running there, commandeering it is
enough to do remote screen and remote reprovision.

>
> I don't know ME well, but maybe this catch also applies to ME. Note that 
> whole ME includes not only some persistently running chip and its firmware, 
> it also includes some (optional) software for the OS, which is BTW actually 
> recommended to be removed by the Intel's security advisory. I don't know what 
> is it exactly capable of, it can probably give the admin access to OS shell, 
> and maybe something more. (And BTW, you can see it in dom0 by lsmod.) This 
> just illustrates that ME is actually a complex beast and it's hard to 
> properly reason about it.
>
The removal of the software just makes it harder for attackers (now they
have to have system privileges to talk to the I/O ports or PCI, so
exploit chaining would be needed).  It is sound security advice to
reduce the attack surface in this way, as it isn't a given that
exploiting Microsoft Internet Exploder (or whatever they're calling it
these days) will yield system access.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/59740614-3744-1ef3-bc1f-ee89f5d45c16%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Youtube/Video Problem

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/07/2017 07:07 PM, cooloutac wrote:
> there is also vlc plugin for firefox browser. vlc uses its own codecs
> don't think it installs anything for systemwide. You have to install
> gstreamer packages for that. Although you shouldn't need to to for
> youtube, but i had to install gstreamer1-libav to play mp4 streams,
> maybe installing some codecs would help you also even though you
> shouldn't have to.
> This happens in all vms? 

This has to be an unrelated-to-codecs problem, because YouTube knows to
serve HTML video + WebM to YouTube.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/a29f2d35-88f3-24b3-2f9b-f00f8f4acbe1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/02/2017 05:25 AM, Vít Šesták wrote:
> * There seems to be some MEI PCI device (see lspci | grep -i mei) in dom0 and 
> /dev/mei0. I am not sure how all the parts (network stack, MEI PCI device, 
> MEI software for OS and management while offline) are connected together. I 
> am also unsure if having it in dom0 is good (i.e., it prevents passing 
> malicious inputs to it) or bad (i.e., it adds attack surface). The safest 
> approach seems to be attaching it to /dev/null with IOMMU (VT-d) isolation. 
> Just crerating an autostarted (and maybe also autoshutdown) 
> network-disconnected dummy VM with all ME-related PCI devices should do the 
> trick. The VM would be trusted not to pass any malicious input to MEI, but it 
> would not be trusted for anything else (so that it could absorb attack from 
> MEI). I am unsure if this adds some actual protection or if it is totally 
> hopeless.

I remember a few days ago reading that you can talk to ME via SMBus, and
that is in fact the way ME talks to other components when the system is
off and therefore can't talk over PCI.  PCI is obviously another way to
talk to ME.

Keeping them in dom0 won't hurt anything.  The fact that ME cannot be
exploited locally from a VM (assuming the Qubes OS security model holds)
is enough to protect you from local exploits.  In case of successful
exploitation. the ME has full access to RAM in any case, so moving them
to another VM won't give you any extra security.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/21446e90-3336-4d91-2249-9c60123a2b04%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/02/2017 05:25 AM, Vít Šesták wrote:
> Some notes:
>
>
> * I wonder what is the technical distinction between home and SMB/Enterprise. 
> Is it vPro?

I deduced this in the affirmative a few years ago by comparing the SKUs
for various Intel products, and whether they had vPro.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/163291d6-af6e-50b4-6781-95c6c1e331b2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/01/2017 05:26 PM, Vít Šesták wrote:
> AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then 
> the particular CPU is safe. But I am not 100% confident in vPro and related 
> technologies, so I might be wrong. Can someone confirm/deny this claim?

That has been my experience as well.

The typical test is to see if DHCP requests come out of your machine's
network port after it has been "powered off" (it is well known that the
CPU running the ME is separate and doesn't power off).

-- 
Rudd-O
http://rudd-o.com/

-- 
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/2d52e0e2-2c62-c029-d56f-b30ba0bb9612%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Intel ME exploitable

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/01/2017 05:14 PM, Reg Tiangha wrote:
> On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote:
>> *Sigh*... Yep. We were right to be concerned (of course). And now we
>> have something other than our tin foil hats to point at too:
>>
>> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>>
>> I want my RISC-V laptop already!
>>
> I don't know if it helps things, but I recently disabled the
> CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel
> options in my kernel branches as soon as I was made aware of their
> existence. My hope is that the ME hardware can't be exploited using
> those methods if they don't exist in the kernel in the first place; that
> someone would have to find another way. But again, I have no idea if
> that's useful or not. For what it's worth, my systems still boot and run
> properly, but the newest machine I have access to is of the Sandy Bridge
> era; I have no idea if newer machines actually need those options baked
> into the kernel in order to run. Can anyone advise?

Local exploit can talk to the ME via PCI and SMBus.  Only from dom0.

Remote exploit only good against machines with vPro (check your CPU SKU
at the Intel database — I explicitly bought systems without that shit)
because vPro is the prerequisite technology for AMT.  If your machine
does not have AMT / vPro, it cannot be exploited remotely because it is
not listening over network cards.

A quick test: connect your machine physically to a router, start
tcpdumping on the router, then power it off.  Do you see DHCP requests
being emitted on the port of the router where your machine is
connected?  If so, then you're screwed.

>
> https://github.com/rtiangha/qubes-linux-kernel
>
> Also, if anyone has any other ideas on kernel options to disable for
> various security concerns (ME related or not), let me know. For the
> moment, I've implemented almost all of the KSPP's recommended settings
> that are applicable to a certain kernel branch, except for the ones
> about loadable modules since I don't know how it affect u2mfn or any
> other user-compiled kernel modules a Qubes user may want to install. I
> haven't encountered any issues on my machines (or at least, any that
> I've noticed), but those could use more testing as well:
>
> https://github.com/rtiangha/qubes-linux-kernel
>
KSPP is good, but it will not protect you from the attack, because the
attack runs *on a different CPU within your machine, which is always on,
even when the machine is off*.

Yes, it's THAT bad.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/0361826c-468c-74a5-bd75-0701cd022ab1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] ANN: qubes-pass for Ansible — an Ansible lookup plugin for Qubes pass integration

2017-05-07 Thread Manuel Amador (Rudd-O)
Building on https://github.com/Rudd-O/qubes-pass, the new Ansible Qubes
Pass lookup plugin allows you to create Ansible playbooks and roles that
integrate seamlessly with your Qubes OS pass store.

Check it out at
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins

Enjoy!

-- 
Rudd-O
http://rudd-o.com/

-- 
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/8a000fc5-01fa-3762-381e-7cb16334ff79%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/07/2017 05:23 PM, Andrew David Wong wrote:
>
> I prefer the security of qvm-backup[-restore], since it allows me to
> keep the vault and its contents permanently offline. The entire VM is
> BZIP compressed, AES-256 encrypted, and HMAC-SHA512 authenticated. The
> integrity verification, authentication, and decryption all happen at
> the dom0 level. The backup is tiny, so the storage overhead is
> inconsequential, and there's no need to worry about file-level
> metadata leakage or the backup file itself being used as an attack
> vector. KeePassX has sufficient built-in versioning for me, and it's
> easy enough to sync Qubes backups across machines with simple scripts.

Git push takes 5 seconds.

qvm-backup requires anywhere between minutes and many hours. 
Additionally, it requires the target VM be off.

Weekly backups are served okay by qvm-backup (I say "okay" because I
have a borg backup setup on my Qubes OS system, and it's far more usable
and performant than qvm-backup).  Git push is much better suited to,
say, syncing your keyring to other systems.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/6da3112a-4873-bc02-4cac-34bf329c4a63%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/07/2017 03:23 PM, Andrew David Wong wrote:
> On 2017-05-07 10:10, nickl...@kulinacs.com wrote:
> > What benefit does this have over simply ysing
> > qubes-split-gpg-client-wrapper, like done here:
> > https://github.com/kulinacs/pass-qubes It seems like a lot of
> > overhead for not a lot of gain.
>
> > On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> > <rud...@rudd-o.com> wrote:
> >> Building on the excellent pass (https://passwordstore.org), it
> >> gives me great pleasure to announce the initial release of
> >> qubes-pass — an inter-VM password manager and store for Qubes
> >> OS.
> >>
> >> Check it out here!
> >>
> >> https://github.com/Rudd-O/qubes-pass
> >>
>
> What are the advantages of either of these over the traditional Qubes
> model of having a normal password manager in a vault VM and using the
> inter-VM clipboard to copy/paste passwords out of it?
>

These programs do not require user interaction as long as the policies
are properly configured.  Thus, they are extremely useful for batch
processes or system orchestration purposes.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/e8f22638-8944-b0c4-57f6-e962350fdb8b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/07/2017 03:10 PM, nickl...@kulinacs.com wrote:
> What benefit does this have over simply ysing
> qubes-split-gpg-client-wrapper, like done here:
> https://github.com/kulinacs/pass-qubes
> It seems like a lot of overhead for not a lot of gain.

 1. The actual store is stored in a separate VM.  It is never decrypted
in the VM you manage the passwords from.
 2. You do not need to set up your own GPG key, as `qvm-pass init` does
it for you.
 3. There are two different services — one for read-only access and one
for read-write.
 4. There is a get-or-generate feature which is useful for stuff like
https://github.com/Rudd-O/ansible-qubes/tree/master/lookup_plugins


>
> On May 7, 2017 9:50:26 AM CDT, "Manuel Amador (Rudd-O)"
> <rud...@rudd-o.com> wrote:
>
> Building on the excellent pass (https://passwordstore.org), it gives me
> great pleasure to announce the initial release of qubes-pass — an
> inter-VM password manager and store for Qubes OS.
>
> Check it out here!
>
> https://github.com/Rudd-O/qubes-pass
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. --
> 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
> <mailto:qubes-users+unsubscr...@googlegroups.com>.
> To post to this group, send email to qubes-users@googlegroups.com
> <mailto:qubes-users@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com
> <https://groups.google.com/d/msgid/qubes-users/0A765A21-F411-4015-B9C2-790508B1A0C1%40kulinacs.com?utm_medium=email_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/c8fc3adc-5fce-46de-05e5-d0aa2946ed6b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Changed resolution, now screen doesn't work?

2017-05-07 Thread Manuel Amador (Rudd-O)
On 05/01/2017 05:42 PM, almir.aljic1...@gmail.com wrote:
> On Monday, May 1, 2017 at 6:51:51 PM UTC+2, almir.a...@gmail.com wrote:
>> I changed the resolution of my Qubes from 1920x1080 to 1600x1200 (by 
>> accident) and now my screen doesn't show anything when I choose HDMI2 (my 
>> desktop PC is attached to the screen with an HDMI cable). Setting the 
>> resolution to 1280x1024 worked fine, but as soon as I set it to 1600x1200 
>> and clicked "apply" my screen turned black and now all it does is say "no 
>> signal" and I can't see anything on the screen to set it back to 1920x1080. 
>> How do I go about solving this?
>>
>> Thanks.
> I know of a potential solution but then I need help from someone on here.
>
> What you can do is shut down all your windows and left-click the Qubes icon 
> (at the bottom left/top left) then solely use your keyboard to navigate to 
> the Display settings and change resolution. Then send me the exact keyboard 
> strokes you pushed (for example down arrow 2x, right arrow 1x, down arrow 8x, 
> tab 4x etc.) so that I can mimic them and ultimately change my resolution 
> back to 1920x1080.
>
> Thanks in advance!
>
Isn't it easier to launch a terminal using the xfce minicli key combo,
then using xrandr to set the right resolution?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/75e1a8ce-4b51-9107-ec3e-c5f503a85c3d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-07 Thread Manuel Amador (Rudd-O)
Building on the excellent pass (https://passwordstore.org), it gives me
great pleasure to announce the initial release of qubes-pass — an
inter-VM password manager and store for Qubes OS.

Check it out here!

https://github.com/Rudd-O/qubes-pass

-- 
Rudd-O
http://rudd-o.com/

-- 
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/24c27d7a-e72e-14fc-e388-2f5718d95660%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Cannot execute commands in terminal - not root?

2017-04-27 Thread Manuel Amador (Rudd-O)
On 04/27/2017 01:52 PM, jimmycarter wrote:
> I am following this guide to create a ProxyVM: 
> https://www.mullvad.net/guides/qubes-os-and-mullvad-vpn/
>
> However, when I try to execute the commands in step 2 I am not able to 
> execute the sudo bash command with the error message "permission denied". The 
> sudo apt-get update && install command doesn't work either, with the error 
> message "Are you root?"-kind of thing.
>
> I selected the "do not create root user" or something in the installation, is 
> this what's wrong? How do I get this to work? I also tried going into 
> /etc/default/openvpn according to step 5 and tried editing the openvpn file 
> but it gave me read-only access and not write access.
>
> When I use the sudo command it never prompts me to type in my root user 
> password in the terminal. By the way, I am typing those commands into a 
> terminal on the ProxyVM.
>
> Help is highly appreciated.
>

They should update their guide to use
https://github.com/Rudd-O/qubes-vpn — it works almost out of the box
with Mullvad, and I would be happy to accept contributions or
suggestions of UI and interaction to specifically configure their VPN
with qubes-vpn.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/b7b61224-a945-7cd6-bebd-bd3f177c8fd8%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Boot Problem

2017-04-19 Thread Manuel Amador (Rudd-O)
On 04/19/2017 08:35 PM, craig.g.jes...@gmail.com wrote:
> I am having at boot problem with my Qubes OS 3.2.  When I boot up I enter the 
> disk password and the boot process continues until it gets to the line...
>
> A start job is running for Qubes NetVM startup (32s / no limit)
>

You must boot in rescue mode (add boot kernel command line option
systemd.unit=rescue.target) and then disable qubes-netvm.service, then
reboot.

Alternatively boot with kernel command line option
systemd.mask=qubes-netvm.service .

Both of these options will mask the NetVM startup, which will then let
you diagnose the problem more accurately.

These options can be added in the GRUB2 command line editor (hit e) when
the GRUB menu appears after the BIOS screen.  If no menu appears, press
ESC multiple times right after the BIOS screen.  You'll see the menu then.

If your machine boots from UEFI, I do not know how to do this procedure,
sorry.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/42034820-17fb-afe8-ecd8-7a2590949872%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] qubes manager add start terminal

2017-04-19 Thread Manuel Amador (Rudd-O)
On 04/16/2017 11:29 PM, Eva Star wrote:
> I'm get tired that Qubes Manager till now do NOT have "Start Terminal"
> at right click menu of each vm, but only "Run command in VM".
>
> I want to patch it to add "Run terminal". I found that need to
> duplicate "Run command" entry, name it "Run Terminal" and predefined
> "gnome-terminal" on the input field.
>
> I need to modify action. On the repository I see actions at
> mainwindow.ui file. But I can not find it on the disk to add new action!
>
> 
>
> 
>  :/run-command.png:/run-command.png
> 
>
> Where is mainwindow.ui with actions???
>
> If I will found it I will add new function to process this action by
> duplicating action_run_command_in_vm_triggered(self) and predefined
> "gnome-terminal" into it.
>
>

Predefine "gnome-terminal || konsole || xterm" for more compatibility.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/4624e592-9cb2-fbf7-c4fe-06a7fb486fe1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)
On 02/27/2017 01:53 PM, Manuel Amador (Rudd-O) wrote:
>
> I am terrified that Qubes 4.0 will force me to use LVM, because LVM is
> frankly a disaster for data recovery and for data integrity as well.  I
> would be willing to write an adapter to use ZFS zvols instead.  That
> would be the right thing to do.
>
Honestly, ZFS on Linux should be integrated into the Qubes OS installer,
and the system should ship and be installed with it.  But if that's too
much work, then btrfs should be the default.

Inferior volume management systems with no data integrity protection
should not be used these days.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/e2c0d505-334a-cda2-a6a3-7ce628c45063%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)
On 02/26/2017 10:07 PM, Vít Šesták wrote:
> Q: Can I backup VM that is running?
> A: If you have LVM-based private.img, you can. (See README for details.) If 
> you have standard file-based private.img, you cannot. I don't plan to 
> implement this feature for file-based private.img, because Qubes 4.0 will use 
> LVM, so they don't seem to have a long future.

I am terrified that Qubes 4.0 will force me to use LVM, because LVM is
frankly a disaster for data recovery and for data integrity as well.  I
would be willing to write an adapter to use ZFS zvols instead.  That
would be the right thing to do.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/ad1961d4-8e9c-308b-221c-2842f664e13d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Feedback request: Incremental file-based backup PoC

2017-02-27 Thread Manuel Amador (Rudd-O)
On 02/27/2017 12:51 PM, Chris Laprise wrote:
>
> In some backup systems, each backup appears complete to the system,
> even though it was created with incremental deltas. A benefit of this
> is you can delete any backup in the set to reclaim space, without
> affecting any of the remaining backups---a single backup set can be
> updated in rotation forever. Its akin to block-level deduplication.
> Another benefit is that all backups except for the first will transmit
> only deltas; data that never changes never gets re-transmitted.
>
> Chris
>

Duplicati does this.  It's really well-designed and does exactly what
you want.  It also does encryption as well.

If this PoC is sound (it appears to be) then Duplicati can be repurposed
to substitute for Duplicity altogether.

File-based backup really does sound like the right thing to do, for so
many reasons.  It's really dumb to back up big, big files, even if they
could be done incrementally (as I do with my own Duplicity-based
solution for dom0).

-- 
Rudd-O
http://rudd-o.com/

-- 
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/6b1b528c-e9c1-7034-fd77-c81f59b18163%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] qubes partitioning questsion

2017-02-18 Thread Manuel Amador (Rudd-O)
Separate /usr is not supported.

There is no point in sub mount points under /var/lib/qubes.  /var/lib/Qubes is 
enough as a single mountpoint.

There is no point in /var/lib/* sub mount points.  Or /var/log for that matter. 

You don't have to have /home under a mountpoint.  Dom0 /home should be empty if 
you are using Qubes right.

Use btrfs instead of LVM.  That way you can do subvolumes.

On February 18, 2017 8:21:10 AM PST, Oleg Artemiev  wrote:
>Hello,
>
>I'm about to upgrade from Qubes 3.0 to Qubes 3.2 now.
>
>I've two terabites (1 ssd and 1 hdd) in my laptop and 16Gigs of
>memory. Is separation to different mount points as proposed below
>is a good idea? Please note if you think that something could also be
>moved to ssd. My criteria for ssd stuff is "oftenly read, very rare
>write".
>
>
>As everything is encrypted , thus no need in gpt - dos partition table.
>
>ssd:
>/   - 400Мb
>/usr - 5G0b
>/boot - 300Mb
>/var/lib/qubes/vm-templates - 350Gb
>/var/lib/qubes/vm-kernels   - 3.5Gb
>/var/lib/rpm- 100Mb
>/var/lib/yum- 50Mb
>
>individual catalogues under /home// - up to 100 mount points ,
>unsure which ones are rewritten rarely an thus worth moving to ssd,
>thus will move after upgrade.
>
>hdd:
>/a_copy_of_/boot - 300Mb
>/tmp - 32Gb - looks like it has to be not less
>then biggest VM size
>swap - 32Gb
>/home - 100Мб
>/var/log - 300Mb
>/var/log/
>
>BTW: Looks like LVM thin provisioning gives at least two times slower
>writes, so I'm about to use usual LVM.
>
>
>-- 
>Bye.Olli.
>gpg --search-keys grey_olli , use key w/ fingerprint below:
>Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
>Blog keys (the blog is mostly in Russian):
>http://grey-olli.livejournal.com/tag/
>
>-- 
>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/CABunX6MReuC_Q9B2NYjHjKnvRLc%2BJeaWaywxF%3DLV8rYpiT32DQ%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/E7D8002A-6C9C-46DE-A29B-CC354E62C469%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Resize dom0

2017-02-18 Thread Manuel Amador (Rudd-O)
It is the standard procedure to enlarge any root partition on any Linux — 
enlarge encrypted volume, enlarge LVM physical volume, enlarge enlarge LVM 
logical volume, enlarge root file system.  You will have to do this from a 
rescue initramfs or another Linux system you booted from.

On February 18, 2017 2:23:29 AM PST, "Zbigniew Łukasiak"  
wrote:
>There are instructions how to resize a VM at
>https://www.qubes-os.org/doc/resize-root-disk-image/ - but this cannot
>apply to dom0 - because it requires stopping the VM and then running
>commands in dom0. What would be the procedure for resizing dom0 root
>partition?
>
>-- 
>Zbigniew Lukasiak
>http://brudnopis.blogspot.com/
>http://perlalchemy.blogspot.com/
>
>-- 
>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/CAGL_UUvH1mT_LP57dS6DO5ksNDEf%3DZWA0XiruH7rzM455GHkdg%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/395BD576-E36E-442E-AEEF-152205714914%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] MP3 support but SMB issues on DebVM or SMB support with MP3 issues on FedVM?

2017-02-18 Thread Manuel Amador (Rudd-O)
Create a mount unit in your template of the Deb VM, which does the mount.  Have 
it WantedBy=multi-user.target.  Enable it.

Add a ConditionPathExists=/var/run/qubes-service/mediamount to the unit.

Power off the template and the Deb VM.

Thru Qubes Manager, add a Qubes service to the DebVM, naming it mediamount.

Power on the template.

Bam, now that thing mounts only in the Deb VM.

I have an Ansible play for this.  Will publish it soon.

On February 18, 2017 9:05:57 AM PST, "'.' via qubes-users" 
 wrote:
>I have been trying to get a "proper" music setup working on my Qubes
>(3.2) machine and am having issues. On a Fed24VM I can't seem to get
>mp3 support (tried installing gstreamer no go) and on Deb9 I can
>connect to my file server via the filemanager but can't find where it
>is mounting (where as I can just type "mount" in Fed and the last entry
>is usuall the mount point).
>
>I love VLC for videos, but despise it for music (compared to what I
>want in a music player). I was able to run foobar2k with wine before
>(which apparently took care of MP3 support issue in Fed) but that is an
>unweildy option and I think Quod Libet player will suffice (which I
>have installed on both Deb/Fed VMs no prob).
>
>I would prefer to use a debVM for my music but could use some
>suggestions on how to include a line to mount it to a point i can find.
>I have tried mount -t smb //fileserver/directory
>/media/testmountdirectory and a few variations (like CIFS) but nothing.
>I don't have a password on set on the server at the moment and when I
>mount via the file manager I just put in smb://fileserver/directory it
>prompts me to connect and I'm in.
>
>How can I set a Deb "AudioVM" to automatically mount the
>music_directory so it can be accessible to something like Quod Libet?
>
>-- 
>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/vS162_w02q8XeVvlJYqXCAPP0iOD1oRX3Pr8Bw_YVyTlMqv60sDcBeRbDle1W0m02n_GT2k7oyLC1cL9GBOQZMbG7qaHPgQOqv6odmYrEUw%3D%40protonmail.ch.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/55D5F7FA-B2FC-4403-99B1-535C7BD4DE9E%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] NetVM without firewall, no PING from outside?

2017-02-17 Thread Manuel Amador (Rudd-O)
Qubes-network-server takes care of this for you.

On February 14, 2017 2:02:18 AM PST, Jarle Thorsen  
wrote:
>> Unman:
>> > I suggest you read the docs:
>> > www.qubes-os.org/doc/firewall  has a section on allowing traffic in
>to
>> > qubes.
>> 
>> Thank you for the link. It provided a good foundation.
>> 
>> > But this may not be what you want. It reads as if you want to have
>> > sys-net operating as a router. You can do this quite simply by
>changing
>> > the iptables configuration and using proxy arp to make sure that
>the
>> > external network sees the qubes behind the router.
>> > Alternatively you could use the netvm as a gateway to the network
>of
>> > qubes, and make sure that THAT route is propagated on your internal
>> > network.
>> 
>> Thank you, it seems like using proxy arp is the way to go for me.
>That way I can still use a dynamic address for my NetVM.
>
>I'm getting back to this thread, still haven't got everything working:
>
>My NetVM is connected to a local network 10.0.0.0/16, and gets a
>dynamic IP via DHCP.
>
>AppVMs connect directly to the NetVM, without any firewall, and all
>firewall rules has been removed from NetVM.
>
>All networking is now working fine, both between AppVMs and from AppVMs
>and into the 10.0.0.0/16 network.
>
>Now I need to have the AppVMs available from the 10.0.0.0/16 network...
>
>Where do I need to enable arp_proxy to make this happen? Only on the
>NetVM interface connected to the 10.0.0.0/16 network, or also on the
>vif interfaces on the NetVM, or in the AppVMs also??
>
>-- 
>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/382450c2-11c6-40dc-9bea-03840335c104%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/FD0BEFAB-47FA-45D7-9CB6-7207675511A4%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Minimal VM requirements for Salt configuration are not documented

2017-01-22 Thread Manuel Amador (Rudd-O)
On 01/20/2017 08:58 AM, qu...@posteo.de wrote:
> Hi,
>
> I am trying to setup all VMs with Salt since the switch to Fedora 24.
>
> I usually took the minimal template and create the others on base of
> this with more packages.
>
> The problem is that the Qubes salt documentation does not document
> what the minimal requirements on packages are for deploying salt and
> receiving.
>
> For example if I install in the minimal fedora 24 template
> qubes-mgmt-salt-vm-connector I still can not install any packages with
> Salt from the outside. If I use this minimal template as the default I
> can not deploy Salt anymore to templates which can be updated with
> Salt because they have all the necessary packages. 

You're going to need at the very minimum python-dnf.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/a6913e0b-4211-2f4f-d2a2-42fce10e2c35%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Fedora Desktop in Qubes

2017-01-07 Thread Manuel Amador (Rudd-O)
On 12/24/2016 05:58 PM, Andrew David Wong wrote:
>
> This is not true. Dropbox doesn't even start automatically, much less
> communicate automatically. If you install Dropbox in a Fedora
> TemplateVM according to the above instructions, the Dropbox daemon
> will *not* start automatically in any AppVM based on that template.
> You have to start it manually. (After starting it manually, you can
> configure it to start whenever the VM starts up, if you wish.)
>

I believe the RPM installs a desktop file in the autostart directory so,
yes, it does start automatically.

You can mask it, though.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/24b5a466-8ad9-b91a-6f9f-44ac7c51185e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Fedora Desktop in Qubes

2017-01-07 Thread Manuel Amador (Rudd-O)
On 12/21/2016 11:13 AM, Patrick Bouldin wrote:
> Hi, I saw some threads on this but am not clear at a high level.
>
> I thought I would install dropbox client on one of my Fedora VMs so that 
> working with files is much smoother than from a browser. So, is installing a 
> Fedora Desktop the best plan to do that? Don't assume I know enough of native 
> Qubes ability please - maybe I'm missing a key point!
>
> Thanks,
> Patrick
>

Run this Ansible recipe on the AppVM where you will be installing your
Dropbox client:


---

---
# It is assumed that the template will have wget.  I could probably use
get_url if it didn't demand a checksum...
- hosts: localhost
  tasks:
  - name: deploy Dropbox
command: creates='{{ ansible_env.PWD }}/.dropbox-dist' chdir={{
ansible_env.PWD }} wget -O -
"https://www.dropbox.com/download?plat=lnx.x86_64; | tar xzf -
  - name: deploy real Dropbox autostart file
copy:
  content: |
  [Desktop Entry]
  Name=Dropbox
  Comment=Run the Dropbox service
  Exec={{ ansible_env.PWD }}/.dropbox-dist/dropboxd
  Terminal=false
  OnlyShowIn=QUBES
  Type=Application
  NoDisplay=true
  dest: '{{ ansible_env.PWD }}/.config/autostart/dropbox.desktop'
  owner: user
  group: user
  mode: 0644

---


Restart the AppVM.  The Dropbox icon should appear on the taskbar now.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/74438f01-da56-0bfa-d747-7c188142dd0d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to rollback Dom0 updates?

2016-12-12 Thread Manuel Amador (Rudd-O)
On 12/10/2016 09:51 AM, Simon wrote:
> Hello everybody,
>
> Is there a way to rollback updates which corrupted a Qubes-OS system?
>
> I checked DNF history, but it seems to have been disabled / bypassed
> for all events following the OS installation back in September:
>
> - 8< --
>
> [user@dom0 ~]$ sudo dnf history
> ID | Command line | Date and time| Action(s) 
> | Altered
> ---
>
>  5 | --exclude=qubes-template | 2016-09-19 21:10 | Install   
> |1  <
>  4 | remove cairo-dock-plug-i | 2016-09-07 18:19 | Erase 
> |   19 >
>  3 | --exclude=qubes-template | 2016-09-07 14:34 | Install   
> |   14  <
>  2 | --exclude=qubes-template | 2016-09-07 14:24 | Install   
> |5 ><
>  1 |  | 2016-09-04 17:57 | Install   
> |  937 >E
>
> - 8< --
>
> Is there any equivalent feature allowing update rollback in Qubes-OS
> for the Dom0 domain?
>

The reliable way to do rollbacks is to:

1. Install Qubes OS on a btrfs file system.
2. Install the dnf / yum plugin that will snapshot your system right
before upgrades.

Slightly less convenient:

1. Migrate your Qubes OS to ZFS.
2. Manually ZFS snapshot your Qubes OS before dom0 / template upgrades.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/142947de-d3bb-7ff3-38ff-aee3edb7e4a0%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to backup an iPhone under Qubes

2016-12-08 Thread Manuel Amador (Rudd-O)
On 10/05/2016 08:23 PM, qu...@posteo.de wrote:
> Hi,
>
> how can I back up my iPhone without a separate Os?
>
> I have installed Windows 10 in an HVM and tried to add both USB
> controller devices but then the VM does not start.
>
> Backing up via Wifi does not work because the HVM is behind a NAT.
>
> I have not tried WIndows 7 because I have not access to it.
>
> So is there any solution which does not require another os or another
> computer?
>
> Thx in advance
>

Qubes network server may be able to add the ability for Windows to join
your LAN with its own IP address, thereby making it visible to your phone.

https://github.com/Rudd-O/qubes-network-server

but, frankly, I have never tested it with Windows.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/2fdcc24e-486e-c6c5-f3e7-b0a17a7aaf77%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Shortcuts of PlayonLinux

2016-12-05 Thread Manuel Amador (Rudd-O)
On 12/05/2016 09:46 AM, peter tseng wrote:
> I installed window applications by PlayonLinux and the shortcuts generated in 
> /home/user/desktop. then I copy those shortcuts to /usr/share/applications 
> but I can't see any of them in Add more shortcuts setting. I surely run 
> qvm-sync-appmenus XXXVM. Any solution?

The destination directory — was it on the templatevm?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/eebf6758-6a19-e538-bf7f-327ac44ded56%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Issue with hdmi

2016-12-04 Thread Manuel Amador (Rudd-O)
On 12/05/2016 04:27 AM, Patrick Bouldin wrote:
>
> ** 2nd update ** while the above update is true, unfortunately when the 
> machine hibernates the only thing that brings the display back is a cold boot.
>
> So it seems to be associated with losing the hdmi somehow - causing the 
> machine not to be responsive to keyboard wake-up.
>
> Any clues?

You may have to enable serial port kernel console terminal for
debugging.  That's usually very difficult on a laptop.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/3e17ddd9-2c38-104a-53c6-5b5e1861ff80%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Any plans for a CCC meeting?

2016-12-01 Thread Manuel Amador (Rudd-O)
I have a couple friends who are huge fans of Qubes OS and they are going
to CCC.  Since they are not subbed to this list, I'd love to know if
there's a meeting of Qubes OS devs and users planned for CCC, so I can
tell them and they can go.

Any plans?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/aab6c8c9-fe6d-4ee7-c298-ca6901ad8a0a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Bluetooth locking (was Re: [qubes-users] safer typing in public places)

2016-11-30 Thread Manuel Amador (Rudd-O)
On 11/30/2016 04:18 AM, pixel fairy wrote:
> has anyone here experimented with bluetooth locks? it seems like a lot of 
> extra scary code to run in dom0, but i like the idea of auto shutdown if 
> device loses range. or maybe after a timeout period of some trigger?thats 
> another discussion. 

On your Bluetooth VM (usually a USBVM), run Blueproximity, and have
Blueproximity invoke a custom /etc/qubes-rpc/pixelfairy.Lock service on
dom0 which you will need to write yourself.  It's a one-liner service:

loginctl lock-sessions

To invoke it from the Bluetooth VM, you need to ask Blueproximity to run
the command:

/usr/lib/qubes/qrexec-client-vm "$bluetoothvm" pixelfairy.Lock

Once you have given the Bluetooth VM permission ("yes to all") to invoke
the locker, it should work automatically every time you walk away.

The reverse is also possible — you could have a similar service that
unlocks the screen by running loginctl unlock-sessions.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/cd707267-d4c1-2a3c-a155-1d2cb89e850e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] desktop sharing, capturing and screenshoting

2016-11-19 Thread Manuel Amador (Rudd-O)
On 11/19/2016 09:30 AM, Ray Brainer wrote:
> I am having hard time to make desktop sharing in Qubes.
> Within VM I see white screen.

X server in VM does not allow screengrabs at all.  Security measure.

> Installing software on dom0 and using it in broadcast is denied.
> What should I do?
>

dom0 does not allow networking.

You may be able to hook some sort of bridge using qvm-run --pass-io and
socat, but it sounds like a bad idea.

Qubes OS is intended to be a highly-secure OS.  Sharing the screen of
dom0 with other machines defeats that purpose entirely.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/faf934d9-1d53-0f2f-14da-c89db68d2c79%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to rotate VPNs?

2016-11-17 Thread Manuel Amador (Rudd-O)
On 10/29/2016 03:09 AM, Gaiko Kyofusho wrote:
> Is it possible to set up a VpnVM to automatically/randomly switch
> between vpn servers? At the moment I have to manually replace
> openvpn-client.opvn file with another file (with other server info)
> every time I want to change, would be great if I could at least have a
> menu that would give me the choice of which server I use or randomly
> cycle through servers.
> -- 
> 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/CAGpWZxNH-2%3DWUuk0YXy9dxn1wBNTyow3MrWU62h6pxTt4snfdQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

Can you file a ticket for a feature request on
https://github.com/Rudd-O/qubes-vpn ?  Thanks.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/39a88389-4aa6-c4b7-9ec5-91f3aa595d7b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: Qubes network server

2016-11-17 Thread Manuel Amador (Rudd-O)
On 11/07/2016 02:29 PM, Max wrote:
>
> This worked first time!
>
> I pinged from the Debian AppVM to a new Fedora AppVM. I checked that the 
> pinging did not work first and then went through the steps to change the 
> Fedora AppVM to connect to the proxy server NetVM, assign a static IP, 
> restart, set the firewall rules and then ping.
>
> In the meantime, could I ask if it is possible to do what I am trying to 
> achieve  by adjusting the iptables? I reported my troubles attempting to do 
> this here: 
> https://groups.google.com/d/msg/qubes-users/Dan7LNLv048/pkT_O2tDAAAJ

It's not clear to me what you are trying to achieve.  Can you describe
it in English with examples?


-- 
Rudd-O
http://rudd-o.com/

-- 
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/ab23a251-6ecd-cc49-1ed4-e9bf5a786dba%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-11-17 Thread Manuel Amador (Rudd-O)
On 11/09/2016 01:38 PM, SEC Tester wrote:
> Hey Rudd-O,
>
> Thanks for your effort and great contribution to the Qubes community. Not 
> sure why Chris was critical, especially without specifically showing evidence 
> of any problems. Maybe just a troll?
>
> I  haven't tried your program out yet, Im keeping it as my backup option, as 
> im still hoping to find a way to get my AirVPN GUI to work. I would prefer a 
> GUI over a CLI, especially when i might want to switch servers quickly or 
> look at my stats.
>
> As you seem like such an expert on this, i was hoping you could have a look 
> at my post, and see if you could workout whats going wrong?
>
> https://groups.google.com/forum/#!topic/qubes-users/T0wbCuIgISg
>
> If you have the time that would be Awesome! Cheers.

I don't really know how that VPN software works, honestly.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/f1e99ec5-280d-b131-0d0e-2d5d263fc5ab%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

2016-11-17 Thread Manuel Amador (Rudd-O)
On 11/12/2016 08:58 PM, Chris Laprise wrote:
>
> That was my first reaction, too. But years later, I am so, s glad
> ITL de-emphasized kernel-based security.
>
> If they had kept it as a supported security layer, the
> "security-in-depth" mindset would have dominated most of our
> discussions and attention... essentially eaten our brains like it does
> to everyone else. Seriously, this stuff can be perniciously
> misleading, and the moment that "authoritative" voices in the
> community start looking down their noses at "dinky little 1MB
> hypervisor" compared with their heavy bookshelves full of standard
> admin guides and certifications... that's when the security zombies
> start encroaching.
>
> Therefore, I think it is up to the community to promote the Linux
> extra security measures as a kind of add-on. Enabling it could be a
> good thing IF and only if we can do it with minimal effort and
> distraction. But keep it far away from pre-installed or supported status.

Actually, enabling things like GRSECURITY / PaX / SELinux by default
adds security, so it is better than not enabling it.  The only question
is what sort of usability problems it can carry.  But something that
will prevent, say, Firefox from doing arbitrary shit when owned, that
would be absolutely great.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/dccafd8b-b4c9-a848-b1f3-41e3b21ae8c9%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Does the Standard Firewall-VM Actaully do anything?

2016-11-17 Thread Manuel Amador (Rudd-O)
On 11/17/2016 04:20 AM, Sec Tester wrote:
> It also raises the question,
>
> Is there any benefit running a VPN-Proxy-VM through sys-firewall?
>
> Or maybe save the overhead and just connect VPN-Proxy-VM directly to sys-Net?
>

Either works.  With the firewall in between, you can limit the outbound
traffic from the VPN VM to strictly VPN traffic and nothing more.

I have explanatory drawings here: https://github.com/Rudd-O/qubes-vpn

-- 
Rudd-O
http://rudd-o.com/

-- 
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/92dde6e3-df91-ccfa-27d2-8a91bb8d0535%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

2016-11-13 Thread Manuel Amador (Rudd-O)
On 11/12/2016 03:21 AM, Sec Tester wrote:
> SELinux or AppArmor.

SELinux would be absofuckinglutely great.  Confined apps like Firefox
would run much more securely.

I got one DispVM owned by an attacker at Defcon in 2014.  Isolation was
nice to have because the machine didn't get owned, but the VM would have
never been owned if SELinux had been active.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/c6aa365c-7c11-1ff1-6cac-482f1db0d329%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ANN: Qubes network server

2016-11-06 Thread Manuel Amador (Rudd-O)
On 11/05/2016 03:54 PM, Max wrote:
>
> Thanks for the response!
>
> I ran this and also ran 'sudo dnf install go' when I came across the 
> following error: 'go is needed by qubes-network-server-0.0.4-1.fc23.noarch'.

A commit is now out which eliminates this dependency.

> I then did the cd into the cloned folder and the 'make rpm' function has 
> appeared to have worked.
>
> I followed the steps to get this to Dom0 and then installed the RPM. It may 
> be better to add to the documentation 'sudo rpm -ivh qns.rpm' as I wasn't 
> initially sure that I actually had to name the file. It helps the noobs! 
>
> The purpose for me for installing the network server was to be able to ping 
> my Debian VM from my Windows VM.
>
> These are the configuration steps I took subsequent to install:
>
> 1) Created a ProxyVM named server-proxy.
> 2) Changed the NetVM on both work-apps (my Debian 8 VM) and windows-7 (HVM) 
> to the new ProxyVM

Sorry, I should have clarified that HVMs are not supported at all.  I am
very, very sorry.  I need to do more work to get HVMs to work properly
("more" is an euphemism for I have totally forgotten so far to support
that use case).  It is totally my fault that I did not explain this in
the documentation.  My bad.  I have updated the documentation to reflect
that.

If you could help me, do report what happens when you ping between a
Fedora and a Debian AppVM, or two Debian AppVMs.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/2d0b8050-8aa1-6b4b-c952-2c054f147930%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Your Battery is syping on you...

2016-11-04 Thread Manuel Amador (Rudd-O)
On 11/04/2016 08:32 PM, 198730178489710317470139 wrote:
> Hello,
>
> good to know that Firefox and other mainstream-browser's spy-features don't 
> work inside the Q-VMs.
>
> But here are many ways to find out, who is sitting in front of the screen, 
> without get logged in, e.g. also keyboard-typing-patterns and mouse 
> movements...
>
> So for ebanking and free of digital dicriminating shopping I should use 
> Whonix?

For ebanking you want to use a normal AppVM that does not have the
Whonix stuff.  They will fingerprint you.

For shopping you want to use a separate normal AppVM that does not have
the Whonix stuff.  They will fingerprint you.

BUT

Those fingerprints will be different and so sites you visit on your
shopping VM will not know about your banking habits in any way, and vice
versa.

For regular browsing you want to have a separate VM that has hardened
settings and uses stuff like User Agent Spoofer with all the Firefox
fingerprinting settings disabled (battery, gamepad, audio, WebGL, et
cetera), as well as uMatrix to disable HTTP requests that you have not
authorized.  This VM can totally be a Whonix browser + Tor combo.  I
think I will post a guide for that soon enough.

Just remember: Don't bank where you surf, don't shop where you bank,
don't surf where you shop.


-- 

Rudd-O
http://rudd-o.com/

-- 
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/639a26e7-f6a1-5b07-2fa7-9f97f24068bb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Display Calibration and Audio Equalizer for Dom0 ?

2016-11-04 Thread Manuel Amador (Rudd-O)
On 11/02/2016 06:28 PM, Marek Marczykowski-Górecki wrote:
>
> > @Marek:
> > Do you have any idea what to look for in order to be able to calibrate
> > my screen under Qubes?
>
> I have no idea how such software works... Especially at which stage
> calibration is applied. Is it something that application does
> "internally", or adjust display driver options?

I believe it tweaks the gamma of the X server?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/cc1c4576-004e-195c-5ddf-a5534b659053%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Your Battery is syping on you...

2016-11-04 Thread Manuel Amador (Rudd-O)
On 11/02/2016 09:49 PM, '109384'019834'09128'340932189 wrote:
> Hello,
>
> in Q the Firefox battery fingerprinting is enabled.
>
> https://blog.lukaszolejnik.com/battery-status-readout-as-a-privacy-risk/
>
> Manual you might disable it:
>
> 1. start Firefox
> 2. open the URL about:config 
> 3. scroll down to dom.battery.enabled and disable this feature
>
> It would be nice if the DispVM has running a Firefox, which don't support the 
> fingerprinting (or even better, a real secure-browser...)

Battery access to the system battery is disallowed because the DispVM /
AppVM does not have access to the hardware.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/dddc3ce5-3b7b-c038-23ad-ba9e34fbeb4d%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: Qubes network server

2016-11-03 Thread Manuel Amador (Rudd-O)
On 11/02/2016 07:03 AM, Max wrote:
> On Thursday, 13 October 2016 01:31:01 UTC+8, Manuel Amador (Rudd-O)  wrote:
>> Update:
>>
>> I have dramatically enhanced the documentation of the project:
>>
>> * https://github.com/Rudd-O/qubes-network-server
>> *
>> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20your%20first%20server.md
>> *
>> https://github.com/Rudd-O/qubes-network-server/blob/master/doc/Setting%20up%20an%20SSH%20server.md
>>
>> This project is now ready and documented enough to be useful to users of
>> Ansible Qubes who want to remotely manage clusters of Qubes OS machines:
>>
>> *
>> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Remote%20management%20of%20Qubes%20OS%20servers.md
>> *
>> https://github.com/Rudd-O/ansible-qubes/blob/master/doc/Enhance%20your%20Ansible%20with%20Ansible%20Qubes.md
>>
>> I strongly welcome anyone who tries this and shares their experiences. 
>> It is my goal to get this to be a key part of the Qubes OS strategy.
>>
>> -- 
>>
>> Rudd-O
>> http://rudd-o.com/
> For the "make rpm" command you refer to the local directory of your clone, is 
> there a tutorial you recommend I should follow for doing this?

That *is* the tutorial.  cd into your clone, then type "make rpm"
(without the quotes).

-- 
Rudd-O
http://rudd-o.com/

-- 
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/94c88b53-223c-fbd6-e438-6be8ab0d0171%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3 MacOSX

2016-10-30 Thread Manuel Amador (Rudd-O)
On 06/17/2016 04:11 AM, Drew White wrote:
>
>
> On Sunday, 15 May 2016 14:05:50 UTC+10, Jeremy Rand wrote:
>
> FWIW, I think a legal argument could be made that such license
> agreements are anti-competitive and therefore unenforceable.
>  However,
> I am unaware of any specific precedent for this argument, so it would
> indeed probably be unwise for ITL to violate the license agreement
> unless their goal is to win the inevitable lawsuit and thus achieve a
> beneficial precedent.  (And while that would be laudable, I would
> definitely not blame ITL if they decided that such activities are not
> worth their effort or budget.)
>
> (And of course, I'm not a lawyer.)
>
>
> Well, in the end, I own a mac, It's not breaking any agreement or
> anything for me wanting to run it.

Yeah you are.  Check the licensing terms for the Mac OS X software that
came with it.

Not that it matters, as it's a bullshit "agreement" that transforms a
purchase into somewhat of a feudal renting system of objects.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/87694b7c-33f9-8a1c-fd26-14d1f361e02e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How to view Youtube in Fullscreen ? (for dummies)

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/27/2016 01:31 AM, raahe...@gmail.com wrote:
> On Wednesday, October 26, 2016 at 5:15:53 PM UTC-4, jamie wrote:
>> does not matter if I use fedora, debian or whonix ... whenever I press 
>> fullscreen on any youtube video the brower freezes..
>>
>> it also does not matter which browser I use firefox, chromium,...
>> all of them freeze.

I can confirm this issue.  It's not that they freeze, they continue to
run and you can see window updates when you resize the window, but it's
simply that they stop updating after hitting that damn fullscreen
button.  This is a new bug and I recommend you file a ticket in
https://github.com/QubesOS/qubes-issues/new .

>>
>>
>> how to watch youtube videos 'for dummies' in fullscreen ? 
>> how to enable fullscreen mode 'for dummies' in my fedora appVM ?
> hmm I've only had the issue on firefox, maybe related?  
> https://github.com/QubesOS/qubes-issues/issues/1502
>


-- 
Rudd-O
http://rudd-o.com/

-- 
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/3e47b747-25e4-8254-f06a-f06abb947cac%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] "Start Button" and "Task Bar" are Missing

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/27/2016 02:00 PM, Scott Bourne wrote:
> On Wed, Oct 26, 2016 at 9:22 PM, Andrew David Wong  > wrote: >
> On 2016-10-26 09:25, scot...@gmail.com  wrote:
> > I installed R3.2 yesterday and everything looked and worked fine,
> but today when I started my machine up, I only have the VM Manager
> window - no 'task bat' and no 'start' button.
>
> > How can I get them back without doing a complete re-install?
>
>
> Some questions:
>
> * Are you using Xfce4 (the default desktop environment in 3.2)?
>
>
> > Yes, I am
>
>
> * Have you reboot the machine before or after having this problem? In
> other words, was this the first reboot since installing? Does the
> problem persist across reboots?
>
>
> > Yes - and it persists across reboots.  When I first installed it,
> the taskbar and button were there, but after my first reboot, were gone.
>
>
> * Did you do anything you can think of that might have triggered this
> problem? Any configuration changes?
>
>
> > No changes. New and inexperienced user and was very cautious -
> trying to follow tutorials as closely as possible.

Which tutorials?  It would be good to guard against any
incompatibilities created by them.  We need to know what you did, or
what you remember you did, in order to diagnose the problem 100%.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/79d7b4d6-5848-286a-15c7-a082f6984830%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to destroy files without leaving any traces ?

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/27/2016 01:31 PM, 7v5w7go9ub0o wrote:
>
>
> On 10/27/2016 12:14 PM, Manuel Amador (Rudd-O) wrote:
>> On 10/26/2016 04:46 PM, maritnez wrote:
>>> you have a file that contains sensitive banking data and would like
>>> to delete it without leaving any traces on your system.
>>>
>>> you can 'move it to trash'
>>> which moves it to the trash
>>>
>>> you can then press the delete button in your trash container but
>>> is this really securely deleting the file without any chance of
>>> recovering it?
>>>
>>>
>>> how to delete files without leaving ANY trace from it?
>>>
>> Here is what happens when you do that in a VM, assuming the data is
>> stored in /home or /rw:
>>
>> 1. VM file moves to trash.
>>
>> 2. you empty the trash in the VM.
>>
>> 3. In 5 seconds, the VM kernel's ext4 file system commits the metadata
>> change to /dev/xvdb, and discards the data blocks that were occupied by
>> the file.
>>
>> 4. The discard makes its way to dom0's
>> /var/lib/qubes/appvms/vm/private.img by way of the loopback device that
>> was connected to the VM in representation of the private.img file.
>>
>> 5. Since loopback devices honor discard, and since loopback devices
>> mapping files issue PUNCH_HOLE or zero out the relevant data on the
>> file, that means the discard operations make their way into private.img
>> as either blocks zeroed out or PUNCH_HOLE operations.
>>
>> 6. The dom0 file system hosting that private.img file can do any number
>> of things about these incoming operations:
>>
>> 6.1. If ext4: after 5 seconds, the discard operation makes its way to
>> the underlying block device; this may be 100% ineffectual in rotational
>> devices that do not support discard, and may also be 100% ineffectual in
>> the case of SSDs as they may decide to forego deleting the data and just
>> add those disk regions to a fresh pool of writable flash (while keeping
>> the "zeroed" data hidden from you. but certainly not from governments)
>>
>> 6.2. If ext4 on top of LVM: ask someone else, as I'll put it bluntly: I
>> do not know what that shit does, and I do not know if anyone knows.
>>
>> 6.3. If ZFS or btrfs: the file system code will do copy on write, which
>> means the blocks will still be available in some other region of the
>> disk, until they get overwritten by new writes.  Worse still, if the
>> data you just tried to zero out in the VM actually happens to be in a
>> file system snapshot of dom0, then by definition it will not ever get
>> deleted, until you kill the snapshot and zero out all storage on the
>> devices.
>>
>> It's more complex than that, though.
>>
>> First rule of thumb: IF you wrote X to disk, THEN be sure X is going to
>> be there.
>>
>> Second rule of thumb: IF you read data chunk X with a program at some
>> point, THEN it's likely that X is going to be on disk too, because of
>> swap (read -> memory -> swapout -> disk).
>>
>> The way to get around these rules of thumb is (a) make sure that data
>> always hits the disk encrypted (b) make sure to never ever let any
>> adversary read from that disk while unencrypted, or obtain the key to
>> that disk.
>>
>> The takeaway: deleting data is REAL HARD.  You better have a good
>> encryption password.
>>
>> The honest, cheap-to-execute answer to your question is: get a blowtorch
>> and torch the individual data-bearing parts of the drive, until each
>> part changes color, and then some.  Don't breathe the magic smoke coming
>> out of these parts — it may kill you.
>
>
>
> (Heh... "magic smoke", eh!?)
>
> (Newbie question:) Is there a possibility of using "mlock" to block
> swap;  working entirely in ram - de-crypting the imported subject file
> using "tmpfs" interim files, then exporting the updated, encrypted
> subject file back to vault (or out the door)?

tmpfs is swappable by default.  You would have to swapoff.

> I'd guess this would leave you vulnerable only to someone hands-on
> dumping your memory? I'd presume doing all of this in a DispVM would
> preclude some "relic" remaining in a Domain. (One wouldn't want any
> (encrypted) relics in case of a rubber-hose interrogation and demand
> for passwords.)

I do not know what the status is on keeping the whole DispVM in RAM, but
there is an issue filed on the matter.  Check the qubes-issues Github repo.

>
> p.s. Thank You for your helpful postings here!!
>
>


-- 
Rudd-O
http://rudd-o.com/

-- 
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/b01247de-7999-98ef-90f0-e0bb3cffb4cb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Crashplan?

2016-10-28 Thread Manuel Amador (Rudd-O)
On 06/26/2016 03:40 PM, Andrew David Wong wrote:
> On 2016-06-26 04:27, Niels Kobschaetzki wrote:
> > Hi,
>
> > does anyone have experiences with running Crashplan in Qubes? If
> > yes, how did you install it?
>
> > Niels
>
>
> I installed it in a StandaloneVM with the installer's default options.
>
> (As I'm guessing you've discovered, attempting to install it in an
> AppVM with the default options doesn't allow it to persist across
> reboots since it tries to install parts of itself to the read-only
> root filesystem.)
>

There is a persist dirs option.  Look for bind-dirs.sh in the
qubes-core-agent-linux package.  This should let certain directories
persist for good in any AppVM (but, of course you don't want to do that
for system dirs like /usr/bin and such).


-- 
Rudd-O
http://rudd-o.com/

-- 
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/d2c28aca-8ac4-7954-07d2-6626ca344010%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Internal networking: How are IPs chosen, why class C subnet.

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/28/2016 08:51 AM, Robert Mittendorf wrote:
> Hey,
>
> yesterday I noticed that even if VMs share a class C network, all
> trafic is routed through the gateway and by default the gateway does
> not allow a connection to other VMs in the same subnet.
> This makes a lot of sense from a security perspective, but the shown
> information is missleading.

qubes-network-server does the right thing if you have a number of VMs
with assigned static IPs.  Traffic gets routed to the right VM.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/f2af19a4-7839-1a34-41e6-f57bf19b2cad%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/28/2016 09:40 AM, Marek Marczykowski-Górecki wrote:
>
> Actually yes, we may hook qubes-gui-agent.service into graphical.target
> and call it "display manager", preventing others from running. This is
> good idea, but something I'd like to avoid as a stable update - so, for
> Qubes 4.0.

Yes, this would be a good start.

>
>> I believe the correct thing to do is to create the necessary
>> configuration for the default display manager to start qubes-guid with
>> autologin.  This will also give us a complete desktop session inside the
>> VM, 
> This is exactly what we want to avoid. We don't want another window
> manager there (which would be fighting with the one in dom0), as well as
> a ton of other useless things like panels, clock icons etc. Excluding
> this crap makes Qubes VMs lightweight enough to run 20+ of them at the
> same machine.

I was not suggesting you run a window manager.  Just a qubes-guid
session.  No window manager whatsoever.  Certainly not clocks, or
panels, or any of that shit.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/68bd52bc-ad96-f342-0989-869fbc97fb6c%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/28/2016 10:51 AM, cyrinux wrote:
> Le jeudi 27 octobre 2016 13:47:14 UTC+2, Manuel Amador (Rudd-O) a écrit :
>> It gives me great pleasure to announce the inter-VM Git bridge for Qubes
>> OS, which allows you to git push and git pull from VMs stored in other
>> repos, with no networking involved whatsoever, and observing full
>> compliance with Qubes OS qrexec policy.
>>
>> This should usher in a new era of software development that allows
>> people to segregate their secure Git repos from insecure build VMs and
>> other engineering constructs I can't even think of (after doing
>> low-level socket programming for a week, which has left my brain utterly
>> fried).
>>
>> Find the software at https://github.com/Rudd-O/git-remote-qubes
>>
>> ---
>>
>> # Inter-VM Git for Qubes OS
>>
>> This is a very simple Git protocol bridge between Qubes OS VMs.  With it,
>> you can `git pull` and `git push` between VMs without having to grant
>> any of the VMs any special policy privileges other than access to Git.
>>
>> ## Using the software
>>
>> These instructions assume you have installed the software.  See the
>> *Installing the software* heading below for more information.
>>
>> ### Creating a repository
>>
>> We'll assume for illustration purposes that you want to access a repository
>> stored in `/home/user/xyz` on your VM `servervm`.
>>
>> Run the following commands on `servervm`:
>>
>> ```
>> cd /home/user
>> mkdir -p xyz
>> cd xyz
>> git --bare init
>> ```
>>
>> That's it.  Your new and empty repository is ready to use.
>>
>> ### Adding a remote to a local repository
>>
>> For illustration purposes, you'll be pushing and pulling `servervm`'s `xyz`
>> repo on your vm `clientvm`.  Run the following commands on `clientvm`:
>>
>> ```
>> cd /home/user
>> git clone qubes://clientvm/home/user/xyz
>> ```
>>
>> You will get a permission dialog from dom0 asking for `ruddo.Git` access.
>> Accept it.  Note that accepting the permission dialog implicitly gives
>> Git access to all Git repos stored in `servervm`, but only for that one
>> execution (unless you say *Yes to all*, in which case the permission
>> is remembered within the policy file that you installed earlier with the
>> `dom0` package).
>>
>> This should have cloned `xyz` from `servervm` into your `/home/user/xyz`
>> directory in `clientvm`.
>>
>> From this point on, you can push and pull in `clientvm` from
>> `servervm:/home/user/xyz` to your heart's content.
>>
>> If, instead of cloning, you have an existing repo, you can add a new remote
>> just as easily:
>>
>> ```
>> cd /home/user/existingxyz
>> git remote add qubesremotevm qubes://servervm/home/user/xyz
>> ```
>>
>> That addition will enable to push and pull from the remote `qubesremotevm`
>> which represents the repo `/home/user/xyz` in the remote VM `servervm`.
>>
>> ## Installing the software
>>
>> There are two components for this software:
>>
>> * Component 1 is the VM side of things, which implements the Git protocol
>>   across VMs.
>> * Component 2 is the dom0 side of things, which is a simple text file
>> declaring
>>   the initial Git access policy for your VMs.
>>
>> First, build the software,  After cloning this repository on a suitable VM,
>> run the command:
>>
>> ```
>> make rpm
>> ```
>>
>> This will generate two installable packages on the local directory:
>>
>> * `git-remote-qubes-.noarch.rpm`, which contains the Git
>>   protocol implementation.
>> * `git-remote-qubes-dom0-.noarch.rpm`, which contains the
>>   default policy.
>>
>> Copy the `git-remote-qubes-.noarch.rpm` file to the template VM
>> or standalone VM where you plan to pull or push to / from a Git repo
>> stored in another Qubes VM.  Install the RPM with
>> `dnf install `.  At this point, this VM, as well as
>> any VMs using this as a template, have gained the ability to push and pull
>> from Git repos stored in other VMs, as well as the ability to listen on
>> push / pull requests from different VMs in the same system.
>>
>> Now copy the `git-remote-qubes-dom0-.noarch.rpm` file to
>> your dom0.  At this point, the default policy (`deny`) is active on
>> your Qubes OS system, and you can begin pushing and pulling.
>>
>> Those clever among you will have discovered that there is a `Makefile`
>> included, and

Re: [qubes-users] Re: Introducing the qubes-announce read-only mailing list

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/28/2016 05:02 AM, Achim Patzner wrote:
> Am 28.10.2016 um 02:00 schrieb Drew White:
>> On Friday, 28 October 2016 10:57:03 UTC+11, Andrew David Wong  wrote:
>> We've just introduced a new mailing list: qubes-announce
>>> So it's a forum, not a mailing list >
> No, darling. It's a mailing liist. The contents are transferred to
> registered users by mail and only those subscribed will receive it. The
> contents are distributed by SMTP. The link he sent is an explanation
> page on a web server.
>
> Don't pretend to be dumber than you are, it doesn't make you look better.
>
>
> Achim
>

Forgive me for asking this:

Anyone else beginning to get annoyed with Drew's constant participation
that contributes nothing of value, and in fact often detracts from the
value of the mailing list?

I don't want to be mean, but it's like we have our own Ken M in this
mailing list, and it is Drew.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/7bc77a5f-d86c-249f-6153-c7083568fce4%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-28 Thread Manuel Amador (Rudd-O)
On 10/28/2016 01:56 AM, Marek Marczykowski-Górecki wrote:
> On Thu, Oct 27, 2016 at 03:31:46PM +0200, Marek Marczykowski-Górecki
> wrote:
> > On Thu, Oct 27, 2016 at 09:50:56AM +0200, Zrubi wrote:
> >> On 09/06/2016 01:24 AM, Marek Marczykowski-Górecki wrote:
> >>
> >>> I've just tried this and successfully upgraded Fedora 23 to Fedora 24
> >>> template.
> >>>
> >>> TL;DR version:
> >>> 1. Clone fedora-23 to fedora-24-test.
> >>> 2. Open terminal in fedora-24-test.
> >>> 3. Run "dnf upgrade --releasever=24".
> >>> 4. Shutdown the template.
> >>> 5. Switch (some of?) VMs to this template.
> >>>
> >>
> >> Just tried to upgrade my templates and got this error:
> >>
> >>
> >> Error: Transaction check error:
> >>   file /usr/lib64/libpython3.so from install of
> >> system-python-libs-3.5.1-17.fc24.x86_64 conflicts with file from
> package
> >> python3-libs-3.4.3-12.fc23.x86_64
> >>
> >>
> >> Was not able to workaround it, because(?) those libs are used by dnf
> >> itself :o
> >>
> >> The official fedora upgrade way:
> >> https://fedoraproject.org/wiki/DNF_system_upgrade
> >>  seems not compatible with Qubes
> >>
> >>
> >> any hints how to solve this?
>
> > I haven't tried recently, but it worked before. Maybe a workaround would
> > be to disable "updates" repository for the upgrade time? Just add
> > --disablerepo=updates.
>
> Or another idea: use `dnf distro-sync --releasever=24`, instead of `dnf
> upgrade`. Not sure if that helps.
>
> > I think it may be possible to use "official" upgrade method, by
> > switching to pvgrub first:
> >
> https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm
> > But in practice probably it will be more complex than just following
> > that instructions...  Maybe worth a try?
>
> Actually, it looks like it almost works this way, even without switching
> to pvgrub. The only problem is that we put "3" on kernel cmdline, which
> forces systemd going into multi-user.target (instead of
> system-update.target). This can be worked around by putting
> "systemd.unit=system-update.target" on the template kernel command line
> ("kernelopts" property) before starting second phase of the upgrade.

We should not be putting 3 in the kernel command line, and we should not
be modifying the default target in qubes-core-vm-systemd either.  What
we should do is do the necessary work to get the default system
configuration to work when we boot a VM into graphical.target (the
default).  That way we avoid these integration issues.

I believe the correct thing to do is to create the necessary
configuration for the default display manager to start qubes-guid with
autologin.  This will also give us a complete desktop session inside the
VM, and XDG autostart as well, as opposed to just a tiny stub that
doesn't have e.g. password manager environment or GPG agent.

This area is ripe for research, and it's time we matured in that
direction.  Also noteworthy is that, with the move to Wayland, this sort
of work is very apropos.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/822d780c-e039-f80b-3808-c6c8e740ffa7%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Networking between two vms?

2016-10-28 Thread Manuel Amador (Rudd-O)
On 04/08/2016 02:17 PM, edev.u...@gmail.com wrote:
> On Sunday, February 1, 2015 at 11:45:05 PM UTC-5, Marek Marczykowski-Górecki 
> wrote:
>
>> By default firewallvm blocks all the inter-vm traffic. But you can add a
>> rule to allow that. Take a look here:
>> https://wiki.qubes-os.org/wiki/QubesFirewall#EnablingnetworkingbetweentwoAppVMs
> The above guide requires both VMs to be connected to the same firewall vm.
>
> I have a case when one vm is a proxyvm connected to a separate NIC via a 
> dedicated netvm and I want to connect the proxyvm to the default sys-firewall 
> vm. How can I enable networking between these two vms?
>

To enable transparent networking between VMs, you can also use:

https://github.com/Rudd-O/qubes-network-server

Just give your two VMs different IP addresses and they will work.  Of
course, the firewall rules still need to be set, if the VMs are attached
to a ProxyVM.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/385f673c-f103-07e8-af90-3d70428d3645%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Windows HVM doesn't get updates

2016-10-28 Thread Manuel Amador (Rudd-O)
On 04/10/2016 11:34 PM, Salmiakki wrote:
> Well, maybe. I haven't looked at traffic yet. Is there a simple way to
> do that with qubes?

sudo tcpdump -i eth0 -nn in the ProxyVM that your Windows VM is attached to.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/ef0825ab-29be-31a1-f382-538ac61a8d5a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-27 Thread Manuel Amador (Rudd-O)
On 10/27/2016 11:37 PM, Drew White wrote:
> On Thursday, 27 October 2016 22:47:14 UTC+11, Manuel Amador (Rudd-O)  wrote:
>> It gives me great pleasure to announce the inter-VM Git bridge for Qubes
>> OS, which allows you to git push and git pull from VMs stored in other
>> repos, with no networking involved whatsoever, and observing full
>> compliance with Qubes OS qrexec policy.
> You can either do that and use something that will absorb RAM, OR you can 
> just add the iptables rules, they work easier and faster than adding ANOTHER 
> layer.
>
> Just look for the post I put up months ago regarding the rules for it.
>

Actually, it's the other way around — your solution requires some sort
of daemon continuously running on the machine serving the repos, such as
git daemon or sshd.  That costs RAM.

And your solution requires networking too, which makes it impossible to
apply your solution to serve repos stored in non-networked VMs.

But thanks for pointing this out so I can update the README with these
advantages.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/5d7da42c-f427-4b6a-a074-2ac17e191a9e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: Request for test: Re: [qubes-users] Fedora 24?

2016-10-27 Thread Manuel Amador (Rudd-O)
On 09/06/2016 11:10 AM, Achim Patzner wrote:
> Some key bindings might have changed; ctrl-"+" in a terminal window
> increases the font size but the terminal window does not grow with it
> anymore.

Finally!  The GNOME people finally unfucked Ctrl++!

-- 
Rudd-O
http://rudd-o.com/

-- 
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/0192cadb-f62e-3955-96c1-5770609ec274%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-27 Thread Manuel Amador (Rudd-O)
On 10/27/2016 12:03 PM, Robert Mittendorf wrote:
> Just saw the Qubes VPN project right now.
>
> Quick-reading the tutorial I have to questions:
>
> 1) why does the VPN-VM need to be allowed to do DNS,

The VPN VM does not need to be allowed to do DNS.  You can set an IP in
its configuration and then no DNS is needed.

I will expand the instructions to indicate that.

> if DNS requests are routed through the VPN. Is it just in case the VPN
> server it wants to connect to is defined by hostname instead of IP?

No.  The DNS requests of the chained AppVMs are routed to the DNS
servers declared by the VPN server.  The DNS requests of the VPN VM
itself are routed to the DNS servers of the NetVM that is upstream of
the VPN VM.

> 2) why is the recommendation to allow all hosts for the VPN server
> (and not only the VPN servers IP)?

No reason.  I will clarify that there's no need to do that.

>
> thank you
>

Thank you for helping me clarify the documentation.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/1324039e-5a32-e200-b60b-533a9ad56ceb%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-27 Thread Manuel Amador (Rudd-O)
On 10/27/2016 09:15 AM, cyrinux wrote:
>
> Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no 
> problem, this seems perfect ;)

Thank you very, very much.  You are very kind for taking the time to
give public appreciation for my work :-)


This is the stuff I live for.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/e9c69164-c780-7755-8c1f-fb258676900b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] ANN: git-remote-qubes: Inter-VM Git for Qubes OS

2016-10-27 Thread Manuel Amador (Rudd-O)
It gives me great pleasure to announce the inter-VM Git bridge for Qubes
OS, which allows you to git push and git pull from VMs stored in other
repos, with no networking involved whatsoever, and observing full
compliance with Qubes OS qrexec policy.

This should usher in a new era of software development that allows
people to segregate their secure Git repos from insecure build VMs and
other engineering constructs I can't even think of (after doing
low-level socket programming for a week, which has left my brain utterly
fried).

Find the software at https://github.com/Rudd-O/git-remote-qubes

---

# Inter-VM Git for Qubes OS

This is a very simple Git protocol bridge between Qubes OS VMs.  With it,
you can `git pull` and `git push` between VMs without having to grant
any of the VMs any special policy privileges other than access to Git.

## Using the software

These instructions assume you have installed the software.  See the
*Installing the software* heading below for more information.

### Creating a repository

We'll assume for illustration purposes that you want to access a repository
stored in `/home/user/xyz` on your VM `servervm`.

Run the following commands on `servervm`:

```
cd /home/user
mkdir -p xyz
cd xyz
git --bare init
```

That's it.  Your new and empty repository is ready to use.

### Adding a remote to a local repository

For illustration purposes, you'll be pushing and pulling `servervm`'s `xyz`
repo on your vm `clientvm`.  Run the following commands on `clientvm`:

```
cd /home/user
git clone qubes://clientvm/home/user/xyz
```

You will get a permission dialog from dom0 asking for `ruddo.Git` access.
Accept it.  Note that accepting the permission dialog implicitly gives
Git access to all Git repos stored in `servervm`, but only for that one
execution (unless you say *Yes to all*, in which case the permission
is remembered within the policy file that you installed earlier with the
`dom0` package).

This should have cloned `xyz` from `servervm` into your `/home/user/xyz`
directory in `clientvm`.

>From this point on, you can push and pull in `clientvm` from
`servervm:/home/user/xyz` to your heart's content.

If, instead of cloning, you have an existing repo, you can add a new remote
just as easily:

```
cd /home/user/existingxyz
git remote add qubesremotevm qubes://servervm/home/user/xyz
```

That addition will enable to push and pull from the remote `qubesremotevm`
which represents the repo `/home/user/xyz` in the remote VM `servervm`.

## Installing the software

There are two components for this software:

* Component 1 is the VM side of things, which implements the Git protocol
  across VMs.
* Component 2 is the dom0 side of things, which is a simple text file
declaring
  the initial Git access policy for your VMs.

First, build the software,  After cloning this repository on a suitable VM,
run the command:

```
make rpm
```

This will generate two installable packages on the local directory:

* `git-remote-qubes-.noarch.rpm`, which contains the Git
  protocol implementation.
* `git-remote-qubes-dom0-.noarch.rpm`, which contains the
  default policy.

Copy the `git-remote-qubes-.noarch.rpm` file to the template VM
or standalone VM where you plan to pull or push to / from a Git repo
stored in another Qubes VM.  Install the RPM with
`dnf install `.  At this point, this VM, as well as
any VMs using this as a template, have gained the ability to push and pull
from Git repos stored in other VMs, as well as the ability to listen on
push / pull requests from different VMs in the same system.

Now copy the `git-remote-qubes-dom0-.noarch.rpm` file to
your dom0.  At this point, the default policy (`deny`) is active on
your Qubes OS system, and you can begin pushing and pulling.

Those clever among you will have discovered that there is a `Makefile`
included, and that you can use the `Makefile` to install the software on
other non-RPM templates.  I welcome pull requests to add support for
other distro packages and Qubes OS templates.

## Troubleshooting and debugging

If you are experiencing problems communicating with a Git repo in a VM,
export the variable `QUBES_DEBUG` on the side of your client (where your
local Git repo is), and look at the debugging output that appears.

As always, you can file new issues on the repo of this project for help
with fixing bugs that the programs may have.  Pull requests also welcome.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/1f1dc56f-4d34-c9e1-6d15-f497fc7e5822%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: Leakproof Qubes VPN

2016-10-26 Thread Manuel Amador (Rudd-O)
Apologies for the reply to self, but I have received great news.

The first piece of great news is that a user of Qubes VPN found a bug
that made it impossible for Qubes VPN to work with tun-style VPN
providers.  We have fixed that bug thanks to his cooperation, and you
can see the result of our bug report and conversation here:

https://www.reddit.com/r/Qubes/comments/57acz8/add_a_leakproof_vpn_to_your_qubes_os_with_this/

The second piece of great news is that, based on what he reported there,
ABSOLUTELY NO TRAFFIC ever leaked from his VPN-protected AppVM to any
sort of network device, as the VPN VM still prevented the traffic from
going anywhere else except over the VPN.

That means: even under an environment where a critical bug rendered VPN
operation impossible, Qubes VPN still managed to prevent leaks 100%.

I am quite happy to see that the engineering gone into this thing
actually paid off big time.

Have you tried Qubes VPN yet?

-- 

Rudd-O
http://rudd-o.com/

-- 
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/667e45a5-0278-ca7a-0cd4-3bc0101ff045%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Privacy issue in DisposableVMs

2016-10-22 Thread Manuel Amador (Rudd-O)
DisposableVMs have Firefox cookies for Google and other websites in
them, unless you have customized the homedir of the DVM as per the
instructions in the documentation pages.

To read the details, please refer to:

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

To mitigate:

I recommend deleting the /etc/dispvm*tbz file from your DispVM template,
deleting all the *-dvm VMs, and recreating the DVM template with
qvm-create-default-dvm --default-template

-- 
Rudd-O
http://rudd-o.com/

-- 
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/47012b3e-f8cd-8528-791f-6fc423cb0c53%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Most Secure way to encrypt your usb stick ?

2016-10-22 Thread Manuel Amador (Rudd-O)
On 10/22/2016 12:09 PM, lakschmi wrote:
> have sensitive data on your usb stick?
>
> whats the best way to encrypt/decrypt it?
>
>
>
> normally I use whonix-ws pgp and encrypt every file but Id rather have a 
> different method
>
>
>
> is there a way to install the tails os ecryption system in qubes os?
> I prefere it over the whonix workstation system.

Install gnome-disks on the template of whonix-ws (then power off
template, and power on the actual machine), then plug your USB, then use
qubes-manager to passthru the USB to your VM, then open gnome-disks.

>From there you can format the disk with LUKS encryption and FAT32 inside
the encrypted container.

After doing so, every time you plug it back in, and pass it thru, just
open the file manager and click on the drive in the sidebar.  This will
prompt you for your password and voila, decrypted.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/8a6a0213-e121-6cb2-669b-42712640ceb7%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes R3.2, cannot find redshift{-gtk} packages on dom0

2016-10-20 Thread Manuel Amador (Rudd-O)
On 10/20/2016 01:47 AM, Pablo Di Noto wrote:
> Hello all,
>
> I have reinstalled R3.2 and want to install Redshift (and its GUI) on dom0 
> again.
> I do not recall how I did it on R3.1, and successive updates.
>
> I see on a Fedora 23 VM that redshift and redshift-gtk are available in the 
> `updates` repository. 
>
> But cannot find how to access these (or equivalent) repositories on dom0. 
> Used `qubes-dom0-update --enablerepo=XXX` with many different repositories 
> mentioned in FAQs and other posts here with XXX={updates, 
> qubes-dom0-current-testing, qubes-dom0-security-testing, qubes-dom0-unstable, 
> ...} but all return "Unable to find a match".
>
> What am I missing?
>
> Thanks in advance,
> ///Pablo
>

Curious here: what is Redshift and why would it be a good idea to
install it in dom0?  Not judging, just curious.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/1dc6500b-92b1-2445-4f14-26d2539928d2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: philosofy on qubes and other environment

2016-10-20 Thread Manuel Amador (Rudd-O)
On 10/20/2016 05:12 PM, pleom...@gmail.com wrote:
> @Jeremy Rand
>
> realy sorry about that,i didnt think that someone get some emails.

THOUSANDS of us get "some emails" from you.

> But this thing of system security is important.
>

The fact that security — which you do not seem to understand how it
works — is important, does NOT excuse you spamming the entire list with
many, many poorly-researched allegations that each are one line.

This is not your personal chat room.

Next time, compose your ideas in a single e-mail, and then send them as
a single e-mail.

PLONK!

-- 
Rudd-O
http://rudd-o.com/

-- 
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/fcbe5432-fc25-9e4c-e1cd-d91d49832459%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Attaching USB 3g modem to sys-net.

2016-10-20 Thread Manuel Amador (Rudd-O)
On 10/20/2016 05:03 PM, f03gu9h3u9fh3...@gmail.com wrote:
> Is there no software route i can take? Is is not possible to virtualize a 
> specific device and then attach that to the VM or something alike?
>
> I could just get 2 PS/2 adaptors for my keyboard and mouse and set up a 
> dedicated USBVM then proxy my 3g modem device to sys-net. 
>

USBIP / Xen USB passthrough.

It ought to be possible, at a cost of reduced security, to pass through
individual devices from the dom0 to the NetVM, where they should appear
as regular USB devices that you can just use.

It also ought to be possible to use USBIP to pass through individual
devices from the USB VM (if you are using one) to the NetVM, where
(again) they should appear as regular USB devices.

I have not tried these things, I must say.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/c80e55c2-d80a-f0fe-55a3-41e3f2d144c2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   >