PeerGuardian in QubesOS

[Iestyn Best]

Hi All,

I was wondering if anyone has thought of using a service like PeerGuardian to stop network traffic to known bad addresses?

I am trying to work out, in my head, if it should be integrated into the default firewallvm or created as a separate firewall/proxy vm before the default firewallvm. I am leaning towards the latter and believe it should be created separately.

Interested to hear other peoples thoughts on this.

Regards,

Iestyn Best

[Iestyn Best]

Hi All,

I have started doing some work on this and would like to provide an update along with asking for some assistance to make sure I am tackling things in the right way to support Qubes.

I started by cloning a copy of the Debian template as there is no known source of an RPM for PeerGuardian, as well as the fact that I am adding a 3rd part repo.

I then added the repo and installed the 3 required core components (pgld, pglcmd and pglgui). When prompted if I wanted the service to start automatically I said no as I want it only starting in the AppVM and not the template (would this be correct?).

After doing a little fiddling, I found that it stores most of its dynamic config files in /etc/pgl/ so I copied the files to ~/.pgl/ and changed it to a symlink so that user can modify them (Would this be correct?)

I also had to change the pglgui config use sudo instead of gksudo for its super user commands.

I now have 2 quest about autostarting both the service and gui applet on VM start. Can you advise what is the best way to do these?

Any assistance and feedback would be greatly appreciated.

Regards,

Iestyn Best

[Iestyn Best]

I needed to create more symlinks for the following:

/var/log/pgl/

/var/spool/pgl/

This has allowed it to create logs and store the dynamic list of IP addresses it downloads for blocking.

I still have not got it to autostart the service on VM boot.

[Iestyn Best]

The PeerGuardian service keeps crashing.

I think it is related to multiple services trying to play with the iptables.

Attached is a log file from PeerGuardian, I think the bit that is import is:

....FORWARD from 10.137.2.24 to Internal error: Usage set_NETWORK IP SUBNETMASK, arguments were: "10.137.5.1 255.255.255.255 255.255.255.255".Bad argument `255.255.255.255'

Try `iptables -h' or 'iptables --help' for more information.

failed!

2015-04-14 04:33:20 UTC Begin: pglcmd restart

Stopping pglcmd.wd.

Deleting iptables ...

..Executing iptables remove script /var/lib/pgl/.pglcmd.iptables.remove.sh.

..Removing iptables remove script /var/lib/pgl/.pglcmd.iptables.remove.sh.

Iptables deleted.

Stopping pgld.

Inserting iptables ...

..Setting up iptables for INPUT:

....Creating chain and inserting NFQUEUE rule.

....Whitelisting IP ranges.

....Inserting block rule.

..Setting up iptables for OUTPUT:

....Creating chain and inserting NFQUEUE rule.

....Whitelisting IP ranges.

....Inserting block rule.

..Setting up iptables for FORWARD:

....Creating chain and inserting NFQUEUE rule.

....Whitelisting IPs.

....Inserting block rule.

..Allowing loopback traffic: INPUT OUTPUT.

..Allowing OUTPUT traffic to DNS server 10.137.2.1.

..Allowing OUTPUT traffic to DNS server 10.137.2.254.

..Allowing FORWARD traffic to DNS server 10.137.2.1.

..Allowing FORWARD traffic to DNS server 10.137.2.254.

..Allowing LAN traffic ...

....INPUT from 10.137.2.24.

....OUTPUT to 10.137.2.24.

....FORWARD from 10.137.2.24 to 10.137.2.24.

....FORWARD from 10.137.2.24 to Internal error: Usage set_NETWORK IP SUBNETMASK, arguments were: "10.137.5.1 255.255.255.255 255.255.255.255".Bad argument `255.255.255.255'

Try `iptables -h' or 'iptables --help' for more information.

failed!

[cprise]

> --

Not sure if you need to clone the template. Though I haven't used
peerguardian, my approach might be to create a standalone VM which is
essentially a clone and it simplifies configuration (there is no
template/vm divide).

Otherwise, with a template-based VM I would use /rw/config/rc.local to
set the symlinks at boot time, probably pointing to a folder under /rw.

As for your runtime problems, I'd have expected them because Qubes has
its own firewall management system (which is most active in proxyvms).
Probably the next thing I'd do is try pg in a standalone appvm;
otherwise I'd look for an option to use a hosts file instead of iptables.

[cprise]

