Re: [qubes-users] Re: Qubes locks up half the time on startup with filenotfound error trying to run qubes manager

2018-09-13 Thread 'awokd' via qubes-users
On Thu, September 13, 2018 5:43 pm, Guy Frank wrote:

> Ok, so on my next reboot, it ran into this problem again.  I made a copy
> of the journalctl log and tried to restart qubesd, to no effect.
>
> The attached file, jnlctlErr.txt, if you scroll down to 09:24:43, I think
> you can see where the Qubes OS daemon fails.  It is immediately preceded
> by the 1d.2 pci device worker failing, suggesting that something about
> this failure is causing the daemon from starting (which occurs below the
> blank line I added to the log). 1d.2 is a PCI Bridge, Intel Corp Device
> a332.  No idea what exactly this is or how to find out (not a hardware
> person).

What is :06:00.0 (and :05:00.0 for that matter), one of your USB
controllers? Check with lspci. Try unplugging all USB devices except
keyboard and mouse, and seeing if that error still shows. If so, try
moving your keyboard and mouse to a different controller, and disable
:06:00.0.

> One thing I thought of is the fact that there's a PS/2 card in the
> machine to which a PS/2 keyboard & mouse are attached.  Neither has ever
> worked in Qubes (though they worked in Windows), so maybe that's what's
> triggering the problem?  Will do some testing.
>
> When I attempt to start qubes daemon w/ sudo systemctl restart qubesd,
> journalctl log shows other errors.  The qubes daemon doesn't get started
> and I can't use the system.

Only qubesd errors I see in that log are:
Sep 13 09:52:19 dom0 systemd[1]: qubesd.service: Start operation timed out.
Terminating.

I don't know how to get more detailed logs to see why it's doing that-
maybe it has a systemd dependency on udev?

> What I can do is reboot.  And about every other time, Qubes comes up and
> is fine.  My concern is that at some point it'll stop doing this, so I'd
> really like to figure out how to solve this problem.


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


[qubes-users] Qubes 3.2 Whonix-14?

2018-09-13 Thread Stuart Perkins
I deleted the whonix vms and went to install whonix-14 and it won't work.  The 
salt command continues to say that the community repo is unknown.  What am I 
missing?

-- 
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/20180913223610.41a2deea%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Whonix version support policy

2018-09-13 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

With the recent release of Whonix 14 [1] and subsequent announcement
that Whonix 13 will reach EOL (end-of-life) on 2018-09-30 [2], we have
updated the Supported Versions page [3] with a new section [4]
explaining the Whonix support policy. For your convenience, the content
of that section, as it currently appears, is reproduced below. In the
future, users are advised to consult the Supported Versions page for the
current version of the policy.

- -

Whonix is an advanced feature in Qubes OS.  Those who wish to use it
must stay reasonably close to the cutting edge by upgrading to new
stable versions of Qubes OS and Whonix TemplateVMs within a month of
their respective releases.  To be precise:

 * One month after a new stable version of Qubes OS is released, Whonix
   TemplateVMs will no longer be supported on any older version of Qubes
   OS.  This means that users who wish to continue using Whonix
   TemplateVMs on Qubes must always upgrade to the latest stable Qubes
   OS version within one month of its release.

 * One month after new stable versions of Whonix TemplateVMs are
   released, older versions of Whonix TemplateVMs will no longer be
   supported.  This means that users who wish to continue using Whonix
   TemplateVMs on Qubes must always upgrade to the latest stable Whonix
   TemplateVM versions within one month of their release.

We aim to announce both types of events one month in advance in order to
remind users to upgrade.


