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

2016-10-27 Thread cyrinux
Le mercredi 26 octobre 2016 14:38:24 UTC+2, Manuel Amador (Rudd-O) a écrit :
> 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/

Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no 
problem, this seems perfect ;)

-- 
You received this message because you are subscribed to the Google Groups 
"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/7cf989a6-91cf-4281-94b5-32701272fa4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] 3.2 Install: Error unpacking qubes-template-fedora-23

2016-10-27 Thread me
I'm trying to install Qubes 3.2 on a Thinkpad T450s (i7), which is listed on 
the hardware compatibility list as being generally successful with both 
releases 3.1 and 3.2.

I have had to use the UEFI Lenovo workaround documented at 
https://www.qubes-os.org/doc/uefi-troubleshooting/ so my install process has 
been as follows:

- dd write a checksum and signature verified Qubes-R3.2-x86_64.iso to a 32GB 
USB drive
- Enable legacy boot in the Thinkpad BIOS
- Boot from the USB drive
- Select "Troubleshooting" > "Boot from local disk" to enter secondary GRUB menu
- Highlight the "Verify and Install" option and press 'e'
- Add '/mapbs /noexitboot' to the 'chainloader' GRUB line
- Press ctrl-x to boot with modified config
- See successful verification of the USB drive contents and launch of Qubes 3.2 
installer
- Secondarily verify the install media from the "Installation Source" GUI panel
- Configure install destination to "reclaim all space" by deleting the existing 
partitions and use the automatic paritioning
- Begin the install

About halfway through the progress bar, the status reads:
"Installing qubes-template-fedora-23.noarch (800/930)"

Switching to tty-1 with ctrl-alt-f1 shows the error message:
"Error unpacking rpm package qubes-fedora-23-3.0.6-201608081228.noarch"

If left along for long enough, this rpm task seems to error out completely and 
get skipped over to finish the rest of the installation.  I then add the 
documented UEFI workaround to /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg.

After rebooting into the Qubes install, asking the Configuration helper to set 
up the default system qubes (sys-net, sys-firewall) fails with an alert message:

[Dom0] Error 
['/usr/bin/qubes-prefs'. '--set', 'default-template', 'fedora-23'] failed:
stdout: ""
stderr: "A VM with the name 'fedora-23' does not exist in the system."

I'm confused about why such a specific package would consistently fail to 
install from good installation media over multiple install runs on my laptop.  
I've now tried with two different USB drives and ISO files from different 
sources.

When running the installed Qubes, manually adding the package to dom0 with:

sudo yum install 
/run/media//Qubes-R3.2-x86_64/Packages/q/qubes-template-fedora-23-3.0.6-201608081228.noarch.rpm

installs successfully and provides the fedora-23 vm template in the VM Manager, 
from which I'm able to create a new NetVM and connect to a wired network.  So 
that's all working, once it's in place.

I would very much like to have the default sys-net and sys-firewall qubes.  The 
way I see it, there are two semi-automated ways to get them:

1) Re-run the firstboot qubes-anaconda-addon now that the fedora-23 vm template 
is installed.

2) Re-install again, manually adding the qubes-template-fedora-23 package 
before the reboot so that it's available for the normal firstboot process.

[Implicit option 3) Figure out and manually type the sys-net and sys-firewall 
creation commands by picking through the qubes-anaconda-addon source.]

Any helpful hints come to mind?

Thanks,
Evan

-- 
You received this message because you are subscribed to the Google Groups 
"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/8d246f46-132a-4b52-97a3-73fc3fc01e5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2016-10-27 Thread Zrubi
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?

Thanks.


-- 
Zrubi

-- 
You received this message because you are subscribed to the Google Groups 
"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/74308bcb-80b6-9992-9240-14da9073c5b9%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Configuration web server

2016-10-27 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 10/26/2016 02:37 PM, Roberto Fock wrote:
> i have a sys-net with ip 192.168.1.33 (mask 255.255.255.0) and ip
> 10.137.4.1 (mask 255.255.255.255). Also I have a firewall with ip
> 10.137.4.6 (mask 255.255.255.255). By ultimo i have a web server
> with ip 10.137.z.z. My router have ip 192.168.1.1. In the
> configuration nat of my router put 192.168.1.33. How to configure
> of web server with ip public in qubes. I need to use iptables?
> 
> (Tengo la siguiente estructura en mi qubes: *sys net con ip
> 192.168.1.33 mask 255.255.255.0 e ip 10.137.4.1 *firewall con ip
> 10.137.4.6 *un servidor web con otra ip del tipo 10.137.x.x En la
> configuracion nat de mi router puse 192.168.1.33 para que permita
> salir a internet por el puerto 8084. Es decir, para que la pagina
> se vea en el puerto 8084. Ahora, cómo configuro qubes para que el
> sitio pueda verse desde intenet. Tengo que usar iptables?)
> 
> 

Look here https://www.qubes-os.org/doc/qubes-firewall/

"Port forwarding to a VM from the outside world" section.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYEZwMAAoJEBQTENjj7QilsBIQAJP+2uIXa6Ckp5jTMtntyxEl
MNl+YNoGjJfiAn4+EtjVahQ0ATnzi/8XXw4Q7pU1UaWGbcpl+ffEESFZuMI1TOqA
UZpDG0DGBP2QsOFsEH4TzbFwKD7CxaQN6O5ehacSUhrSj2kS4I5b8tq6xsxzDV/y
1knNCOr7nOCrlEhxRPOdNtt92v9PtNnCCPOFl/SdRc3GU72Whhi3oSUzYRpl4klP
isDHfZjfrfABbF638vJjHJbR8RbN50/JCkwZ6b8QJ5K1gLtj1I6Mm03035vM4eCW
8Hq+CBkBI4hgrUG6ZBtXkG137KzqZ5ZyhbCbWiuAMWSN4CjbHQgk2sijQVuQCzx8
X+wJQMhtfCXu9bVixUc0sZ29Ej3m6WSnTezaq/L8CjJGPEThzwlzSUTDo/Wc+yuL
33udBrIFtlBYItnYKC5hgql2Bwlwx24XSHVvz6ogH6dqWfEmuJW9cvzuvrlaAgro
FKbji9VuRD6iXVmx0mQeYWnEuj0uNeNxeUB4RWGtqX2ECiHxUgSTd0yD5LnWSHNT
zAz5K4L6Wwl6DwbqJXff30/ISuPXi82QcqeSY72hc864/hHct59r4Yj0tyB80kLR
p8i4zftTKXE08b/8w5CpZYYNbyeva3Uk5qDcMPs4mJNnwqAkaBqJpiT41Wo/Iuz6
uFttX/oxcEtARsGBHPtb
=Yukd
-END PGP SIGNATURE-

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


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