On 04/14/15 01:11, Iestyn Best wrote:
> The PeerGuardian service keeps crashing.
>
> I think it is related to multiple services trying to play with the iptables.
>
> Attached is a log file from PeerGuardian, I think the bit that is import is:
> |
> ....FORWARD from 10.137.2.24 to Internal error: Usage set_NETWORK IP
> SUBNETMASK, arguments were: "10.137.5.1 255.255.255.255
> 255.255.255.255".Bad argument `255.255.255.255'
> Try `iptables -h' or 'iptables --help' for more information.
> failed!

Where is that subnet mask coming from? Can you specify one that is
255.255.255.0 ?

[J.M. Porup]

Has anyone gotten mutt working with split gpg using the debian template?

current roadblock: qubes-gpg-client does not appear to be available in
the debian template. I've enable the qubes testing and unstable repos,
to no avail.

any ideas?

thanks
Jens

[cprise]

On 04/14/15 01:11, Iestyn Best wrote:

> --

Another thought is, if you're using a proxyvm, see if pg has a mode that
just spits out a file containing iptables commands. Then copy/move that
output to /rw/config/qubes-firewall-user-script .

[J.M. Porup]

J.M. Porup:

OK, so, I'm doing some more work on this. I think it should be possible
get mutt working with split gpg, (and with significant security benefits
over using thunderbird/enigmail,) although it's quite fiddly to set up.

Right now I'm working in FC20 templates, could anyone tell me why so
many qubes packages aren't available for debian?

For instance, here's what `aptitude search qubes` gives me in the
debian-8-x64 template:

i qubes-core-agent - Qubes core agent

i qubes-gui-agent - Makes X11 windows available to
qubes dom0
i qubes-gui-common - Qubes GUI common files

i A qubes-utils - Qubes Linux utilities


[note: qubes-gui-common only became available when I enabled the testing
repo in /etc/apt/sources.list.d/qubes-r2.list]


but this is what the FC20 template gives me for `yum search qubes`:

qubes-core-vm.x86_64 : The Qubes core files for VM
qubes-core-vm-debuginfo.x86_64 : Debug information for package qubes-core-vm
qubes-core-vm-doc.noarch : The Qubes docs for VM tools
qubes-core-vm-systemd.x86_64 : Qubes unit files for SystemD init style
qubes-core-vm-sysvinit.x86_64 : Qubes unit files for SysV init style or
upstart
qubes-gpg-split.x86_64 : The Qubes service for secure gpg separation
qubes-gui-common-devel.x86_64 : Common files for Qubes GUI - protocol
headers
qubes-gui-vm.x86_64 : The Qubes GUI Agent for AppVMs
qubes-gui-vm-debuginfo.x86_64 : Debug information for package qubes-gui-vm
qubes-img-converter.x86_64 : The Qubes service for converting untrusted
images
: into trusted ones
qubes-libvchan-xen.x86_64 : Qubes vchan libraries
qubes-libvchan-xen-debuginfo.x86_64 : Debug information for package
: qubes-libvchan-xen
qubes-libvchan-xen-devel.x86_64 : Include files for qubes core libraries
qubes-pdf-converter.x86_64 : The Qubes service for converting untrusted PDF
: files into trusted ones
qubes-tor.x86_64 : The Qubes package for running a TorVM
qubes-utils.x86_64 : Common Linux files for Qubes Dom0 and VM
qubes-utils-debuginfo.x86_64 : Debug information for package qubes-utils
qubes-utils-devel.x86_64 : Development headers for qubes-utils
qubes-utils-libs.x86_64 : Qubes utils libraries
thunderbird-qubes.x86_64 : The Qubes extension for Thunderbird
xen-qubes-vm-debuginfo.x86_64 : Debug information for package xen-qubes-vm
qubes-core-vm-kernel-placeholder.x86_64 : Placeholder for kernel package
as it
: is managed by Dom0
qubes-tor-repo.x86_64 : Torproject RPM repository
xen-qubes-vm.x86_64 : Xen is a virtual machine monitor
xen-qubes-vm-devel.x86_64 : Development libraries for Xen tools
xen-qubes-vm-libs.x86_64 : Libraries for Xen tools
xen-qubes-vm-licenses.x86_64 : License files from Xen source


Note that qubes-gpg-split appears to be available only for fedora. (?!)

Or have I missed something here? Any pointers appreciated.

thanks
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm just preparing updates for Debian :)

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

iQEcBAEBAgAGBQJVL7EvAAoJENuP0xzK19csh/wIAIZQZxiLEaQjdGu856SE449V
/A0638s/L7Zs+bS5mbbmFVPHD0u12vsENLm6JL2HdzA8+tqjvSMi472zh+wSPGmg
0FY5SPVHOHrKK+Wmjr5yOvnzBgy37b32SDkJa81f6hRRx+ciCT7jneitxsyRXcMx
8zA9K9uqQAwn57Jy7TwH1x/IR9lfTkWR0ltBYdK+qrRHJwxMBZMCbMkH/M+wYc/V
j2OB98jHe+5n5/tkV8DEvax9F5gm88bXn69h04QgLLxds2rwgAEuw4K84axFzXHX
dy9X2Wf6BwWhJJc63ztwx8Jkl+st3uUGtku6K1i5BcO3Vjih7ls4/CeL7Z5b72k=
=rqaR
-----END PGP SIGNATURE-----

[J.M. Porup]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

>> Note that qubes-gpg-split appears to be available only for
>> fedora. (?!)
>
>> Or have I missed something here? Any pointers appreciated.
>
> I'm just preparing updates for Debian :)

Great! Thanks, Marek.

In the meantime, a quick question. One stumbling block for mutt +
split gpg is the large number of gpg command line args mutt wants to
pass for optimum usage, and which qubes-gpg-client rejects as invalid
(like --passphrase-fd). Poking around in the split gpg source on
github, I found this:

https://github.com/QubesOS/qubes-app-linux-split-gpg/blob/master/src/gpg
- -common.h

has this whitelist for gpg command line args been implemented yet? If
not, is there an ETA?

thanks
Jens
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVL7e/AAoJEGrDVsHXOmiEd60P/1MKoGCwI4bfW8f+ghpGj/Eo
QFekVCsVY/MLhJmwzGhP+2I/VwNNWNposdSuZ0/ZJTaYrCGXm42Q2JKgXbYMLRqV
yyoB+a1Nfjd/D4Yuw66QDdKaJQvPoQtaTsbdfH10XRWjsHVzr38PEg1+HtclyJWO
bd9rU+S3ASG9GLCTVS7SrysjMPeXY0vRkF5B718AYoX0vABw+wQZV6gVEQuZst9W
JZPsSSUj1B5VUzuDEeRIXzRmzbLxBIjmucWVtnCIo3IwL51B54buvg+a2spo/bM4
BgaiS/flfc1w7sLIEYic6nppV0Hwahcr77sfF/cRximd/Ignf6x3GfGNdVp4TxQe
VJ0rDemL2ZOynBRRpCahaGnymeOYi9mIhVSIC4/YrzTd18q1amloCDmoxevJmydQ
Tb9Yb80PzT2KgS/ZxXPp1ZjoZTDiYNL7dF6/08uGVgZ6gF0t8nVJGdIwVsMtqazW
+Yq/z/V4zHGTaTZ3NVcVezF59MGoY6+IGQ63hdnNQzwznjuhAKiisZUokk8MLrI6
6wwmPCIQiPkp91k9FzPQlszA2x6bO8gLOCCgPmz65UUklSe4urAHhcQ/jAlAcpMq
4ezT/5sZhneM+xDKkCPJie41fBHJQGbrBNxLcUEyYDJJ4ubDIA54DGlEsqoWrLLX
KrA1SDoxHn8iqN9yv5Ao
=cQwI
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 16, 2015 at 01:23:13PM +0000, J.M. Porup wrote:
> Marek Marczykowski-Górecki:
> >> Note that qubes-gpg-split appears to be available only for
> >> fedora. (?!)
> >
> >> Or have I missed something here? Any pointers appreciated.
> >
> > I'm just preparing updates for Debian :)
>
> Great! Thanks, Marek.
>
> In the meantime, a quick question. One stumbling block for mutt +
> split gpg is the large number of gpg command line args mutt wants to
> pass for optimum usage, and which qubes-gpg-client rejects as invalid
> (like --passphrase-fd). Poking around in the split gpg source on
> github, I found this:
>
> https://github.com/QubesOS/qubes-app-linux-split-gpg/blob/master/src/gpg

> -common.h
>
> has this whitelist for gpg command line args been implemented yet? If
> not, is there an ETA?

Take a look here:
https://www.qubes-os.org/doc/Mutt/

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

iQEcBAEBAgAGBQJVL7sUAAoJENuP0xzK19cs6GkIAIbjCRXxrSZp4xM0y6Nov+3T
SE+hYZlRjcQdv91dWSx98ksnhoyK4dFt3ouiV858VH4Dw+awqqMKk0yH3J9nUHXd
GSjKn6vKj8JiRf3bXYSnxibnSlhpUd12AgYJV6Ie2lC62MKI7TjomwA5qXpymcYd
/WWpsSimAyIB7RXx0YJa1/q70XhtIRCNPRoa+VDskxCF/ATNGZWh9gglSmWuDQIB
z45Lix6ZvhlSoxKpPce5bvICq1SCSXz3rOmcgrgHy2dDjhuXXvq46y/AZWXsUNm7
iIKtHnUwSLdzr8ujkhyHoRcwgapK5Q68MGH6ITyeUQIgCqJbNKKJNqGnAyn0WKw=
=QzEH
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 16, 2015 at 03:37:24PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 16, 2015 at 01:23:13PM +0000, J.M. Porup wrote:
> > Marek Marczykowski-Górecki:
> > >> Note that qubes-gpg-split appears to be available only for
> > >> fedora. (?!)
> > >
> > >> Or have I missed something here? Any pointers appreciated.
> > >
> > > I'm just preparing updates for Debian :)
> >
> > Great! Thanks, Marek.
> >
> > In the meantime, a quick question. One stumbling block for mutt +
> > split gpg is the large number of gpg command line args mutt wants to
> > pass for optimum usage, and which qubes-gpg-client rejects as invalid
> > (like --passphrase-fd). Poking around in the split gpg source on
> > github, I found this:
> >
> > https://github.com/QubesOS/qubes-app-linux-split-gpg/blob/master/src/gpg
> > -common.h
> >
> > has this whitelist for gpg command line args been implemented yet? If
> > not, is there an ETA?
>
> Take a look here:
> https://www.qubes-os.org/doc/Mutt/

Packages uploaded to testing repository. Let me know if everything is
working for you :)

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

iQEcBAEBAgAGBQJVL84iAAoJENuP0xzK19csF9MIAIkFLnt4qRkxTph/NiNCjfTA
O4AX9HQd6Y4KdAYtdzxEvDAR3ZnoIeUlHCyR+XYIlDJfOdPSIGqEp15XrrLrvzhl
iLSmPNprgO6Qacq8fl+GIJdmmcKDCy/7eZbVqjBKXzw3vVExCD/nXleO3WghMNVk
0Ek9UnL+/XfT4TvgCupNXst1ht0ZEK1LR2qhrAcIVGzM6EEdJyyqxEUZhzIUMWcI
Fi9bUPOzqQL7hBwuIx8fE+0mYEun3HVhTd5hwas+BnxV2UddHHuEHviKDTpEp2lP
0pLv/kXWjOveQhvSVon3MAm6A9WjDG1a48oawhzG4ItvwPrhqlmEzCtv+nQdkTs=
=xECq
-----END PGP SIGNATURE-----

[J.M. Porup]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Thu, Apr 16, 2015 at 03:37:24PM +0200, Marek
> Marczykowski-Górecki wrote:
>> On Thu, Apr 16, 2015 at 01:23:13PM +0000, J.M. Porup wrote:
>>> Marek Marczykowski-Górecki:
>>>>> Note that qubes-gpg-split appears to be available only for
>>>>> fedora. (?!)
>>>>
>>>>> Or have I missed something here? Any pointers appreciated.
>>>>
>>>> I'm just preparing updates for Debian :)
>>>
>>> Great! Thanks, Marek.
>>>
>>> In the meantime, a quick question. One stumbling block for
>>> mutt + split gpg is the large number of gpg command line args
>>> mutt wants to pass for optimum usage, and which
>>> qubes-gpg-client rejects as invalid (like --passphrase-fd).
>>> Poking around in the split gpg source on github, I found this:
>>>
>>> https://github.com/QubesOS/qubes-app-linux-split-gpg/blob/master/src
/gpg
>>>
>>>
>>>

- -common.h

>>>
>>> has this whitelist for gpg command line args been implemented
>>> yet? If not, is there an ETA?
>
>> Take a look here: https://www.qubes-os.org/doc/Mutt/
>
> Packages uploaded to testing repository. Let me know if everything
> is working for you :)

Thanks, Marek. mutt is talking to my gpgvm, but the conversation isn't
going too well. neither signing nor encryption works in FC20 based on
the wiki doc, I'm fiddling with config files to see what I need to do
to make it work. Will also try with the new debian packages and report
back.

cheers!
Jens


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVL9EBAAoJEGrDVsHXOmiEG8UQAKO3Z/Yd3AMSF+7bxY1V+uHz
LMg0PWtP4KyZlfupYqLa2fWN1i/cgF99wNy85gPaUEzUa+DlppttqyMh20XVGgm/
Mni/bCWqN1McgUSiM9clYLN+nBxwYDQOP00gIhH0G9nrRdkMI2+vZxV5t3Fefk+q
sljyrWW2zQs7LLYXc6CddW8rDYl/Fsi7Ao0M5j0ABqtoVZHFhrN1Yvj4j9GCwy3X
kG6vhSKM66596QUuKoO1OEMhkoUoNBGOlmgrPd0IWMml6/dLvwK7Kn7fAPAKip5E
/gKgog+LExd16Nd4rd3uNoBK486RmjxsV9sPcNfi0/rd4L8mAJGtNiAEjL6pQuJT
/ULQ4U5maLR8hJw5mDJTS6KdrZ26PgHfsFHXLp8kaphiB5Y7kX4s7k0KUBoTRv/9
rfv4mTqhs+JVTACcpIo+Z3ecNHBvxq881XEVTbSxB4IgU/mHD4V/hJmAf93mbRpu
RqP/dW2h5JUv63OswvBo8ZT5q533/IZPlbzN1GvRzgnyZAyYFJD3EH6HV4j9Xw28
nA1fB/rjP12Qr4zxc6LVYT8VOTxvEx0TEP29k6kbX5cTaRTU4RAgXTBNLawHhvyh
ZzM0+JlYO5R1mhVYjB+2jdCoZ7LXzCF6cJkWLzNYx5VlZGrHM2pwtDPRMfCq0EUM
vkANzqgd2hfKjWHIVEN3
=ZGa3
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 16, 2015 at 03:11:00PM +0000, J.M. Porup wrote:
> Marek Marczykowski-Górecki:
> > On Thu, Apr 16, 2015 at 03:37:24PM +0200, Marek
> > Marczykowski-Górecki wrote:
> >> On Thu, Apr 16, 2015 at 01:23:13PM +0000, J.M. Porup wrote:
> >>> Marek Marczykowski-Górecki:
> >>>>> Note that qubes-gpg-split appears to be available only for
> >>>>> fedora. (?!)
> >>>>
> >>>>> Or have I missed something here? Any pointers appreciated.
> >>>>
> >>>> I'm just preparing updates for Debian :)
> >>>
> >>> Great! Thanks, Marek.
> >>>
> >>> In the meantime, a quick question. One stumbling block for
> >>> mutt + split gpg is the large number of gpg command line args
> >>> mutt wants to pass for optimum usage, and which
> >>> qubes-gpg-client rejects as invalid (like --passphrase-fd).
> >>> Poking around in the split gpg source on github, I found this:
> >>>
> >>> https://github.com/QubesOS/qubes-app-linux-split-gpg/blob/master/src
> /gpg
> >>>
> >>>
> >>>

> -common.h
> >>>
> >>> has this whitelist for gpg command line args been implemented
> >>> yet? If not, is there an ETA?
> >
> >> Take a look here: https://www.qubes-os.org/doc/Mutt/
> >
> > Packages uploaded to testing repository. Let me know if everything
> > is working for you :)
>
> Thanks, Marek. mutt is talking to my gpgvm, but the conversation isn't
> going too well. neither signing nor encryption works in FC20 based on
> the wiki doc, I'm fiddling with config files to see what I need to do
> to make it work. Will also try with the new debian packages and report
> back.

What is the exact error? Maybe you need to save your keys without a
password in gpgvm?

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

iQEcBAEBAgAGBQJVMCiUAAoJENuP0xzK19csbGsH/3PbPBlr7ru6m7sgei+gDnRU
Ldx1v/+6FY5YCpp6Iy9F1cphWoscS8X+XtkDiNJOaN7DWkdHcqODaZJ9uwsxCUZc
l66SnPqZA2QL4aQILHParRh6lDT6f+UOJFmcbYXfNiSYY5GAni0V/Nq8HpE5Uy5M
lLx3tqBPSjs7V8kRkAWBq3XPtsJlrJa7J9VwTVoTvshg7tp0a4O2Oh1xssLzRnz+
+E/4oSA5dqvV06fYbaovJO5jjlxEdnGQaeWnTbZTEQn8B103v2nlDZb/BtZpa1NN
QVaDMJMfywrxM4ig2qOiUhf+nZwFnLpHRhwrHME8Ncxn5F8LM+ebJi2QRcDMHWk=
=LacV
-----END PGP SIGNATURE-----

[J.M. Porup]

mutt can execute qubes-gpg-client-wrapper and talk to the gpgvm, but
can't seem to find my key ID, even though it's in my config. I've tried
manually entering it at the prompt, but no results. Any ideas what I
should look for?

thanks
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Try to run commands configured in mutt manually as see what the output
is.

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

iQEcBAEBAgAGBQJVMDJeAAoJENuP0xzK19csntQH/Rg55T0PDdtUqNgbb70tREh4
lih2dU3E1QWGjKDTCQqoP+t/+31iQlRTTlA5+icNYdeuVbWx6vQhRbJRghKikKbb
rMo+ijJWLx+GUHKudRjpsEZcZBaSAZak+RmKF67JpD99Xha2vAjPHsaTZR9OPfrm
+LvkTn7nioNZTyKZWHaoEjDlvLr9Q433ZUj9pTX78FFZjpGPNS7tQTOYjaYkTYHn
36U5M8q7uVNIsl6FczggMLbTlpRcbzD1L2uYebpa5Glv1LECYbiK3Tp0zLZDCG7y
CHjQIt6huQHgkBjxDkF/UK3Vs7A4nACGFpd9iGUKWt6+wbDMQe4hy9TmHycHQqc=
=jcNQ
-----END PGP SIGNATURE-----

[J.M. Porup]

Marek Marczykowski-Górecki:

>>>>>> Take a look here: https://www.qubes-os.org/doc/Mutt/
>>>>>
>>>>> Packages uploaded to testing repository. Let me know if everything
>>>>> is working for you :)
>>>
>>>> Thanks, Marek. mutt is talking to my gpgvm, but the conversation isn't
>>>> going too well. neither signing nor encryption works in FC20 based on
>>>> the wiki doc, I'm fiddling with config files to see what I need to do
>>>> to make it work. Will also try with the new debian packages and report
>>>> back.
>>>
>>> What is the exact error? Maybe you need to save your keys without a
>>> password in gpgvm?
>
>> mutt can execute qubes-gpg-client-wrapper and talk to the gpgvm, but
>> can't seem to find my key ID, even though it's in my config. I've tried
>> manually entering it at the prompt, but no results. Any ideas what I
>> should look for?
>
> Try to run commands configured in mutt manually as see what the output
> is.

Yup, tried that, not as simple as it sounds.

First, I run something simple, like

`qubes-gpg-client-wrapper --encrypt foo.txt`

This returns:

gpg: cannot open tty `/dev/tty': No such device or address