[1] https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/
[2] https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/
[3] https://www.qubes-os.org/doc/supported-versions/
[4] https://www.qubes-os.org/doc/supported-versions/#whonix

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2018/09/13/whonix-version-support-policy/

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlubFiQACgkQ203TvDlQ
MDBUwg/+MaCDMouC26Kz+o8ADOHKPh45bXJbuQbYdctxePe5Wy4+Dz/JNQ/7t230
L9XKMm70tIiOyROC6CoGvvw6ncXZNkT7rEC7p5htklayoUtxMDUlJFQRjcvLn4h9
mMIXJk7KFIJp41+vAsxWlFGJ8UGpYXKc4tTaftiEh6JeoJye19dvoOuev7BB8ss1
M55+lKDz6Ut8+OBVfOh7iStWD+TU/sg2nUkPQ+tpAW/NI4EFYp7xI22nEth5NFwD
rJ6nd0xjYVmiNFQDXlPe9X2gB5av6XYoijb0e+wV/UlvmY7uVLTWKC5PpWY0vh9M
qM0NjwQz5vapD2EECbzivG9PVb3+OLExtJEFLZ9GPss0MvWI4IWZfDQDQalXgUj7
EzXO42DC3lGDXeUQIpUOZGtFbSu2uRaxLyW69HDqD4NYRjv6BvoEefK7eE1xKBfn
iGmKvv5ib8roP65No2wSlzqWBCcsmrFYwCwy7JrKh3hYB5jhdLf2prvpxOJoccbL
h6ba3ZNUPbNuj7znJxYF/9kF7OuK6OU5xjL39cA3Czfw0oUKmCqOAaCkIy8vLdbc
9vBKrPBlYbuZX2S6f+jp1wN/87dpty7jhPBFsUy8HCAtwBQU/A1tA1ZcsjS+5YpK
dRnbg5QyxomeJ5NQKgHP8HIwtga5ASiVF1HdkJWw6LaWwst3bXA=
=cWm/
-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/72a67366-02f1-6cde-26c2-e1a8f9bffd1f%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-13 Thread Chris Laprise

On 09/13/2018 08:00 PM, Anac wrote:



On 09/14/2018 12:13 AM, 22...@tutamail.com wrote:
Unfortunately I have been under constant attack and a target and the 
only solution I see is a fresh rebuild or new computer unless you have 
another idea?




https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service

Step 3 of the revised doc is probably the most effective test you can 
perform... its basically starting fresh with (at that point) no scripts 
added. Its just openvpn + the config. If that doesn't work then you may 
be right that something in Qubes itself has become broken and maybe a 
reinstall is necessary.


Before you go through the trouble of a whole reinstall, you could try 
setting your VPN VM to use Fedora 28 instead to see if it works. You can 
also perform a reinstall of the Debian template.




You said that Tor was running. When combining Tor with VPN, the VPN's 
connection type should be TCP, not UDP. Did you check that?


When connecting to VPN through TOR, TCP is required but depending on 
your provider's server config you may also have to change the port number.



--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/f8ea83ca-9adc-add1-c376-a0791eac5062%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-13 Thread Anac




On 09/14/2018 12:13 AM, 22...@tutamail.com wrote:

Unfortunately I have been under constant attack and a target and the only 
solution I see is a fresh rebuild or new computer unless you have another idea?



You said that Tor was running. When combining Tor with VPN, the VPN's 
connection type should be TCP, not UDP. Did you check that?


--
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/f9b9defd-b9b7-3484-19b2-84524feec988%40rbox.co.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: application icons not displayed in panel in xenial

2018-09-13 Thread Guy Frank
On Thursday, September 13, 2018 at 12:29:22 PM UTC-5, Guy Frank wrote:
> On Wednesday, September 12, 2018 at 6:52:48 PM UTC-5, Guy Frank wrote:
> > I created a template for Xenial.  Things work well w/ the AppVM based on 
> > this, but there's one hitch:  most of the icons for applications do not 
> > display in the panel.  The odd thing is that the icons show just fine in 
> > the Applications launcher and in Whiskers.  But on the desktop panel, they 
> > just show as a lock.  It gets quite difficult to find windows after a bunch 
> > have been opened without icons to clue me in.  Not sure what's causing this 
> > problem because evidently the .desktop files work fine for the launcher and 
> > Whiskers.
> > 
> > Guy
> 
> Hi folks:  Sorry, false alarm!  I was quite concerned about this issue 
> because it made Qubes potentially to difficult for me to use because I need a 
> lot of software and files open at once, so being able to see icons is 
> important for me.  Turns out the problem resolved itself when I rebooted the 
> system.  I've been reluctant to reboot because I had a number of things open 
> I needed to address.
> 
> Guy