2016-10-27 Thread Robert Mittendorf
You can enable full screen mode, in that mode browser fullscreen works. 
The video tends to be flickering, I think because of missing hardware 
acceleration.


However other applications like RDP cause problems in fullscreen mode. 
In that case you cannot switch to another window without disconnecting.
If you try, the RDP viwer looses context of at least the keyboard, 
sometimes of the mouse as well.
Your only chane then is to pull the plug to make FreeRDP disconnect 
after a timeout.


--
You received this message because you are subscribed to the Google Groups 
"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/50ee485b-1502-7160-641b-5e9348f742a4%40digitrace.de.
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-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.


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

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, 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?
2) why is the recommendation to allow all hosts for the VPN server (and 
not only the VPN servers IP)?


thank you

--
You received this message because you are subscribed to the Google Groups 
"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/b4c85024-1da2-f674-5082-801720fde365%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Windows is NOT starting after windows-tools installation... help

2016-10-27 Thread Robert Mittendorf

Windows problems may have a lot of reasons.
Sometimes after a failed boot windows wants to start "boot help" (or 
whatever its called in English) and defaults to use it. As you do not 
see this selection in Qubes (only if you enable debug mode) it boots 
into that mode and Qubes is tuck at yellow for that VM. Try debug mode 
and non-seamless.


--
You received this message because you are subscribed to the Google Groups 
"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/c8b3deff-2029-251c-a0a5-40ef14f07d8c%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


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

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

[qubes-users] Re: HCL - DELL PRECISION T7400

2016-10-27 Thread ludwig jaffe
updated hcl file.


On Thu, Oct 27, 2016 at 11:23 AM, ludwig jaffe <ludwig.ja...@gmail.com>
wrote:

> One mistake:
>
> the command is i8kfan speed 1 1
>
> Also I did not check if VT-d enabled works now with the current version
> (including current updates) of qubes 3.2, as I was lazy.
> I will check later and read the bios first with a flash programmer just to
> be sure not to destroy anything. But the machine boots,
> why updating the bios. I will do it later...
>
>
>
> Have fun.
>
>
>
> On Thu, Oct 27, 2016 at 11:18 AM, ludwig jaffe <ludwig.ja...@gmail.com>
> wrote:
>
>> Hi, I am running Qubes 3.2 on my Dell-Monster.
>> 2 flaws:
>> 1st: if I enable VT-d the machine crashes while or after booting the
>> xen-kernel
>> (I experienced it with the older kernel the one prior 4.4.14-11!) I also
>> run old BIOS A2 instead of A11 as I fear upgrade, as
>> it could brick the machine if this gets wrong.
>> 2nd: the fans are sometimes *really* noisy,
>> like a starting concorde, but the processer is quite cool.
>> So one needs to run
>> ik2fan speed 1 1 to get it quite silent. One small fan still
>> is to loud. I need to find it. I guess it is the nvidia graphics
>>  fan.
>>
>> Important: It should be possible to install additional software
>> to dom0 with more comfort!
>> Doing yumdownload (some package) and then copy it using the
>> command line tools as they are nice but ugly to use w/o cut and
>> paste to dom0 :-(
>>
>> Maybe, you should include these packages to the dom0 repository
>> as there are also noisy dell laptops around...
>>
>> What I did to get the fans more silent is to make sure to have lm_sensors
>> (was provided in dom0 repository, thanks, installed by default?)
>>
>> Then I did the more unpleasent stuff:
>> yumdownlod of the packages in personal vm, of course...
>>
>> on dom0:
>>
>> qvm-run --pass-io personal 'cat 
>> /home/user/dell/i8kutils-1.33.-8.fc22.x86_64.rpm'
>> > /home//i8kutils-1.33.-8.fc22.x86_64.rpm
>> qvm-run --pass-io personal 'cat /home/user/dell/tk-8.6.4-2.fc23.x86_64'
>> > /home//tk-8.6.4-2.fc23.x86_64
>> qvm-run --pass-io personal 'cat /home/user/dell/tk-8.6.4-2.fc23.x86_64.rpm'
>> > /home//tk-8.6.4-2.fc23.x86_64.rpm
>> qvm-run --pass-io personal 'cat /home/user/dell/tcl-8.6.4-1.fc23.x86_64.rpm'
>> > /home//tcl-8.6.4-1.fc23.x86_64.rpm
>> qvm-run --pass-io personal 'cat 
>> /home/user/dell/i8kutils-1.33.-8.fc22.x86_64.rpm'
>> > /home//i8kutils-1.33.-8.fc22.x86_64.rpm
>> qvm-run --pass-io personal 'cat 
>> /home/user/dell/i8kutils-1.33-8.fc22.x86_64.rpm'
>> > /home//i8kutils-1.33-8.fc22.x86_64.rpm
>> qvm-run --pass-io personal 'cat 
>> /home/user/dell/gkrellm-2.3.7-2.fc23.x86_64.rpm'
>> > /home//gkrellm-2.3.7-2.fc23.x86_64.rpm
>> qvm-run --pass-io personal 'cat 
>> /home/user/dell/libntlm-1.4-4.fc23.x86_64.rpm'
>> > /home//libntlm-1.4-4.fc23.x86_64.rpm
>>
>> sudo dnf install tk-8.6.4-2.fc23.x86_64.rpm
>> sudo dnf install tcl-8.6.4-1.fc23.x86_64.rpm
>> sudo dnf install libntlm-1.4-4.fc23.x86_64.rpm
>> sudo dnf install gkrellm-2.3.7-2.fc23.x86_64.rpm
>> sudo dnf install i8kutils-1.33-8.fc22.x86_64.rpm
>>
>> all w/o cut and paste :-(
>>
>> But now there is silence:
>>
>> ik8fan
>> 1 1
>>
>> As it was loud it said:
>> ik8fan
>> 3 3
>>
>> to get it silent type
>> ik8fan 1 1
>>
>> ik8fan 2 2 is a acceptable loud.
>>
>>
>> check the temperature with sensors. And also open the case
>> to feel the two cooler blocks, to check if the computer lies to you.
>>
>>
>> So thats all, for now, thanks for qubes, it is cool on such
>> an old machine as the machine is cheap and ddr2 ecc memory
>> is quite cheap.
>> This box can theoretically pimped upto 128GB.
>> 2 CPUs with 4 cores each and 40GB are enough for the moment.
>>
>>
>> Have fun
>>
>> Ludwig
>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAP7JdrJFo2c%3DRiS%3DD7fRP5HhaNoXrLS4xN8rfEP83jyqHyorgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Dell_Inc_-Precision_WorkStation_T7400__-20161027-104558.yml
Description: application/yaml


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

2016-10-27 Thread ludwig jaffe
dd if=/dev/urandom  of=/home/noob/myporn.jpg

-- 
You received this message because you are subscribed to the Google Groups 
"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/3e0c5e02-9875-46dd-a23c-4fe61ef6ba7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HCL - DELL PRECISION T7400

2016-10-27 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Oct 27, 2016 at 11:18:47AM -0400, ludwig jaffe wrote:
> Hi, I am running Qubes 3.2 on my Dell-Monster.
> 2 flaws:
> 1st: if I enable VT-d the machine crashes while or after booting the
> xen-kernel
> (I experienced it with the older kernel the one prior 4.4.14-11!) I also
> run old BIOS A2 instead of A11 as I fear upgrade, as
> it could brick the machine if this gets wrong.

There is a chance that BIOS upgrade will improve the situation here. I'd
recommend checking BIOS changelog / release notes.

> 2nd: the fans are sometimes *really* noisy,
> like a starting concorde, but the processer is quite cool.
> So one needs to run
> ik2fan speed 1 1 to get it quite silent. One small fan still
> is to loud. I need to find it. I guess it is the nvidia graphics
>  fan.
> 
> Important: It should be possible to install additional software
> to dom0 with more comfort!
> Doing yumdownload (some package) and then copy it using the
> command line tools as they are nice but ugly to use w/o cut and
> paste to dom0 :-(
> 
> Maybe, you should include these packages to the dom0 repository
> as there are also noisy dell laptops around...
> 
> What I did to get the fans more silent is to make sure to have lm_sensors
> (was provided in dom0 repository, thanks, installed by default?)
> 
> Then I did the more unpleasent stuff:

(...)

You can do this much more convenient way:

sudo qubes-dom0-update i8kutils

Also, it will be much more secure, as manually downloading rpm packages
(via yumdownloader) do not enforce signature being checked.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYEkTVAAoJENuP0xzK19csHi4IAIjtvyim6WGEM1JGU71xoOVr
sCSEgqi9ufqeTUMcewH6kFGXr1QjSGNIdqJ9FFRdx4oAj8MPKlmlv19Z6GCpwrHr
RKlF9ut3tYPOulKiMFKMDdyu4e4IjJZJH3kX8Cj8SXi/M8LCtpe9zwxdH2rRnDjd
cdn3bk3Ni5f/eIlTeSiL/6vHvZOcSylmQJOgsA7w8zD9wh3VAie2yWP96OArQPkm
hKLEE8KJFSryNAAiod2DFOsHC2nI6IsscJLPfE6AztqdLPj5Nqv7UCgZSMJ2zZBM
q7LcREu6rvb79NELhmWextPS2QaOAJfCe314fReDViHapbh5sw67sHA/Axxj+44=
=STCE
-END PGP SIGNATURE-

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


[qubes-users] windows7 hangs on installation

2016-10-27 Thread scheurer13 via qubes-users
Hello together,

i try to install a win7hvm but after the first boot screen it hangs on 
"Starting Windows" screen.
I tried to increase the memory, enabled the debug mode but no success.

Here my steps:
1. First installed the windows tools
2. qvm-create win7hvm --hvm --label green
3. qvm-start win7hvm --cdrom=HomeVM:/media/user/win7.iso (also tried an local 
iso)

Can somebody help?

Thanks and best regards
Thorsten

-- 
You received this message because you are subscribed to the Google Groups 
"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/f5195d69-87eb-4db7-8768-fd5b984cc9a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HOW TO: Set up Netowrking for Kali HVM

2016-10-27 Thread kenflyy14
Wanted to do a quick run down on how to set this up.
I am using Kali MATE, so yours may look slightly different, but the commands 
are the same.

Create your standalone KALI machine. If you haven't got it installed, here 
isn't where you should be.

Shutdown your working kali hvm.

Once it's off, right click your hvm and go into your kali VM settings.

Under the General tab, note the following

Netowrking:
IP: X.X.X.X
Netmask: XXX.XXX.XXX.X
Gateway: X.X.X.X

Now right above that, set the NetVM dropdown to Sys-Firewall (what works for me)

Start your VM
Log into root, or standard user with SU access

open the following file with your favorite editor

/etc/network/interfaces

if you see 

auto eth0 dhcp

Remove it

add the following

auto eth0
iface eth0 inet static
address (IP from earlier)
netmask (netmask from earlier)
gateway (gateway from earlier)

save and close.

Now, open this file with your favorite editor

/etc/resolv.conf

add the following

nameserver (gateway from earlier)

save and close.

Shutdown.

Run the Kali VM and open terminal. verify your settings applied with 

ifconfig

run some ping tests against your gateway, google.com, etc.

test internet.






Hope this helps someone.

-- 
You received this message because you are subscribed to the Google Groups 
"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/d50f0559-7929-46a8-b204-a02ed9e61937%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Crashplan?

2016-10-27 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-27 13:38, Vincent Elliott wrote:
> On Friday, 21 October 2016 22:54:53 UTC-5, Andrew David Wong  wrote:
> On 2016-10-21 11:08, Max wrote:
 On Monday, 27 June 2016 04:21:20 UTC+8, Andrew David Wong  wrote:
 On 2016-06-26 12:07, Niels Kobschaetzki wrote:
>>> On 16/06/26 08:40, Andrew David Wong wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512

 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.)
>>>
>>> Ok, thanks. And then you transfer the data from the other VMs to
>>> that VM to back it up via Crashplan? Sounds like a lot of redundant
>>> data or do you have multiple disks (like a fast SSD for daily usage
>>> and a slow spinning disk for your backup-VM) in your computer?
>>>
>>> Niels
>>>

 I just send my Qubes backups there.


 Hi Andrew, just to confirm my understanding...

 You put your Qubes backups on a standalone VM which has Crashplan 
 installed so these backups can be selected as files and stored offsite on 
 another machine?

> 
> Correct.
> 
> 
> I installed it twice, once on the template so the service would start and 
> run, and also on the VM so that the client side would be persistent. Used the 
> default options both times.  It works.
> 
> Vincent  
> 

Yes, that's certainly another way to do it. I didn't want it installed in any 
of my templates, so I opted for a StandaloneVM. Whichever you prefer is fine.

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

iQIcBAEBCgAGBQJYEoDcAAoJENtN07w5UDAwc3sP/iQigEMpz80WTvpMo+GJL3rV
8K3ZJ+L1dpsXZKyl9Uyexdtkx8YKGqk6kniq/1pQoikcimU+jN9RESBeO6ra3q5Y
hoS8Gqtdr4N61Grv7MNEJrB05ieMV6BFsKdAv+L568r3s9yKh28cNyq00KVWJf75
Aoq8AFj06O/cyhUgDdk2MQsPiVCSmVia38+LQ91N8epej+t/tkvvQk155PkxQYUZ
IMczEuDkJf6Ao00PyUo5fCq+kKVAa1/F6soXRUepzMBj56yLs4NmHUwVt3Po1QGg
ruYmiWrxN5V/ghUlmFC2j8cxzgvhcjWIVayDmTcCuLQaTM2l5sh4eSjCzIindBXM
RTD8Xc0/4C0CkVjNJi7gIv9fLxBZqAkb+2NBYj4y+B5NLEUPY2PMWeFQOS0uP2xT
8pDNKma3v324TfiZh1UqZA9A0o2ZCO0H8DaSoWZ/dYs3DDYCALmSIlAckCiSOaQ9
ucjFGpTEoY72lEgLtwDzUC4NiGffeZQ/hz/eqDIsXHCVF89v36urSAE+kQeXatp0
B2feCJEQMn3bmioA4KWXIO7qmYX/mW+SR79sEg921ajqSgYSgqCgnO84ZdkAsa6C
NgtiBYsY07sCalAZUbD6jALyxcrnp2XnwjfL3FwrXKzhMNBtyNgQC8xzWm1snFCg
9MIKNLs4HlF2ovgSQZkl
=yxsH
-END PGP SIGNATURE-

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


Re: [qubes-users] Crashplan?

2016-10-27 Thread Vincent Elliott
On Friday, 21 October 2016 22:54:53 UTC-5, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-10-21 11:08, Max wrote:
> > On Monday, 27 June 2016 04:21:20 UTC+8, Andrew David Wong  wrote:
> > On 2016-06-26 12:07, Niels Kobschaetzki wrote:
>  On 16/06/26 08:40, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
> >
> > 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.)
> 
>  Ok, thanks. And then you transfer the data from the other VMs to
>  that VM to back it up via Crashplan? Sounds like a lot of redundant
>  data or do you have multiple disks (like a fast SSD for daily usage
>  and a slow spinning disk for your backup-VM) in your computer?
> 
>  Niels
> 
> > 
> > I just send my Qubes backups there.
> > 
> > 
> > Hi Andrew, just to confirm my understanding...
> > 
> > You put your Qubes backups on a standalone VM which has Crashplan installed 
> > so these backups can be selected as files and stored offsite on another 
> > machine?
> > 
> 
> Correct.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYCuLpAAoJENtN07w5UDAwfTQQALKGLatqCPUOsTmDavMIc8+v
> 1o1FwV55a8njlpsKPNKz0H9FverUGhSY2nfEpxaOuc/oe7mIX7ftctZOLR/ofHNm
> uAQunnzZp7zIswf936cVPqPQ7k9D57RhVEzHRpHXtOWG83orYutFXDlbsgBRHp6i
> aiJYfcHMdTgTH8428VY6VXPdVHXXHKTMDhxhGeDwuLKylDrIOnQgDZWLwooqzM7N
> dWDMPhh6OBPKpL5IB3v7Lr0M5DGCn7IShdhPtprMwKcdqRvNj+UzB0F+i55+HA3d
> sNb5RAUYi8nSk6rENMFuh8vdhA2QlFHSTCqoOwTMgXs/EtYlBNaDH32nLP+ACUZ3
> 3C4eiMQEKFdmojJJaTcoNMp8dUAbesiU74+l9o25GbPeOFZW6LKOvuIK9vvCp353
> CUHt2w+HF6c9+iKevhJL5bMsGxdXfgpKdodc4mBQzQo0fTmFdMrAl0s0xWUuHu7a
> U8jCoulblU2FseRoPPT9aLJ1ongL/NRNPH3gv6/U9faqb0XK15ETTpxKBTKFoORd
> ZTCDzfnEusInSGETZvExbntlte78tVbs6+wiGEg8+CC4bmL9cKvbQnDP7q+MJwyv
> dgmSNkRunxzjumkQq28Pc03k0MxJNgdq+SLTzehHSGvpOVcxAm6PFD6Cs1VCuX8S
> TlN0yYU1Gil6LDPRfDlr
> =WYoO
> -END PGP SIGNATURE-

I installed it twice, once on the template so the service would start and run, 
and also on the VM so that the client side would be persistent. Used the 
default options both times.  It works.

Vincent  

-- 
You received this message because you are subscribed to the Google Groups 
"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/ec4a0c4d-2207-4799-85d8-b157f844212b%40googlegroups.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-27 Thread Drew White
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.
> 
> 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 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 

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

2016-10-27 Thread Drew White
On Friday, 28 October 2016 10:57:03 UTC+11, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi everyone,
> 
> We've just introduced a new mailing list: qubes-announce
> 
> This is a read-only list for those who wish to receive only very
> important, infrequent messages. Only the core Qubes team can post to
> this list, and only Qubes Security Bulletins (QSBs) and new Qubes OS
> releases will be announced here.
> 
> Instructions for subscribing to the list are available here:
> 
> https://www.qubes-os.org/mailing-lists/#qubes-announce
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYEpQ5AAoJENtN07w5UDAw8J8P/i2mx158pBxuIXyWUAsxX5uu
> 9jTZoWdPFyV9O8YPNX6EYFpW8J0fX9fWpG1R+6/274pibtJ9u+/vjbnEFzCmIxE1
> 0jjnEH2Ayu5yCMleje2on5GN46kGJkeJknqzjM3eirCjHvAM/Q7iBoJl8a7oPUGw
> asjWGYSxFOhyDJPaa9ZB8e6yn5mE77HDZCn0gTJ+y5XNMOkSHMD/VIycHDe70jJ0
> KHUdwafpGpoo/dUGJPRT+q+FWi99EMq205mHHF7T8NKO2RgDuLzDA7CYr2WPynsS
> sw7SNf4UgOk8W9s2XuaxwwEzgUZCClMbT3tfT93aS0fXjRe+5Qn1lv+/C7Q06MH/
> EZSxqllaQ0XhTU1B/CDYZ5Xfgty90iKSbt2sVgFQyaOMPuEjgFtLKUq/pCnd8wtQ
> k3AhludRypbocQWTm1KwrvVGP5NSevBJuCyYHS1vf3TYQ/gOmLCbAkXU26VExMoR
> o//Z+uiwt2puPFmbkJrRQhtnL/BPApldLF9Q4n/qR0VOZ0jMXh47sPub+JVxEySd
> J0azketQzJWVKVUmfFAqcxkcywaohJx7r/1XiSLon1HnZ6jIOUbKS9DGEGR8BWub
> DjPSpRz0M/GZ5h4t761MhjoZ2N/jgVKhs9eM/fvO9oyKZQoTesYYgxlpDns4njf4
> wmOWv1iaq5Al0IFYNULD
> =9LW+
> -END PGP SIGNATURE-

So it's a forum, not a mailing list

-- 
You received this message because you are subscribed to the Google Groups 
"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/027f1d3a-c616-49fa-b43f-9e1fea0258d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Services still don't start even when they are there for starting in the list.

2016-10-27 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Oct 27, 2016 at 05:15:45PM -0700, Drew White wrote:
> Fedora 23 AppVM
> 
> I have several issues.
> 
> 1... Every time the AppVM starts, you rewrite the hosts file to
> remove anything that I've put in there to make
> it "127.0.0.1   {AppVMName}" instead of
> "127.0.0.1 {the domain I entered for httpd usage}"
> In an AppVM that uses a parent template, I know it would
> overwrite because of the non-persistent changes. But I've got
> my hosts file and I have it the way I have it and want it.

Only the last entry is replaced, so anything you put before actual VM
name should stay untouched. But if you still want to suppress even that,
create /etc/qubes/protected-files.d/hosts with a single line:
/etc/hosts

> 2... I put a service to start in the services tab of the
> settings in qubes-vm-settings python application, and the
> services don't start.

You probably tried to start service which doesn't support being
controlled by this mechanism. Here is list of supported services:
https://www.qubes-os.org/doc/dom0-tools/qvm-service/
And here is how to add such support for anything else:
https://www.qubes-os.org/doc/qubes-service/

> Can either of these be fixed sometime? They have been an issue I have raised 
> in Qubes 2.0 as well.

I don't want to waste my time on searching, but I believe you've got
exactly the same answer before. It's not something to be fixed, it's
something you don't know how to use.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYEpzMAAoJENuP0xzK19csCiwH/AgF3Dvp/BTMK8UDJ+h1d13B
9dVWht+VDcs4gS4xp4EYJHJOaBB9orenOetH9eDkK136u8MLGNzXuTc0EpxCuZ7t
TXodwWKXZaL2f2nbM8dtQQ8N11gn/SZfHeSvDobhfaO2j8fV2Te2ncvpdRYTmWJm
T6+leny1VB4u954UC9PLab1j96TRSjPxfVz4MvySDAu0mAM4RsANbrenkodW1yYQ
XeDJ8Dg4CRzZtiqiIrpPvYj6vHH80sssIdFE5iv3qlO5wq1gZwAMJ7ItkjGyVsKq
NCicH0S8d1rc2FKf3sV7y1Vf0hFdS01AjjAbYlk1Jt1VlISkrntUaHSzNbqRtv4=
=v2ju
-END PGP SIGNATURE-

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


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

2016-10-27 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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. So
the procedure is:
1. Clone fedora-23 template to fedora-24.
2. Start fedora-24, launch terminal
3. Proceed with https://fedoraproject.org/wiki/DNF_system_upgrade
4. Triggering a reboot will actually shutdown the template.
5. Add "systemd.unit=system-update.target" to kernel options of the
template.
6. Start fedora-24 template. It will fail to connect qrexec daemon, GUI
etc. But it will be running and performing the upgrade. Be patient, it
will take some time - for me it was about two hours on non-SSD machine.
There will be no progress information.
7. When upgrade is completed, template with automatically shutdown
itself. When it happens, remove "systemd.unit=system-update.target" from
kernel options.
8. Done.

I'll look into removing "3" from kernel command line - it would simplify
the above instruction (steps 5 and 7 will be unnecessary).

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYErAwAAoJENuP0xzK19csGrIH/iSWPIa8LmRlSta8Xv6Lyr3A
5XEZFh6nNevKGX2emPmL3K8z//cBr2gULQ7lkldo9l/RJ8Xb3nFRUrazzbLNyTcF
1YHFAGGS3W8A4ZnTMldmAAlcqzcWAX112td5QWzMtX4y++zPNEx8ZgVZ+C7WWFCX
UH5ZSVvrV0rePTbwJeE29K6n5ke6OjwsBQg6kQeamNDMPV0n9BXUls/dPPe2w4dG
9wRY8Eo40zqzaRvn+GzQ4eT9ovTaKDdAD+U2irQD80wFu1DfwNm0b8hOu5xI21FI
YvsDB8+PIuuiLrioGIYMizWfC8CZvekqpXfjTN47mi0Bhsllw4kvkG0XR2AlZns=
=w9HA
-END PGP SIGNATURE-

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


Re: [qubes-users] Re: Qubes Windows Tools 3.2.2-3 released

2016-10-27 Thread Drew White
On Thursday, 27 October 2016 03:21:09 UTC+11, Robert Mittendorf  wrote:
> After updating Qubes tool, basically all relavant devices have issues.
> 
> Qubes Video, Xen Interface, Xen PV Storage, Xen PV Network.

There has been an issue with QWT for as long as I can remember.
the Qubes Video driver has always had issues, and even though they have been 
reported, not all of them are easily fixed.

They fixed the multi-screen issue, in a way, not really multi-screen but it's 
one resolution to the issue, even though it produced another issue, it resolved 
one.

Storage and networking are just fine as far as I can tell, no matter the 
hardware. If it's an HVM then it has both, and they work, even the THVm works 
fine.

Maybe you can be more specific?


> Config in registry incomplete or broken (Code 19)
 
That's a Windows 10 error. QWT is not yet built for Win10.

> The repair option of the QWT uninstaller does not solve the issue as well.
> Any idea? Otherwise I think I'm stuck with QWT 3.2.1.2.

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


[qubes-users] Services still don't start even when they are there for starting in the list.

2016-10-27 Thread Drew White
Fedora 23 AppVM

I have several issues.

1... Every time the AppVM starts, you rewrite the hosts file to
remove anything that I've put in there to make
it "127.0.0.1   {AppVMName}" instead of
"127.0.0.1 {the domain I entered for httpd usage}"
In an AppVM that uses a parent template, I know it would
overwrite because of the non-persistent changes. But I've got
my hosts file and I have it the way I have it and want it.


2... I put a service to start in the services tab of the
settings in qubes-vm-settings python application, and the
services don't start.


Can either of these be fixed sometime? They have been an issue I have raised in 
Qubes 2.0 as well.

-- 
You received this message because you are subscribed to the Google Groups 
"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/648f788c-92b9-4880-b1c8-15fab4a947f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2016-10-27 Thread Robert Mittendorf

Am 10/27/2016 um 02:28 PM schrieb Manuel Amador (Rudd-O):

On 10/27/2016 04:34 AM, Andrew David Wong wrote:


Building on what Chris said, here are your general options, from best
to worst:

[...]
2. Make sure the data is encrypted before it ever touches the storage
medium (then wipe the encryption headers, if any, or keep the key secret).

This method is no longer 100% effective since the advent of flash,
hybrid drives, and hidden storage areas on rotating disks that store
unused sectors for when used sectors begin to fail.
so what is the matter? If the data on the drive is stored only encrypted 
(SSD, HDD or SSHD), those "hidden sectors" (for performance, wear 
leveling or reserve) and the caches do only contain encrypted data as 
well.


--
You received this message because you are subscribed to the Google Groups 
"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/ecae9e5f-3c30-5499-eeb7-7e17c394efd3%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - DELL PRECISION T7400

2016-10-27 Thread ludwig jaffe
Hi, I am running Qubes 3.2 on my Dell-Monster.
2 flaws:
1st: if I enable VT-d the machine crashes while or after booting the
xen-kernel
(I experienced it with the older kernel the one prior 4.4.14-11!) I also
run old BIOS A2 instead of A11 as I fear upgrade, as
it could brick the machine if this gets wrong.
2nd: the fans are sometimes *really* noisy,
like a starting concorde, but the processer is quite cool.
So one needs to run
ik2fan speed 1 1 to get it quite silent. One small fan still
is to loud. I need to find it. I guess it is the nvidia graphics
 fan.

Important: It should be possible to install additional software
to dom0 with more comfort!
Doing yumdownload (some package) and then copy it using the
command line tools as they are nice but ugly to use w/o cut and
paste to dom0 :-(

Maybe, you should include these packages to the dom0 repository
as there are also noisy dell laptops around...

What I did to get the fans more silent is to make sure to have lm_sensors
(was provided in dom0 repository, thanks, installed by default?)

Then I did the more unpleasent stuff:
yumdownlod of the packages in personal vm, of course...

on dom0:

qvm-run --pass-io personal 'cat
/home/user/dell/i8kutils-1.33.-8.fc22.x86_64.rpm' >
/home//i8kutils-1.33.-8.fc22.x86_64.rpm
qvm-run --pass-io personal 'cat /home/user/dell/tk-8.6.4-2.fc23.x86_64' >
/home//tk-8.6.4-2.fc23.x86_64
qvm-run --pass-io personal 'cat /home/user/dell/tk-8.6.4-2.fc23.x86_64.rpm'
> /home//tk-8.6.4-2.fc23.x86_64.rpm
qvm-run --pass-io personal 'cat
/home/user/dell/tcl-8.6.4-1.fc23.x86_64.rpm' >
/home//tcl-8.6.4-1.fc23.x86_64.rpm
qvm-run --pass-io personal 'cat
/home/user/dell/i8kutils-1.33.-8.fc22.x86_64.rpm' >
/home//i8kutils-1.33.-8.fc22.x86_64.rpm
qvm-run --pass-io personal 'cat
/home/user/dell/i8kutils-1.33-8.fc22.x86_64.rpm' >
/home//i8kutils-1.33-8.fc22.x86_64.rpm
qvm-run --pass-io personal 'cat
/home/user/dell/gkrellm-2.3.7-2.fc23.x86_64.rpm' >
/home//gkrellm-2.3.7-2.fc23.x86_64.rpm
qvm-run --pass-io personal 'cat
/home/user/dell/libntlm-1.4-4.fc23.x86_64.rpm' >
/home//libntlm-1.4-4.fc23.x86_64.rpm

sudo dnf install tk-8.6.4-2.fc23.x86_64.rpm
sudo dnf install tcl-8.6.4-1.fc23.x86_64.rpm
sudo dnf install libntlm-1.4-4.fc23.x86_64.rpm
sudo dnf install gkrellm-2.3.7-2.fc23.x86_64.rpm
sudo dnf install i8kutils-1.33-8.fc22.x86_64.rpm

all w/o cut and paste :-(

But now there is silence:

ik8fan
1 1

As it was loud it said:
ik8fan
3 3

to get it silent type
ik8fan 1 1

ik8fan 2 2 is a acceptable loud.


check the temperature with sensors. And also open the case
to feel the two cooler blocks, to check if the computer lies to you.


So thats all, for now, thanks for qubes, it is cool on such
an old machine as the machine is cheap and ddr2 ecc memory
is quite cheap.
This box can theoretically pimped upto 128GB.
2 CPUs with 4 cores each and 40GB are enough for the moment.


Have fun

Ludwig

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAP7Jdr%2BU03YL44vBSEkm3fsG3-p_iOUcsGNj8DM7G%3DeMyn-ZVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Dell_Inc_-Precision_WorkStation_T7400__-20161027-104558.yml
Description: application/yaml


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

2016-10-27 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi everyone,

We've just introduced a new mailing list: qubes-announce

This is a read-only list for those who wish to receive only very
important, infrequent messages. Only the core Qubes team can post to
this list, and only Qubes Security Bulletins (QSBs) and new Qubes OS
releases will be announced here.

Instructions for subscribing to the list are available here:

https://www.qubes-os.org/mailing-lists/#qubes-announce

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

iQIcBAEBCgAGBQJYEpQ5AAoJENtN07w5UDAw8J8P/i2mx158pBxuIXyWUAsxX5uu
9jTZoWdPFyV9O8YPNX6EYFpW8J0fX9fWpG1R+6/274pibtJ9u+/vjbnEFzCmIxE1
0jjnEH2Ayu5yCMleje2on5GN46kGJkeJknqzjM3eirCjHvAM/Q7iBoJl8a7oPUGw
asjWGYSxFOhyDJPaa9ZB8e6yn5mE77HDZCn0gTJ+y5XNMOkSHMD/VIycHDe70jJ0
KHUdwafpGpoo/dUGJPRT+q+FWi99EMq205mHHF7T8NKO2RgDuLzDA7CYr2WPynsS
sw7SNf4UgOk8W9s2XuaxwwEzgUZCClMbT3tfT93aS0fXjRe+5Qn1lv+/C7Q06MH/
EZSxqllaQ0XhTU1B/CDYZ5Xfgty90iKSbt2sVgFQyaOMPuEjgFtLKUq/pCnd8wtQ
k3AhludRypbocQWTm1KwrvVGP5NSevBJuCyYHS1vf3TYQ/gOmLCbAkXU26VExMoR
o//Z+uiwt2puPFmbkJrRQhtnL/BPApldLF9Q4n/qR0VOZ0jMXh47sPub+JVxEySd
J0azketQzJWVKVUmfFAqcxkcywaohJx7r/1XiSLon1HnZ6jIOUbKS9DGEGR8BWub
DjPSpRz0M/GZ5h4t761MhjoZ2N/jgVKhs9eM/fvO9oyKZQoTesYYgxlpDns4njf4
wmOWv1iaq5Al0IFYNULD
=9LW+
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/210aa32a-59d8-1dd5-d32a-32439e3ad48c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


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

2016-10-27 Thread Scott Bourne
On Wed, Oct 26, 2016 at 9:22 PM, Andrew David Wong  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> 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.

>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCgAGBQJYEYD6AAoJENtN07w5UDAw8DgP/3oekpV4tGRyZdCSFZ/2eJ3W
> z0LY0BNEmwN7aJceqma3ZIlGhggEvDnhm9y2r6VXDSIa4QPDuhE5fYDbFSqpdTXw
> fnYda6BBGrtsxPn2XNn/8c9ga9WgMgFHtZjzfr3GCvjs7C0VNJc8MTXZklLlfEVe
> Ik0VsbBmA1III2x86QdWDI7fvaMVW5ufKt9MeLevGVOZVVHddZWSa5dMS5bJtzxt
> 4fTvchkSsj+WIn9xX5tOWfqYe/dGEhlXRSHWV4InYrVwGb8Qr4XUT3BLsip7kl4O
> ot0SkWZCiHGV6EH4OXfIQFrVhRfoZfpC6MTDOzJKRcRrJojpdjFFolYgqeiI85dq
> 5jLDRXFZVZM2/HXi8BaDrvbWsxFOypodXyHuDyUfRfX+pN47zhFCzQLMOz7TgxZk
> bL0CyElb+80HPUssllM8QYhrxVb5fhFPpYpDOOousRST4X6SsmHKDsGRPdMEM7Zu
> j8oSMn9gdzMPS2q88/gGtE6VnGjiCdDkoQ7NKDa07mguzWRLI48ydhVMyKI5JSOO
> khbb98F9cnN2hxANgHv5xjDjG9QPE/ZoazD2QpKGI2vchq9qsWXL1R66Y2N1gxqn
> 0uGdMss4jQUt18KKT/55H/hAQDdXoMiH3i467akZEx8cqWCj4+XwjUxynqdxpsCO
> P2Lz7v9nJT3/jzLO1miH
> =HXRu
> -END PGP SIGNATURE-
>
>

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


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

2016-10-27 Thread 7v5w7go9ub0o



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)? 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.)


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


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f5303c85-6554-68ce-2901-2b8b69ffcd1b%40gmail.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: Request for test: Re: [qubes-users] Fedora 24?

2016-10-27 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.

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?

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYEgHCAAoJENuP0xzK19csXQYH/2DWHoZ+Td3+a4Rd2Y6L8Aj0
ECAK3TCObhmtCTgCi16rHtGTGY0zTZiE1a0yYFpAM1XwVan9Baalbu3gYGwUOLcx
imQ+gYsXccLh1JdxrH/NeovzuoRvH1jFW0upUpawuPAsmebVpRbcQ2y9wNwe9mWF
pajUFwpNZMEarfIXbsd6dVnPbJTAHUhPzC1Iq01zxtpcDoAWSzAzSwmWUSN8rfCt
McMgVK8cZcS4rNvsVfxfEqR6+Pxz9qiCHjZZGJweRYQ/DoksFqr1cwYfoNhh0NnB
TuYnlmW9DUL1FOqHW4I9wAE6B93cTvkBmCMH24YnAXkq9JN/jeiJxSI+RAmYra0=
=xINa
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20161027133146.GR1136%40mail-itl.
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: [qubes-users] Re: Introducing the qubes-announce read-only mailing list

2016-10-27 Thread Achim Patzner
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

-- 
You received this message because you are subscribed to the Google Groups 
"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/cf2f3c00-5ae6-2f86-389c-1e7e11bda8dd%40noses.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Services still don't start even when they are there for starting in the list.

2016-10-27 Thread Drew White
On Friday, 28 October 2016 11:33:28 UTC+11, Marek Marczykowski-Górecki  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Thu, Oct 27, 2016 at 05:15:45PM -0700, Drew White wrote:
> > Fedora 23 AppVM
> > 
> > I have several issues.
> > 
> > 1... Every time the AppVM starts, you rewrite the hosts file to
> > remove anything that I've put in there to make
> > it "127.0.0.1   {AppVMName}" instead of
> > "127.0.0.1 {the domain I entered for httpd usage}"
> > In an AppVM that uses a parent template, I know it would
> > overwrite because of the non-persistent changes. But I've got
> > my hosts file and I have it the way I have it and want it.
> 
> Only the last entry is replaced, so anything you put before actual VM
> name should stay untouched. But if you still want to suppress even that,
> create /etc/qubes/protected-files.d/hosts with a single line:
> /etc/hosts

But that doesn't work.
I had 10 entries. ALL of them were changed.

I've added that line and will check it after I next re-start that guest. Thanks.
Do I have to do the same thing for other files?
Does that directory only protect for startup not letting Qubes change the file? 
Or does it protect as in no-one is allowed to change it?

> > 2... I put a service to start in the services tab of the
> > settings in qubes-vm-settings python application, and the
> > services don't start.
> 
> You probably tried to start service which doesn't support being
> controlled by this mechanism. Here is list of supported services:
> https://www.qubes-os.org/doc/dom0-tools/qvm-service/
> And here is how to add such support for anything else:
> https://www.qubes-os.org/doc/qubes-service/
 
Yup, you are right. So it's not a service manager, but only a qubes-service 
manager.
I misunderstood that because of the naming.

> > Can either of these be fixed sometime? They have been an issue I have 
> > raised in Qubes 2.0 as well.
> 
> I don't want to waste my time on searching, but I believe you've got
> exactly the same answer before. It's not something to be fixed, it's
> something you don't know how to use.
 
I completely understand.
And no, I didn't get exactly the same answer before. I can gaurantee that 100%.
If I was provided that information the last time, I would not have been asking 
this time, simple.

I know how to use services, but the fact that it only supports a limited number 
of services, not all services is kind-of not good. The services all start the 
same way, so why is there a limitation?

crond, cups, ntpd, network-manager... They all use the same methodology as 
httpd, maridb, and others that I try to turn on on boot. Only difference in the 
command is the fact it's httpd or mariadb instead of cups or crond.

So, I don't know what's going on or why it's done the way it is..

There isn't any limitation in qvm-manager to stop it from working. so why isn't 
it working? Please explain? (don't take too long because I don't want to waste 
too much of your time explaining what isn't explained anywhere)

Hope you can help Marek, since you are one of the few people that can explain 
things technically enough that I can understand it. (so far)

Catch ya later.


-- 
You received this message because you are subscribed to the Google Groups 
"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/9e9f85a6-552e-45d2-bea3-d59be6d5b622%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.