I search the qubes mailing lists, find Micah Lee's hack:

https://groups.google.com/d/msg/qubes-users/xnAByaL_bjI/Ia14HmdTlCwJ

So for testing purposes I modify /usr/bin/qubes-gpg-client-wrapper to
include:

`exec /bin/qubes-gpg-client --no-tty --use-agent "$@" `

which pops up a split gpg permissions dialog box, then returns:

gpg: Sorry, no terminal at all requested - can't get input

I try with just --no-tty and just --use-agent, but still no luck.

OK, so let's try something else from my .muttrc. I remove the --no-tty
and --use-agent, then try:

`pgpewrap qubes-gpg-client-wrapper --encrypt foo.txt`

which tells me "pgpewrap: command not found." duckduckgo-fu reveals that
debian puts pgpewrap someplace weird, in this case
/usr/lib/mutt/pgpewrap. So I put absolute paths into my .muttrc, and invoke:

`/usr/lib/mutt/pgpewrap qubes-gpg-client-wrapper --encrypt foo.txt`

this brings me back to where I started. doesn't work with tty, doesn't
work with --no-tty. Hmmm. OK, so let's try something else and come back
to this later.

Let's try to sign something:

`qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode
foo.txt`

which returns:

gpg: can't query passphrase in batch mode
gpg: no default secret key: bad passphrase
gpg: signing failed: bad passphrase

First things first, let's switch to --no-batch and see if that makes a
difference:

`qubes-gpg-client-wrapper --no-batch --armor --detach-sign
--textmode foo.txt`

But:

qubes-gpg-client: unrecognized option '--no-batch'

OK...so we'll just ditch the --batch option and see if that makes a
difference:

gpg: cannot open tty `/dev/tty': No such device or address

Grrr. Back to that again. Let's look at the other problem, anyway. gpg
doesn't know what key ID to sign with. Fair enough. gpg man pages
suggest using the --default-key arg:

`qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode
--default-key 0xFFFFFFFF foo.txt`

But this returns:

qubes-gpg-client: unrecognized option '--default-key'

What about --local-user? man page suggests that too:

`qubes-gpg-client-wrapper --armor --detach-sign --textmode
--local-user 0xFFFFFFFF foo.txt`

This returns:

gpg: cannot open tty `/dev/tty': No such device or address

And just because, let's try that with --batch mode again:

gpg: can't query passphrase in batch mode
gpg: skipped "0xFFFFFFFF": bad passphrase
gpg: signing failed: bad passphrase

Hmmm. So that's a slight improvement. Can we at least force gpg to
prompt for a passphrase?

`qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode
--passphrase "this is a test passphrase" --local-user 0xFFFFFFFF foo.txt`

which returns:

qubes-gpg-client: unrecognized option '--passphrase'

Grrr. OK. So I'm going to give up on encrypting and signing for now.
What's the most basic thing we could possibly do? How can we isolate the
problem? What about something super simple, like:

`qubes-gpg-client-wrapper --no-verbose --batch --quiet --with-colons
--list-keys`

Huzzah! That returns all the pubkeys in my keyring as promised. So now
what? How do I work backward to find the source of the encrypting and
signing problems?

Note that I'm using qubes-gpg-split v. 2.0.11 on a debian muttvm talking
to a fedora gpgvm running qubes-gpg-split v. 2.0.10. Having just written
that sentence, it occurs to me I should switch my gpgvm to debian 2.0.11
and repeat the above tests. Here are the results:

$ /usr/lib/mutt/pgpewrap qubes-gpg-client-wrapper --encrypt foo.txt
EOF

$ qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode foo.txt
EOF

$ qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode
--local-user 0xFFFFFFFF foo.txt
EOF

$ qubes-gpg-client-wrapper --no-verbose --batch --quiet --with-colons
--list-keys
EOF


So. That's where I'm stuck at. Ideas?

thanks
Jens

[Iestyn Best]

I think this thread has been hijacked.

is there any way to get the content of this thread moved out so it is easier to find in the future?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, this is something worth mentioning in mutt documentation...

> this brings me back to where I started. doesn't work with tty, doesn't
> work with --no-tty. Hmmm. OK, so let's try something else and come back
> to this later.
>
> Let's try to sign something:
>
> `qubes-gpg-client-wrapper --batch --armor --detach-sign --textmode
> foo.txt`
>
> which returns:
>
> gpg: can't query passphrase in batch mode
> gpg: no default secret key: bad passphrase
> gpg: signing failed: bad passphrase

As I've wrote before - you need to save keys *without* a password in
your GpgVM.

Log messages are probably in system log in your gpgvm, most likely
/var/log/syslog. I guess it can't find gpg - check the path in
/etc/qubes-rpc/qubes.Gpg.

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

iQEcBAEBAgAGBQJVMFKNAAoJENuP0xzK19cs35sH/1sCoZATzci3fGfqh+OCG+To
tlgyJNq8eJ+9tjGhg2tnXiTzCCha33iSIl55PlE/6A2NB+KJmPDmlyC2Qv1iB6vx
vDF3HBPti4FnEwepSHW43vHdVnfgcJKodfE0cgCLFwKdYuwQ04VsGIfMW5YOheMN
gIu6iCDcxgPrZln70h6vS2PIoD/DRwJ09JuphjWQgZzzdYaR8XFMtdzNjvj0UDFc
AHPamFSTFaoEyelpwSW6ay1obOZVH6yIexsfjAcnYkb71lUJYtTXeZUBxEtnNQTz
MPrgmuMiBFaqJkL43asL7sVOIZo2f6i4NmptopA8CETE+a6/y8HRskdfXTNzQEg=
=0ReD
-----END PGP SIGNATURE-----

[J.M. Porup]

Marek Marczykowski-Górecki:

> As I've wrote before - you need to save keys *without* a password in
> your GpgVM.

I should use a zero-length passphrase for my keys? I confess that sounds
rather like a bad idea. Is there no workaround?

Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
> Marek Marczykowski-Górecki:
> > As I've wrote before - you need to save keys *without* a password in
> > your GpgVM.
>
> I should use a zero-length passphrase for my keys?

Yes.

> I confess that sounds
> rather like a bad idea. Is there no workaround?

If someone could get access to your private keys, he/she probably can
also install there some keylogger to capture the password. This is
why split gpg was implemented - to keep the private keys away from
attackers in the first place. The whole disk is encrypted in Qubes so
offline attacks are prevented at lower level.

If you still want to use password-protected keys, it doesn't make sense
to provide the password from outside of gpgvm. You can try to setup
gpg-agent in gpgvm, but I don't know if that will work.

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

iQEcBAEBAgAGBQJVMQhFAAoJENuP0xzK19csmPAH/1HFIFPE6hw8UNio5cBUAit6
vB7Z1LQsoaP+s30mJhH1yQJSTbxKldTJ5LCO1xXlmekcUzivHiGxJS7FFki0klPp
ynfLJgKg55CjykuX8YgY+Ztrxt4eWkJS3JibEWH2EIoQRkLuQWYXVn11JAI37oA6
qdHVt8g4VOrix54WGhwYceslx3Dnn+6xH6EzYs1fw+UATreTdVAUGNu/VD9WEx87
QnM+Rrb3P8WOhlgnuNN8y9L1XPy/9oj58jDH0wbD6O79l4ylDo6Yt969WP8TZiQd
iZBvkj5m+BVwH1aLg+kIA2rBYQ+uazCb3CRUaK253VM+xadCT61/usBhY2IhKJY=
=Rsm+
-----END PGP SIGNATURE-----

[Andrew]

Marek Marczykowski-Górecki:

> On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
>> Marek Marczykowski-Górecki:
>>> As I've wrote before - you need to save keys *without* a password in
>>> your GpgVM.
>
>> I should use a zero-length passphrase for my keys?
>
> Yes.
>
>> I confess that sounds
>> rather like a bad idea. Is there no workaround?
>
> If someone could get access to your private keys, he/she probably can
> also install there some keylogger to capture the password. This is
> why split gpg was implemented - to keep the private keys away from
> attackers in the first place. The whole disk is encrypted in Qubes so
> offline attacks are prevented at lower level.
>
> If you still want to use password-protected keys, it doesn't make sense
> to provide the password from outside of gpgvm. You can try to setup
> gpg-agent in gpgvm, but I don't know if that will work.
>
>

If you still want to store your keys encrypted, in case of theft while
the disk is decrypted, you can store them in an encrypted loopback file.
Then decrypt and mount this file before using GPG.

Andrew

[J.M. Porup]

Andrew:

> Marek Marczykowski-Górecki:
>> On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
>>> Marek Marczykowski-Górecki:
>>>> As I've wrote before - you need to save keys *without* a password in
>>>> your GpgVM.
>>
>>> I should use a zero-length passphrase for my keys?
>>
>> Yes.

Yup, this works.

> If you still want to store your keys encrypted, in case of theft while
> the disk is decrypted, you can store them in an encrypted loopback file.
> Then decrypt and mount this file before using GPG.

Thanks for the suggestion!

It seems to me that, in addition to offering a much smaller attack
surface than thunderbird/enigmail, mutt also allows more flexibility --
macros for opening links and attachments in dispVMs, and so forth. If
you like, I can put together a sample qubes-optimized config with those
kinds of suggestions for the wiki.

cheers
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 18, 2015 at 12:28:59AM +0000, J.M. Porup wrote:
> Andrew:
> > Marek Marczykowski-Górecki:
> >> On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
> >>> Marek Marczykowski-Górecki:
> >>>> As I've wrote before - you need to save keys *without* a password in
> >>>> your GpgVM.
> >>
> >>> I should use a zero-length passphrase for my keys?
> >>
> >> Yes.
>
> Yup, this works.

On Debian or Fedora?

> > If you still want to store your keys encrypted, in case of theft while
> > the disk is decrypted, you can store them in an encrypted loopback file.
> > Then decrypt and mount this file before using GPG.
>
> Thanks for the suggestion!
>
> It seems to me that, in addition to offering a much smaller attack
> surface than thunderbird/enigmail, mutt also allows more flexibility --
> macros for opening links and attachments in dispVMs, and so forth. If
> you like, I can put together a sample qubes-optimized config with those
> kinds of suggestions for the wiki.

It would be great! Currently our documentation for mutt focuses on split
gpg setup only.

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

iQEcBAEBAgAGBQJVMaguAAoJENuP0xzK19csx/MIAI6XIc/56PC63atBwy7qkj1D
wcpPmGGTzKmqavx+/BLVOA1KBI9hsjoKjHq7L2mzsAhv2gceJxOdzf9a8Nq09G/A
kQ0dBPVNfAZxancLQSoJdZldPzxng5OuMy3mXlWQhshcgn3JQX+oRQ+RN9LqZbaE
fMGS+grEZeYhLBlAlvhcZR2okzArEoKLpmr65ya428HsDlxe9Wyzc+hxCfcC9kQL
2HZugeUFwVA5txTxjZvUfBFsg6aLDK/AEqzwCDd3vQt1GslKZa+ZN6GaoPQ1lVet
ttXQrwdqKW7Nep1Nw4ZJ9XiRlEleHywA05VE47jabzGO5mcp/ArH3t7XR0H+kLE=
=lGXG
-----END PGP SIGNATURE-----

[J.M. Porup]

Marek Marczykowski-Górecki:

> On Sat, Apr 18, 2015 at 12:28:59AM +0000, J.M. Porup wrote:
>> Andrew:
>>> Marek Marczykowski-Górecki:
>>>> On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
>>>>> Marek Marczykowski-Górecki:
>>>>>> As I've wrote before - you need to save keys *without* a password in
>>>>>> your GpgVM.
>>>>
>>>>> I should use a zero-length passphrase for my keys?
>>>>
>>>> Yes.
>
>> Yup, this works.
>
> On Debian or Fedora?

I'm testing on a debian muttvm talking to a fedora gpgvm. (I'm in the
process of migrating all my vms to debian.)