Whoops, have to take that back.  More icons are now showing in the panel, but 
far from all.  Particularly important icons such as for various Libreoffice 
document types are not showing.

-- 
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/46806598-3aae-4334-9908-8b3846c48200%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes Windows Tools not working

2018-09-13 Thread 'Totally Zoid' via qubes-users
Hello,

I've installed Windows 7 x64 in a VM and updated it until SP1 and tried to 
install Qubes Windows Tools 4.0.1-3. I get to the part where it says it will 
place some data on the E: drive and asks me to restart the VM, but when I do 
restart, Windows won't boot and keeps launching Startup Repair, though I do get 
entries for explorer.exe and others in the Qubes start menu.

A possible bug: when Qubes Tools give the notice about the E: drive I also get 
a Windows dialog box in the background asking me to format the E: drive (even 
though I can already access it from Windows Explorer). However, whether I do it 
or not, I still get stuck at Startup Repair on subsequent boots.

Zoid

Sent with [ProtonMail](https://protonmail.com) Secure Email.

-- 
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/_m9qoqbZszYtlKd9Ed_BBryvGT0L6J8o9gU4OEweScTutTO37sxuqXF9JSe1sB_Bw-Mzx0UdeaHQC6Q_LdzKVJs-ERd7qEwU85J3dw3LBQI%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes locks up half the time on startup with filenotfound error trying to run qubes manager

2018-09-13 Thread Guy Frank
On Tuesday, September 11, 2018 at 5:12:00 PM UTC-5, Guy Frank wrote:
> On Tuesday, September 11, 2018 at 4:29:02 PM UTC-5, awokd wrote:
> > On Tue, September 11, 2018 7:10 pm, Guy Frank wrote:
> > > On Tuesday, September 11, 2018 at 1:44:13 PM UTC-5, Guy Frank wrote:
> > >
> > >> Was a bit premature thinking that my qubes installation was stable.
> > >> About half the time I start the system, it locks up and I am only able
> > >> to access Dom0 (qubes manager will not open, nor will any qubes, even
> > >> from command line).  The system gives a serious 'filenotfound' error
> > >> msg.  I've looked at previous posts on problems like this, but my
> > >> problem doesn't seem to fit what others reported--qubes.xml is not
> > >> empty and disk utilization is minimal (or near 50% in one case).  The
> > >> error message is:
> > >>
> > >> #
> > >> Whoops.  A critical error has occurred.  This is most likely a bug in
> > >> Qubes Manager
> > >> FileNotFoundError:  [Errno 2]
> > >> No such file or directory
> > >> at line 9 of file /usr/bin/qubes-qube-manager #
> > >>
> > >>
> > >> Line 9 reads:  load_entry_point('qubesmanager==4.0.16',
> > >> 'console_scripts', 'qubes-qube-manager')()
> > >>
> > >>
> > >> Ok, so the weird thing is that this works fine half the time.  On half
> > >> of my boot ups, I don't encounter this problem.  So if there is no such
> > >> file or directory, it's not there half the time.  qubes.xml looks good
> > >> (to my untrained eyes), and df -h shows nothing at more than 1%
> > >> utilization except for /dev/nvme0n1p1 mounted on /boot/efi which is 56%
> > >> of 200MB.  nvme0n1p1 is, I believe, the GPT table?
> > >>
> > >> I'm worried about coming to rely on this installation if at some point
> > >> the error doesn't go away every other reboot and becomes permanent.  Am
> > >> trying updates now--maybe that will help.
> > >>
> > >> Guy
> > >>
> > >
> > > Updating the software in dom0 doesn't make the problem disappear, though
> > > now the main error message is:
> > >
> > > QubesDaemonCommunicationError: Failed to connect to qubesd service:
> > > [Errno 2] No such file or directory
> > > at line 9 of file /usr/bin/qubes-qube-manager
> > 
> > Nothing related earlier in the "sudo journalctl -e" log? Try "sudo
> > systemctl restart qubesd"?
> 
> Thanks awokd!  I'll give these a try next time I run into the problem

Ok, so on my next reboot, it ran into this problem again.  I made a copy of the 
journalctl log and tried to restart qubesd, to no effect.  

The attached file, jnlctlErr.txt, if you scroll down to 09:24:43, I think you 
can see where the Qubes OS daemon fails.  It is immediately preceded by the 
1d.2 pci device worker failing, suggesting that something about this failure is 
causing the daemon from starting (which occurs below the blank line I added to 
the log). 1d.2 is a PCI Bridge, Intel Corp Device a332.  No idea what exactly 
this is or how to find out (not a hardware person).  

One thing I thought of is the fact that there's a PS/2 card in the machine to 
which a PS/2 keyboard & mouse are attached.  Neither has ever worked in Qubes 
(though they worked in Windows), so maybe that's what's triggering the problem? 
 Will do some testing.

When I attempt to start qubes daemon w/ sudo systemctl restart qubesd, 
journalctl log shows other errors.  The qubes daemon doesn't get started and I 
can't use the system.

What I can do is reboot.  And about every other time, Qubes comes up and is 
fine.  My concern is that at some point it'll stop doing this, so I'd really 
like to figure out how to solve this problem.

Guy

-- 
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/2556521e-ba44-48fd-b66f-5db21767abf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Sep 13 09:50:49 dom0 sudo[4220]:   pm : TTY=pts/1 ; PWD=/var/lib/qubes ; 
USER=root ; COMMAND=/bin/systemctl restart qubesd
Sep 13 09:50:49 dom0 kernel: audit: type=1123 audit(1536850249.779:214): 
pid=4220 uid=1000 auid=1000 ses=2 msg='cwd="/var/lib/qubes" 
cmd=73797374656D63746C207265737461727420717562657364 terminal=pts/1 res=success'
Sep 13 09:50:49 dom0 kernel: audit: type=1110 audit(1536850249.779:215): 
pid=4220 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_env,pam_unix 
acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 
res=success'
Sep 13 09:50:49 dom0 audit[4220]: USER_CMD pid=4220 uid=1000 auid=1000 ses=2 
msg='cwd="/var/lib/qubes" cmd=73797374656D63746C207265737461727420717562657364 
terminal=pts/1 res=success'
Sep 13 09:50:49 dom0 audit[4220]: CRED_REFR pid=4220 uid=0 auid=1000 ses=2 
msg='op=PAM:setcred grantors=pam_env,pam_unix acct="

[qubes-users] Re: application icons not displayed in panel in xenial

2018-09-13 Thread Guy Frank
On Wednesday, September 12, 2018 at 6:52:48 PM UTC-5, Guy Frank wrote:
> I created a template for Xenial.  Things work well w/ the AppVM based on 
> this, but there's one hitch:  most of the icons for applications do not 
> display in the panel.  The odd thing is that the icons show just fine in the 
> Applications launcher and in Whiskers.  But on the desktop panel, they just 
> show as a lock.  It gets quite difficult to find windows after a bunch have 
> been opened without icons to clue me in.  Not sure what's causing this 
> problem because evidently the .desktop files work fine for the launcher and 
> Whiskers.
> 
> Guy

Hi folks:  Sorry, false alarm!  I was quite concerned about this issue because 
it made Qubes potentially to difficult for me to use because I need a lot of 
software and files open at once, so being able to see icons is important for 
me.  Turns out the problem resolved itself when I rebooted the system.  I've 
been reluctant to reboot because I had a number of things open I needed to 
address.

Guy

-- 
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/3b759c3c-a3f5-47b8-a525-79839ad17e6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: ANN: Testing new VPN code for Qubes

2018-09-13 Thread 22rip
Thanks again for the help Chris...see my notes below:

IIRC you only need to specify the IP address of a regular system
interface, which in this case is eth0. So do a 'sudo ip addr' and look
up the eth0 'inet' address and put 'local ' in the config.
There's a chance this might work.

- Unfortunately this didn't work, I entered the following:

local 10.137.5.3

I was also able to find the IP in the Qubes Manager as an FYI, however I also 
ran the command in a terminal.

If it doesn't work, and you know of no custom firewall rules or net
settings that you can check or remove, then I'd consider the following
possibilities:

1. Your VPN provider has changed their TLS certificate or other
connection parameters. In this case their special client software (e.g.
installed on other devices?) would automatically refresh the config
files while your Qubes config would remain stale and unable to complete
TLS verification of the remote.


Remedy for this is to download your provider's current openvpn configs
and put them in /rw/config/qtunnel (making sure that qtunnel.conf points
to a new config file).

- It doesn't look like my VPN changed their TLS cert, downloaded a new config 
file and tried again fresh. 

2. Some residual network property of your VPN VM has triggered a bug
that prevents it from working correctly. Simple remedy would be to
create and setup a new proxyVM and use that instead.

- I built a new VPN template with a new AppVM, I get the notification pop up 
but no connection.

3. Unlikely: Interference from malware, possibly residing in sys-net.

- I built a new sys-net (by creating a new Qube, provide network access, 
attached my  Network controller/wirelessnot sure more is needed to setup a 
sys-net) but this didn't fix it.


Whats strange is that the connection is showing up as allowed in my firewall 
log, which makes me think everything is working with the Tasket solution. I did 
notice a strange connection to port 137 (NetBIOS) in my firewall which could be 
related or the cause. I also recently saw an ssh attempt from within Qubes.

Unfortunately I have been under constant attack and a target and the only 
solution I see is a fresh rebuild or new computer unless you have another idea?

Thanks again Chris and Qubes for what you are doing...

-- 
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/40c4f041-5a78-41ae-b1f2-3b2e29714343%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Android Studio AVD emulate

2018-09-13 Thread 'Andrzej Andrzej' via qubes-users
Any idea?

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


Re: [qubes-users] wifi password storage

2018-09-13 Thread Stuart Perkins


On Wed, 12 Sep 2018 22:16:01 -
"awokd"  wrote:

>On Wed, September 12, 2018 8:39 pm, Chris Laprise wrote:
>
>> Another alternative would be to configure a single sys-net with either
>> dispVM or Qubes-VM-hardening so that neither passwords nor malware would be
>> retained when sys-net is restarted.  
>
>Was going to suggest a dispVM as well, per
>https://www.qubes-os.org/doc/dispvm-customization/#using-static-disposable-vms-for-sys-
>.
>
>> Then you could control wifi
>> connections from a dom0 script.  
>
>How would you do that? qvm-run some nmcli command(s), passing along the
>wifi credentials?
>

My approach is with the presumption that he does not want to have to re-enter 
his work wifi credentials every workday morning.  Making sys-net disposable 
would forget everything every reboot...which would work...but he would have to 
re-enter work credentials every workday morning.

By separating work and general sys-net instances, he would not expose his work 
wifi credentials and would also not have to re-enter them every workday 
morning.  By creating a shutdown script to set to the generic sys-net on the 
way down, it would prevent accidentally connecting to an insecure wifi with the 
work sys-net instance.

I have zero 4.0 experience, as I rely on my machine far too much to attempt an 
upgrade from 3.2 at this time.  My approach would work well with 3.2, and would 
likely also work with 4.0.

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


[qubes-users] pEp in Enigmail-Thunderbird in Whonix-14 Qubes

2018-09-13 Thread qubes-fan
Hi, I learned that in Whonix-14 in Qubes 4.0 there is no default support for 
pEp in Enigmail-Thunderbird. Is it Qubes specific or Whonix specific? Is there 
any reason for not supporting pEp in Whonix? 

In other templates after installing the Enigmail addon the support for pEp 
jumps up automatically like Enigmail/pEp.

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/LMIW1vl--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.