>>> If you still want to store your keys encrypted, in case of theft while
>>> the disk is decrypted, you can store them in an encrypted loopback file.
>>> Then decrypt and mount this file before using GPG.
>
>> Thanks for the suggestion!
>
>> It seems to me that, in addition to offering a much smaller attack
>> surface than thunderbird/enigmail, mutt also allows more flexibility --
>> macros for opening links and attachments in dispVMs, and so forth. If
>> you like, I can put together a sample qubes-optimized config with those
>> kinds of suggestions for the wiki.
>
> It would be great! Currently our documentation for mutt focuses on split
> gpg setup only.

sure, give me a few days to play with this, and I'll post a sample
config to the mailing list.

cheers
Jens

[J.M. Porup]

J.M. Porup:

Is this a bug in qvm-open-in-dvm?

qvm-open-in-dvm SomeWordDoc.doc

pops up a dialog box:

Unable to handle mimetype of the requested file (exit status: 32512)!

According to:

https://www.ruby-forum.com/topic/49024

It looks like error status 32512 means the dispvm can't find libreoffice.

The same command with pdf files works fine, e.g.

qvm-open-in-dvm SomePDF.pdf

I'm putting together a mailcap config to integrate mutt into qubes,
stumbled across this...are there any other MIME type gotchas for
inter-VM execution I should be aware of?

thanks
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

qvm-open-in-dvm uses "mimeopen -n" - check if that works for you in
normal VM - maybe you need to setup what application should handle that
mime type.

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

iQEcBAEBAgAGBQJVMsr1AAoJENuP0xzK19csUKQH/RhPFHrIXTnm1DdFs0MP2CNP
kOh+/nDBW3WsOKvcVQlJOhMVPwbIZ1y+570wkWrOmTt8NVY+irKklLfXUMFLKJ/X
o+YhfRCJQTvRE5E0E9noVNYfcmRCil5fA9PlQQ78LEF3Kunh9D/I7scPA+tCGS8C
Uv6v+c793DWHnJzE0ikn9N4DfJ0yvCnIZF6Kb1aNO3pAyTA4nYbtMuFXuJPm9a20
5NXhZ938MPVq0L/JubjybyZsIelzvqg62GDZN26fVM587fpxbm3X4kHhfzLtUynE
3QYUIiejN9ejrFkDFQZDBgeaYB1qPV///b49aw5drEXoRYg3xQ078MhODT21gQI=
=5uP8
-----END PGP SIGNATURE-----

[J.M. Porup]

>> Is this a bug in qvm-open-in-dvm?
>
>> qvm-open-in-dvm SomeWordDoc.doc
>
>> pops up a dialog box:
>
>> Unable to handle mimetype of the requested file (exit status: 32512)!
>
>> According to:
>
>> https://www.ruby-forum.com/topic/49024
>
>> It looks like error status 32512 means the dispvm can't find libreoffice.
>
>> The same command with pdf files works fine, e.g.
>
>> qvm-open-in-dvm SomePDF.pdf
>
>> I'm putting together a mailcap config to integrate mutt into qubes,
>> stumbled across this...are there any other MIME type gotchas for
>> inter-VM execution I should be aware of?
>
> qvm-open-in-dvm uses "mimeopen -n" - check if that works for you in
> normal VM - maybe you need to setup what application should handle that
> mime type.

I am able to reproduce this bug in terminal in both debian and fedora
template based vms.

`mimeopen Test.doc` opens the file and correctly reports:

$ mimeopen Test.doc
Opening "Test.doc" with LibreOffice Writer (application/msword)

Running qvm-open-in-dvm on the same file, however, briefly pops up the
LibreOffice dialog before returning the error:

Unable to handle mimetype of the requested file (exit status: 32512)

Can anyone else reproduce this?

thanks
Jens

[J.M. Porup]

J.M. Porup:

This problem also appears to affect pretty much any file that would be
opened by libreoffice. `qvm-open-in-dvm` works nicely with pdf and
links, also plain text, but returns the above error for .odt, ods, xls,
xlsx, etc.

Also testing this was difficult, as repeatedly invoking qvm-open-in-dvm
freezes dom0, forcing a reboot.

So I think there might be a bug to hunt in how qvm-open-in-dvm is
handling mime types.

Realizing this, I turned to `qvm-run --dispvm libreoffice test.odt` for
a less polymorphic mailcap. This produced another potential bug. Here's
how to reproduce:

create a file, let's call it test.odt

put this file in directory structure /home/user/foo/bar/baz/

cd into foo/bar/baz

run `qvm-run --dispvm libreoffice test.odt` from that directory

this pops up a dialog box saying

/home/user/test.odt does not exist

So somehow the absolute path is not correctly being passed, resulting in
this error.

Will keep poking around, if someone else could confirm these errors are
reproducible, that would be helpful.

thanks
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can you elaborate? I'm not aware of this problem.

> So I think there might be a bug to hunt in how qvm-open-in-dvm is
> handling mime types.
>
> Realizing this, I turned to `qvm-run --dispvm libreoffice test.odt` for
> a less polymorphic mailcap. This produced another potential bug. Here's
> how to reproduce:
>
> create a file, let's call it test.odt
>
> put this file in directory structure /home/user/foo/bar/baz/
>
> cd into foo/bar/baz
>
> run `qvm-run --dispvm libreoffice test.odt` from that directory
>
> this pops up a dialog box saying
>
> /home/user/test.odt does not exist
>
> So somehow the absolute path is not correctly being passed, resulting in
> this error.

It isn't a path problem, your command does not copy the file to the new
DispVM in any way.

> Will keep poking around, if someone else could confirm these errors are
> reproducible, that would be helpful.

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

iQEcBAEBAgAGBQJVM+ECAAoJENuP0xzK19csyL0IAJip6LnqYkPnN8V6wzQqaVqG
fClugOWchVYJOx4G3VfLFvEuSm5uhfEGC92gQQZ9fNbTX4H3Htjzo2zRcB6OCEi0
WOmnkuEEir9JU/7ApYkKwz9ld0HFVTB+D16TiE+qA3/sRwrrsU53cH25TfeoDV3f
/oHbcEgu8dlcS52l9AGsd9V/9nYiYppeX4wyKb8RkcDStqsk1mOO4tYvRLpqeMIf
bdux0gOzI2/motYnGVoxQRq0I6yCh4yzcyKKMlxrC/i7IYe+SP2P5wpjlHuet2nD
p6NwzTDujKB0h3E7eBMUmMHakPHfNn3MnQdtem8nM5Xs4wsi9vS5q0xxKs/IIlQ=
=/Xd2
-----END PGP SIGNATURE-----

[J.M. Porup]

Marek Marczykowski-Górecki:

repeated use of dispvms causes great instability. Others have reported
the issue in general. One vm will usually freeze, and cannot be
shutdown, but must be killed using the VM manager. The VM manager has to
be used, because any qvm-* command issued in dom0 console will hang, and
Ctrl-C produces the python callback. Other vms continue to work as
usual, but after a while they too will freeze. The only solution is a
reboot.

repeatedly running qvm-open-in-dvm seems to produce this quite a lot
more than usual, however.

>> So I think there might be a bug to hunt in how qvm-open-in-dvm is
>> handling mime types.
>
>> Realizing this, I turned to `qvm-run --dispvm libreoffice test.odt` for
>> a less polymorphic mailcap. This produced another potential bug. Here's
>> how to reproduce:
>
>> create a file, let's call it test.odt
>
>> put this file in directory structure /home/user/foo/bar/baz/
>
>> cd into foo/bar/baz
>
>> run `qvm-run --dispvm libreoffice test.odt` from that directory
>
>> this pops up a dialog box saying
>
>> /home/user/test.odt does not exist
>
>> So somehow the absolute path is not correctly being passed, resulting in
>> this error.
>
> It isn't a path problem, your command does not copy the file to the new
> DispVM in any way.

Indeed. If I move the test file to my home directory and run `qvm-run
--dispvm libreoffice /home/user/test.odt`, I still get the error that
/home/user/test.odt cannot be found.

I've tested this in both debian- and fedora-based vms, with identical
results.

Are you able to reproduce these two bug reports, or would you like
screenshots?

Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

When this happen next time, can you send a process list from dom0 (ps
auxfwww) and which processes are accessing qubes.xml (lsof -n
/var/lib/qubes/qubes.xml)?

> >> So I think there might be a bug to hunt in how qvm-open-in-dvm is
> >> handling mime types.
> >
> >> Realizing this, I turned to `qvm-run --dispvm libreoffice test.odt` for
> >> a less polymorphic mailcap. This produced another potential bug. Here's
> >> how to reproduce:
> >
> >> create a file, let's call it test.odt
> >
> >> put this file in directory structure /home/user/foo/bar/baz/
> >
> >> cd into foo/bar/baz
> >
> >> run `qvm-run --dispvm libreoffice test.odt` from that directory
> >
> >> this pops up a dialog box saying
> >
> >> /home/user/test.odt does not exist
> >
> >> So somehow the absolute path is not correctly being passed, resulting in
> >> this error.
> >
> > It isn't a path problem, your command does not copy the file to the new
> > DispVM in any way.
>
> Indeed. If I move the test file to my home directory and run `qvm-run
> --dispvm libreoffice /home/user/test.odt`, I still get the error that
> /home/user/test.odt cannot be found.
>
> I've tested this in both debian- and fedora-based vms, with identical
> results.

This isn't a bug. It is actually a feature that DispVM *do not* have
access to arbitrary file in calling VM.

If you want to open file in DispVM, you need to copy it there first.
This is what qvm-open-in-dvm does.

Regarding problem with qvm-open-in-dvm, try to open some .doc file, wait
for error message, but do not close it. While the message is still visible,
open terminal in this DispVM (for example using Qubes Manager start
gnome-terminal process there), then check contents of /tmp/mimeopen.log.

> Are you able to reproduce these two bug reports, or would you like
> screenshots?

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

iQEcBAEBAgAGBQJVNDXzAAoJENuP0xzK19cs58YH/jpq3p6LrjOirux4l8JeFchp
s/q594h4wRl015jcQWNSRQrOgxK8MJglFUsPZIq6GwgcFbDXzpISXTaJ99lWaObO
doPbbsI2Mgx2HqSkrBbWtNvGmVcGzd03QMPTEZ8XemNO+yFj7KAWJRZv0QlRfKQ6
fXXiMCaasMe35oVYNgvzoBgdDX9yNA6NWb7mhXGhh2mUkxnDUvY6SYSR0hoU33KO
JsHJs1SFAVCNhrl0U94rwVsL/P5PuvMsWJvbdvvaBCeAwVe1F4TP2JkbhSis8eGI
U/YBRbA7dJLMxxMWLrKhS7ne2KDZ+Ob99QYGjqU3Jo5fQaGt8tc3uszUjIabCs4=
=B6hY
-----END PGP SIGNATURE-----

[J.M. Porup]

Marek Marczykowski-Górecki:

>>>> Also testing this was difficult, as repeatedly invoking qvm-open-in-dvm
>>>> freezes dom0, forcing a reboot.
>>>
>>> Can you elaborate? I'm not aware of this problem.
>
>> repeated use of dispvms causes great instability. Others have reported
>> the issue in general. One vm will usually freeze, and cannot be
>> shutdown, but must be killed using the VM manager. The VM manager has to
>> be used, because any qvm-* command issued in dom0 console will hang, and
>> Ctrl-C produces the python callback. Other vms continue to work as
>> usual, but after a while they too will freeze. The only solution is a
>> reboot.
>
>> repeatedly running qvm-open-in-dvm seems to produce this quite a lot
>> more than usual, however.
>
> When this happen next time, can you send a process list from dom0 (ps
> auxfwww) and which processes are accessing qubes.xml (lsof -n
> /var/lib/qubes/qubes.xml)?

Anything in particular I should be looking for? 300+ running processes.
lsof -n /var/lib/qubes/qubes.xml lists nothing.

thanks
Jens

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Processes related to DispVM - qfile-daemon-dvm and its children. Check
if those are in any way different than during successful DispVM startup
(some additional child or sth like this).

> lsof -n /var/lib/qubes/qubes.xml lists nothing.

Hmm.. try lsof -n |grep /var/lib/qubes/qubes.xml

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

iQEcBAEBAgAGBQJVNtCXAAoJENuP0xzK19csUnMH+wXs2wQTvyoLyQTFGai+bA73
MK6qeJa4o/Dg832oiYp/5gLxEidPW0QOB4yZ79MjghH6NkAEx6/qXCkmylI2zdCs
yWtnva6eI64pbqNIAkibl4DI+h9C4LG41+1u+jYRu2vPEqlzofbw1u4KztXexitH
m0arVFrChJ7yCDUA5YbwkzttuegfByVVa2N69Cvc2SKqEBusmnvnmKWruFryPHjk
5McZqscFh4tyzeYTdB/yoZ4c03BJDyRCJevNo32RszdUBrBPcHvnvXOZApFdYBT1
GCk/QJ4LcE2JJ9EwYAvYuuXqlXcrSCK6W2PXkFLlk51HPm8b/lE9Whhs9sK3oNU=
=8yYu
-----END PGP SIGNATURE-----

[J.M. Porup]

So for any potential mutt users, here's a brief guide to get you started
integrating qubes tools into your mutt workflow. These suggested configs
are not exhaustive, and are still a work in progress--and some thought
should be taken to ensuring there are no security flaws in this
suggested config--for instance, failure to override certain mailcap
mimetypes could result in a potential exploit.

I recommend testing and tweaking in an appvm your .muttrc, .urlview, and
.mailcap until you have things to your liking, and then moving these
settings to the relevant templatevm.

.muttrc:

Same as over at https://www.qubes-os.org/doc/Mutt/, but I would add:

# Solarized ##is awesome
#uncomment the colorscheme you want to use, and comment out the others
source ~/.mutt/mutt-colors-solarized/mutt-colors-solarized-dark-16.muttrc
#source
$MAILCONF/mutt-colors-solarized/mutt-colors-solarized-light-16.muttrc
#source
"~/.mutt/mutt-colors-solarized/mutt-colors-solarized-dark-256.muttrc"

### also note you must specify absolute path of pgpewrap when using debian
### e.g. /usr/lib/mutt/pgpewrap

#use debian mutt-patched package for mailbox sidebar hack
set sidebar_width = 30
set sidebar_visible = no
set sidebar_delim='|'

#show/hide sidebar
macro index S '<enter-command>toggle sidebar_visible<enter>'
macro pager S '<enter-command>toggle sidebar_visible<enter>'

#navigate the sidebar folders
bind index CP sidebar-prev
bind index CN sidebar-next
bind index CO sidebar-open
bind pager CP sidebar-prev
bind pager CN sidebar-next


###qubes integration stuff

#open links in a dispvm using urlview
#see below for sample .urlview
macro pager \cb <pipe-entry>'urlview'<enter> 'Follow links with urlview'

#override default mailcap MIME settings with qvm-open-in-dvm calls
#see sample .mailcap below
set mailcap_path=~/.mailcap

bind attach <return> view-mailcap


### in .urlview file:
### TODO: this doesn't work with encrypted emails --
### urlview can't find the links
###
COMMAND qvm-open-in-dvm %s


###in .mailcap file:
###
### TODO: override most/all default mailcap settings to prevent
### opening in muttvm
### is there a way to do this polymorphically? i.e. not
### listing every damn mimetype by hand
###
### also would be convenient to use mailcap's TEST feature to
### show some html in mutt pager (e.g. with w3m, links or html2text),
### else open others in dispvm

# MS Word documents
application/msword; qvm-open-in-dvm %s

application/vnd.oasis.opendocument.spreadsheet; qvm-open-in-dvm %s
application/vnd.oasis.opendocument.text; qvm-open-in-dvm %s

# Images
image/jpg; qvm-open-in-dvm %s
image/jpeg; qvm-open-in-dvm %s
image/png; qvm-open-in-dvm %s
image/gif; qvm-open-in-dvm %s

# PDFs
application/pdf; qvm-open-in-dvm %s

# HTML
text/html; qvm-open-in-dvm %s


Like I said, this is just a starting point, but it might save you a few
hours of searching, anyway.

Suggestions and tweaks welcome.

cheers
Jens

[J.M. Porup]

After an upgrade today, my Whonix gateway starts with the error:


ERROR: Virtualizer xen xen-hvm unsupported by Whonix developers!
Whonixcheck aborted!

Using Virtualizer xen xen-hvm together with Whonix is recommended
against, because it is rarely tested. [1] [2] [3]

It could be made possible, but would require more Whonix contributors.
It may already work, but is highly experimental.

This might endanger your anonymity. Do not proceed unless you know what
you are doing.

If you wish to ignore this warning and to continue whonixcheck anyway,
you can set

WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"
in /etc/whonix.d/30_whonixcheck_default.
Recommended action:
- Shut down.
- Read Whonix documentation [4].
- Use Whonix with either VirtualBox or Physical Isolation [5].
Footnotes:
[1] https://www.whonix.org/wiki/LeakTests
[2] https://www.whonix.org/wiki/Test
[3]
https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection

[4] https://www.whonix.org/wiki/Documentation
[5] https://www.whonix.org/wiki/Physical_Isolation


After reading the fine manual [4], I am left no wiser. What does this
error mean, and what should I do about it?

thanks
Jens

[WhonixQubes]

Hi Jens! :)


The standard Whonix VM download images are not officially supported in
Qubes.

Did you install the VM images from Whonix.org into Qubes HVMs?


If so, this whonixcheck error is just informing you of this.

This approach for using Qubes + Whonix is deprecated.

You can still do it this way if you really want to or need to.

If so, just ignore the message or edit the 30_whonixcheck_default file
how the message says to suppress it.


If you really don't need to use Qubes + Whonix in this specific way,
then we have a new -- MUCH BETTER -- native port of Whonix as a
TemplateVM that you can dynamically generate Whonix-Gateway ProxyVMs and
Whonix-Workstation AppVMs with.

Here is the official documentation that includes install guides:

https://www.whonix.org/wiki/Qubes


And our new Whonix 10 based version should be out soon.


WhonixQubes

[J.M. Porup]

WhonixQubes:

I upgraded my Qubes Whonix templates earlier today using a bog standard
`sudo apt-get update && sudo apt-get dist-upgrade`. Note that I am not
using an hvm, but a standard template->appvm configuration. Starting the
Whonix gateway appvm returns the above error.

ideas?

thanks
Jens

[WhonixQubes]

OK, I understand now.

Sounds like something maybe got changed wrong in the "whonixcheck"
package.

I will check it out, talk with other Whonix developers, and get back to
you.

Thanks for this notice!

WhonixQubes

[WhonixQubes]

Some followup troubleshooting questions for you:



1.

Are you running Qubes R2 (not Qubes R3-rc1)?


2.

What's the output of this command when you run it in the Dom0 Terminal:

In Dom0 -> Terminal, run this command:

sudo yum list installed | grep -i -A 1 "qubes-template-whonix"


3.

What's the output of this command when you run it in the Whonix-Gateway
Terminal:

In Whonix-Gateway -> Terminal, run this command:

grep -i "_virtualizer" /etc/whonix.d/30_whonixcheck_default


4.

What's the output of this command when you run it in the Whonix-Gateway
Terminal:

In Whonix-Gateway -> Terminal, run this command:

sudo apt-cache policy whonixcheck



Thanks,

WhonixQubes

[WhonixQubes]

Also this one could be helpful too:



5.

What's the output of this command when you run it in the Whonix-Gateway
Terminal:

In Whonix-Gateway -> Terminal, run this command:

grep -i "http" /etc/apt/sources.list.d/whonix.list



Thanks,

WhonixQubes

[J.M. Porup]

WhonixQubes:

Sure

>
>
> 1.
>
> Are you running Qubes R2 (not Qubes R3-rc1)?

Yes. R2 for now.

> 2.
>
> What's the output of this command when you run it in the Dom0 Terminal:
>
> In Dom0 -> Terminal, run this command:
>
> sudo yum list installed | grep -i -A 1 "qubes-template-whonix"

hand copied from dom0:

qubes-template-whonix-gateway-experimental.noarch
2.1.8-201503091739 @qubes-dom0-cached
qubes-template-whonix-workstation-gnome.noarch
2.1.8-201503092029 @qubes-dom0-cached

>
> 3.
>
> What's the output of this command when you run it in the Whonix-Gateway
> Terminal:
>
> In Whonix-Gateway -> Terminal, run this command:
>
> grep -i "_virtualizer" /etc/whonix.d/30_whonixcheck_default

WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="0"
## WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER above.
#whonixcheck_skip_functions+=" check_virtualizer "

>
> 4.
>
> What's the output of this command when you run it in the Whonix-Gateway
> Terminal:
>
> In Whonix-Gateway -> Terminal, run this command:
>
> sudo apt-cache policy whonixcheck

whonixcheck:
Installed: 3:2.2-1
Candidate: 3:2.2-1
Version table:
*** 3:2.2-1 0
100 /var/lib/dpkg/status

hth
Jens

[J.M. Porup]

WhonixQubes:

deb http://mirror.whonix.de/whonixdevelopermetafiles/internal/ wheezy main
#deb-src http://mirror.whonix.de/whonixdevelopermetafiles/internal/
wheezy main

cheers
Jens

[WhonixQubes]

Looks like the update simply deleted a line for the "whonixcheck"
package.


Here is how to fix:

In the Terminal of your Whonix-Gateway TemplateVM and Whonix-Workstation
TemplateVM, run this:

echo 'WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"' | sudo tee -a
/etc/whonix.d/30_whonixcheck_default


Then when you shutdown your Whonix VMs (Gateways and Workstations), the
next time you start them or create new VMs it should be resolved.


Let me know if you have any further issues with this.

Thanks!

WhonixQubes

[J.M. Porup]

WhonixQubes:

> Looks like the update simply deleted a line for the "whonixcheck" package.

hi, no, that line is still there, just the bit got flipped from 0 to 1.

> Here is how to fix:
>
> In the Terminal of your Whonix-Gateway TemplateVM and Whonix-Workstation
> TemplateVM, run this:
>
> echo 'WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"' | sudo tee -a
> /etc/whonix.d/30_whonixcheck_default

maybe remove the `-a` from `tee -a` ?

> Then when you shutdown your Whonix VMs (Gateways and Workstations), the
> next time you start them or create new VMs it should be resolved.

After flipping the bit back to '1' in both gateway and workstation
templates, the gateway is unable to connect to the internet for whonix
time sync.

Before, whonix time check failed maybe 20% of the time. The workaround
was to shutdown the VM and try again. However, the gateway is now unable
to connect to the internet, even after multiple appvm reboots, and
indeed a qubes reboot.

tailing sdwdate.log gives me this:

$ tail -f /var/log/sdwdate.log
3688: Running sdwdate... pid: 3688 | LD_PRELOAD:
3688: sdwdate_preparation: who_ami is set to user.
3688: dispatching DISPATCH_PRE (SDW_MODE: startup):
/usr/lib/timesync/timesync_pre --autostart --identifier "timesync"
--progressbaridx "$ID" --mode "$SDW_MODE" --whoami "$who_ami"
3688: dispatching DISPATCH_PRE done.
3688: dispatching DISPATCH_PREREQUISITE (SDW_MODE: startup) (LD_PRELOAD:
): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
3688: DISPATCH_PREREQUISITE exited 2 | Tor is not yet fully
bootstrapped. 124 % done. Tor reports: Variable
check_bootstrap_helper_script_output is empty. | waiting...


cheers
Jens

[WhonixQubes]

Hi,

There was actually originally two instances of that setting in that file
for that version of the Whonix templates. The second instance "1" was to
reverse the first instance "0".


What's the current output of this command in your Whonix templates:

grep -i "_virtualizer" /etc/whonix.d/30_whonixcheck_default


For example, my output of that looks like this and works fine:

WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="0"
## WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER above.
#whonixcheck_skip_functions+=" check_virtualizer "

WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"


You could also manually edit the file and any instance of that setting
to "1".

This is how you could manually edit it:

sudo nano /etc/whonix.d/30_whonixcheck_default

Then change all of the WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER
settings to equal "1".

Then Ctrl + o to save, Enter to overwrite same file name, and Ctrl + x
to exit.


FYI: The next version of the Whonix templates will solve this issue.
Recommended to install new upcoming Whonix templates in Dom0 when
they're released soon! A number of improvements. :)

WhonixQubes

[J.M. Porup]

J.M. Porup:

> WhonixQubes:
>> Looks like the update simply deleted a line for the "whonixcheck" package.
>
> hi, no, that line is still there, just the bit got flipped from 0 to 1.
>
>> Here is how to fix:
>>
>> In the Terminal of your Whonix-Gateway TemplateVM and Whonix-Workstation
>> TemplateVM, run this:
>>
>> echo 'WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"' | sudo tee -a
>> /etc/whonix.d/30_whonixcheck_default
>
> maybe remove the `-a` from `tee -a` ?

ah, I see now. probably better something like:

sudo sed -i -e
's/WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="0"/WHONIXCHECK_NO_EXIT_ON_UNSUPPORTED_VIRTUALIZER="1"/'
/etc/whonix.d/30_whonixcheck_default

probably a fancier way to use '&' to avoid the repetition. Not much of a
sed junkie, to be honest.

that aside, manually editing the file makes no difference to underlying
problem.

hth
Jens

[J.M. Porup]

WhonixQubes:

Um. Why append when you can regex substitute?

> You could also manually edit the file and any instance of that setting
> to "1".

Yup, I manually edited the file in vim. The problem persists. Gateway
can no longer connect to the internet.

cheers
Jens

[J.M. Porup]

So I was able to reproduce this bug today. I removed the whonix packages
from my system, deleted all vms, and reinstalled from scratch.

The initial install worked fine, and the gateway appvm connected to the
internet. I immediately ran an upgrade, and discovered two bugs.

The first is the bug in /etc/whonix.d/30_whonixcheck_default, which I
mentioned yesterday.

The second is this:

####################################################################
## BEGIN ERROR in /var/lib/dpkg/info/timezone-utc.postinst detected!
##
## ERROR LOG:
/var/lib/dpkg/info/timezone-utc.postinst: line 36: /etc/timezone:
Permission denied
##
## BASH_COMMAND: echo "$AREA/$ZONE" > "/etc/timezone"
## EXIT_CODE: 1
##
## END ERROR in /var/lib/dpkg/info/timezone-utc.postinst detected!
## Please report this bug!
####################################################################

I'm not really sure why whonix needs to know my timezone, as this seems
like potentially de-anonymizing information. So I commented out this
line in the postinst file, and the upgrade completed successfully.

However, time check continues to fail in the gateway appvm, and tailing
the sdwdate log doesn't help much:

$ tail -f /var/log/sdwdate.log
3695: Running sdwdate... pid: 3695 | LD_PRELOAD:
3695: sdwdate_preparation: who_ami is set to user.
3695: dispatching DISPATCH_PRE (SDW_MODE: startup):

/usr/lib/timesync/timesync_pre --autostart --identifier "timesync"
--progressbaridx "$ID" --mode "$SDW_MODE" --whoami "$who_ami"

3695: dispatching DISPATCH_PRE done.
3695: dispatching DISPATCH_PREREQUISITE (SDW_MODE: startup) (LD_PRELOAD:
): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
3695: DISPATCH_PREREQUISITE exited 2 | Tor is not yet fully

bootstrapped. 124 % done. Tor reports: Variable
check_bootstrap_helper_script_output is empty. | waiting...

I googled this to no avail. Any ideas how to fix?

thanks
Jens

[J.M. Porup]

I see this has previously been reported on qubes-devel (which I am not
subscribed to, apologies) for R3, but this also now appears to affect R2
after dom0 & FC20 upgrade today.

after reboot, two different FC20-based appvms report the following
kerneloops error:

Kerneloops problem has been detected

BUG: Bad page state in process qrexec-agent pfn: fffffe400058ee00

...

A kernel problem occurred, but your kernel has been tainted (flag: GO).
Kernel maintainers are unable to diagnose tainted reports. Tainted
modules: u2mfn.

--

qrexec appears to work normally in these two VMs, but inter-VM copy and
paste is broken, I had to type the above into this email by hand.

What logs should I send through to debug this?

cheers
Jens

[J.M. Porup]

J.M. Porup:

> I see this has previously been reported on qubes-devel (which I am not
> subscribed to, apologies) for R3, but this also now appears to affect R2
> after dom0 & FC20 upgrade today.
>
> after reboot, two different FC20-based appvms report the following
> kerneloops error:
>
> Kerneloops problem has been detected
>
> BUG: Bad page state in process qrexec-agent pfn: fffffe400058ee00
>
> ...
>
> A kernel problem occurred, but your kernel has been tainted (flag: GO).
> Kernel maintainers are unable to diagnose tainted reports. Tainted
> modules: u2mfn.

Perhaps of interest -- the kernel oops only occurs the first time you
run an FC20-based appvm after upgrade. Subsequent vm starts do not show
the error.

Jens

[raah...@gmail.com]

Wow! talk about hijacking a thread! haha Mention a blacklisting program and it gets shunned from all sides. The myth that blacklists are ineffective are perpetuated by the gov't and criminals for obvious reasons, and by network admins(like torrents and p2p) for fear of slowing their network. So sad. I use pgl mainly for http and the easy point and click to temp allow ip's. If i'm blacklist 3/4's of the ip4 internet space, how would that not help my security? lol

I was just thinking about trying out peerguardian on qubes myself right now. But it Looks like this is going to be an issue :(

So far this issue, and the fact i can't log existing firewall rules are two things keeping me from making qubes my primary o/s.

Has anyone actually gotten pgl working in qubes?

[raah...@gmail.com]

On Sunday, April 12, 2015 at 6:34:46 PM UTC-4, Iestyn Best wrote:
> Hi All,
>
>
> I was wondering if anyone has thought of using a service like PeerGuardian to stop network traffic to known bad addresses?
>
>
> I am trying to work out, in my head, if it should be integrated into the default firewallvm or created as a separate firewall/proxy vm before the default firewallvm. I am leaning towards the latter and believe it should be created separately.
>
>
> Interested to hear other peoples thoughts on this.
>
>
> Regards,
> Iestyn Best

Hey man have you ever got pgl working in qubes?

[raah...@gmail.com]

I got it working now in qubes. I made a debian8 templatevm in qubes r3. Added the peerguardian debian repo and signing keys and installed the packages. Then installed gksu and opened gksu-properties and change auth mode to sudo.

Then in templatevm i did sudo pglgui, and added all the lists I want. Then i closed template vm and restart the untrusted appvm i created.

Then in the appvm i do sudo pglcmd start from the terminal (get Qprocess error if try with gui) it will take a minute to update lists. Then when done do sudo pglgui and thats it. everything works.

at first I tried from netvm but realized it was only seeing forwarded packets not outgoing so made no sense so best to run in appvm. I'm also not sure if wanting to make permanent whitelist if it will save the settings in the appvm, which means I might also want to give temp net acess to templatevm once a week and update the lists from there at the terminal. sudo pglcmd update. Or would there be a better way to do this without giving net access to the templatevm.

But this is great now i got apparmor and pgl working on qubes!

[J.M. Porup]

Has anyone experimented with Nymix? Seems like it might be a good fit
for Qubes. Not sure how mature the project is, though.

https://www.usenix.org/system/files/conference/trios14/trios14-paper-wolinsky-rev_100714.pdf

JMP

[raah...@gmail.com]

I don't know how that relates to an ip blacklist firewall? Not hearing much about nymix in action i'd rather just use whonix.

[Franz]

On Sat, Apr 18, 2015 at 6:21 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Apr 18, 2015 at 08:59:46PM +0000, J.M. Porup wrote:
> J.M. Porup:

> > Marek Marczykowski-Górecki:
> >> On Sat, Apr 18, 2015 at 12:28:59AM +0000, J.M. Porup wrote:
> >>> Andrew:
> >>>> Marek Marczykowski-Górecki:

> >>>>> On Fri, Apr 17, 2015 at 01:03:39PM +0000, J.M. Porup wrote:
> >>>>>> Marek Marczykowski-Górecki:

> >>>>>>> As I've wrote before - you need to save keys *without* a password in
> >>>>>>> your GpgVM.
> >>>>>
> >>>>>> I should use a zero-length passphrase for my keys?
> >>>>>
> >>>>> Yes.
> >>
> >>> Yup, this works.
> >>
> >> On Debian or Fedora?
> >
> > I'm testing on a debian muttvm talking to a fedora gpgvm. (I'm in the
> > process of migrating all my vms to debian.)
> >
> >>>> If you still want to store your keys encrypted, in case of theft while
> >>>> the disk is decrypted, you can store them in an encrypted loopback file.
> >>>>  Then decrypt and mount this file before using GPG.
> >>
> >>> Thanks for the suggestion!
> >>
> >>> It seems to me that, in addition to offering a much smaller attack
> >>> surface than thunderbird/enigmail, mutt also allows more flexibility --
> >>> macros for opening links and attachments in dispVMs, and so forth. If
> >>> you like, I can put together a sample qubes-optimized config with those
> >>> kinds of suggestions for the wiki.
> >>
> >> It would be great! Currently our documentation for mutt focuses on split
> >> gpg setup only.

>
> Is this a bug in qvm-open-in-dvm?
>
>     qvm-open-in-dvm SomeWordDoc.doc
>
> pops up a dialog box:
>
>     Unable to handle mimetype of the requested file (exit status: 32512)!
>
> According to:
>
>     https://www.ruby-forum.com/topic/49024
>
> It looks like error status 32512 means the dispvm can't find libreoffice.
>
> The same command with pdf files works fine, e.g.
>
>     qvm-open-in-dvm SomePDF.pdf
>
> I'm putting together a mailcap config to integrate mutt into qubes,
> stumbled across this...are there any other MIME type gotchas for
> inter-VM execution I should be aware of?

qvm-open-in-dvm uses "mimeopen -n" - check if that works for you in
normal VM - maybe you need to setup what application should handle that
mime type.

I tried to use this "mimeopen -n" because docx and pdf extension give a  "Unable to handle mimetype of the requested file" reply when opened in a Debian dispVM even if the default applications set to open in Debian template are explicitly set respectively to Abiword and Evince.

So, mimeopen -n correctly works with the same files (doc, png, abw etc) that are also correctly opened by "open in dispVM", but when used with:

1.  test.docx  gives:
"Can't call method "get_value" on an undefined value at /usr/bin/mimeopen line 162."

2  test.pdf gives
"Opening "test.pdf" with Print Preview  (application/pdf)
Filename "file:///home/user/Documents/test.pdf" does not exist or is not a regular file"

Regarding the first one I tried to look into line 162 but found nothing related to docx. Not sure if line 162 is really the following:
"print 'Opening '.join(', ', map qq{"$_"}, @ARGV)" but anyway here some more expert help is required.
 

Regarding the second one, the pdf, I can tell something  more because when I checked on Debian/Template/Nautilus/properties/open-with, this "Print Preview" was the default application set to open this sort of files. I changed the default application to Evince, selecting it in the menu, but obviously my change went not far enough to be recognized by mimemopen.

Happy New Year

Fran

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

iQEcBAEBAgAGBQJVMsr1AAoJENuP0xzK19csUKQH/RhPFHrIXTnm1DdFs0MP2CNP
kOh+/nDBW3WsOKvcVQlJOhMVPwbIZ1y+570wkWrOmTt8NVY+irKklLfXUMFLKJ/X
o+YhfRCJQTvRE5E0E9noVNYfcmRCil5fA9PlQQ78LEF3Kunh9D/I7scPA+tCGS8C
Uv6v+c793DWHnJzE0ikn9N4DfJ0yvCnIZF6Kb1aNO3pAyTA4nYbtMuFXuJPm9a20
5NXhZ938MPVq0L/JubjybyZsIelzvqg62GDZN26fVM587fpxbm3X4kHhfzLtUynE
3QYUIiejN9ejrFkDFQZDBgeaYB1qPV///b49aw5drEXoRYg3xQ078MhODT21gQI=
=5uP8
-----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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20150418212157.GE1066%40mail-itl.

For more options, visit https://groups.google.com/d/optout.