Split GPG: thunderbird+enigmail stopped cache password

[cubit]

Halo!

I have run into more problems with thunderbird+enigmail on qubes and wonder if anyone else has problems.

I have a work appvm as Debian 8 with icedove 45.5.1 and enigmail 1.8.2
I have a vault appvm with my gpg keys as Debian 8 to do split gpg.

I updated templates and dom0 today and rebooted computer.  Now when I try to look at encrypted email I am prompted to enter my gpg key password every time I look at an encrypted email.   Also if I look at an encrypted email, go to a different program and then tab back to thunderbird I am immediately asked for gpg key password for the email I was looking at.

I do notice that the password prompt window looks different from pre reboot.

Some other package info:

ii  pinentry-gtk2   0.8.3-2
ii  gnupg  1.4.18-7+deb8u3
ii  gnupg-agent   2.0.26-6+deb8u1
ii  gnupg2   2.0.26-6+deb8u1
ii  gpgv 1.4.18-7+deb8u3 
ii  libgpg-error0:amd64   1.17-3   
ii  libgpgme11:amd64  1.5.1-6 
ii  qubes-gpg-split   2.0.24-1+deb8u1   


Frustratedly
++ Cubit

[cubit]

15. Dec 2016 21:53 by cu...@tutanota.com:

I updated templates and dom0 today and rebooted computer.  Now when I try to look at encrypted email I am prompted to enter my gpg key password every time I look at an encrypted email.   Also if I look at an encrypted email, go to a different program and then tab back to thunderbird I am immediately asked for gpg key password for the email I was looking at.

Another problem I discover.  If a PGP/MIME email has an attachment. I try open it asks for password to open it.  Put correct password in and it just ask again and again and again :(

++Cubit

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The solution is easy - remove password from your keys, especially when
you're using split gpg. It is inconvenient illusion of security. If
someone gets access to your private keyring, he/she will be able to get
your password the same way. Especially when you're relying on caching it
in RAM...

The only case when password protected keys makes some sense is
protection after hardware theft, but since Qubes use full disk
encryption anyway, it doesn't add anything extra in this case.

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

iQEcBAEBCAAGBQJYU2FfAAoJENuP0xzK19csfhwH/2jdT7GbbdhRXlQdw1xPmdgx
f0TchBo2w6UkAowm3JjRhY8iw832qQMTcvKwKqG0JW23VsGsUnU/bqvjd4sDwE9V
7UgTOnAWXqra+wSJHsUjX+L6G+Lxxp+skXq6FKdVcCEsrVYf3BHzxfVeNevf2wG+
HJyIHjHCzwrZyHVscxKUq6rBtOvyOS+zSLNPTn7Nd6V0Kl3eMQwfu0FPvlvdfbre
lkUZ+wcGGo2nDUS+v2qbGiYXvs6+wfAwTFoSuNSC9t7ruofB6NaTTnbZXTEXaXcm
hSM0qzE4RCYjoQAqNNJ0tHfe398xdyowCMeouWrchr8uZpZ2I+Zb3Bb4OlQ3J5o=
=FBVc
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

I recommend disabling your key's passphrase (i.e., using a blank
passphrase).

See our "note on passphrases":

"You may experience trouble when attempting to use a PGP key with a
passphrase along with Split-GPG and Enigmail. If you do, you may need
to remove the passphrase from your (sub)key(s) in order to get
Split-GPG working correctly. As mentioned above, we do not believe PGP
key passphrases to be significant from a security perspective."

The reasoning can be found throughout the document (search for
"passphrase").

https://www.qubes-os.org/doc/split-gpg/

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

iQIcBAEBCgAGBQJYU4KhAAoJENtN07w5UDAwMkMP/3xLSOdj5qjNprwgfiMEKMPe
XUmsjT55gSja0MQ9bKSVMZ58Mk4mp7tkbFpcSVQW7OpAodLUIIoNDg1vC+KwocUA
pAaWXFt2TsjVPNbIL2DJEwCM1z2ElXLciQj57YAzUj4ZvVTHKJAmrP6H8BmI7w0M
DdDhBHZG07KoYyvJ2zpUAj6OY56vOoUs8o9zYj9v6jZ5KOHnHbQVi9MHPQeWZz2f
SPQ4vlcVHpWLFj6pD9e5E1fISLHecmK1q4xmfM3YbtpP24PuFxX0BH1ReYWDKUoj
DZODmBok+Fl4VYx6DIs9bQ/TpKmD+72eN37lEL4QYwYq3SPQbkS2d+7v9H7u5t4u
Cj4ll4Dz9TtFNquLJxXD+TcWzNKTDve5aJP3UQwhZkj71nDuzBD+tKmWkVKMIVwy
X79TQtC0nYZUD/pDIOOiirIuAFwlOAf4l8J8tW/9+dafVB2rfVoRjj0n4jN42IQt
YpSZKOe3KlQAsuVy5tho3wP9WSP4NJIQuCLgCFj401DVD8ZJ21IFSHwiF1pnxOm9
Lsjer+BW3WIPIthoR+pFZhln8cVu7Ol3iCN790rOP3PH+uJLWK6V37cJAw4uPzac
VLEtpVJF4ncSNIf6UYkUoIkBbedfZ2y9ZxMQAEtep9eHFo67mrY18VRyglDKmYw+
fkSpUkgqL0+48a1HX/ht
=JM+z
-----END PGP SIGNATURE-----

[cubit]

16. Dec 2016 05:58 by a...@qubes-os.org:

I recommend disabling your key's passphrase (i.e., using a blank
passphrase).

 

This is disappointing to hear.    Removing the password sounds like a kludge than a fix to something that had been working okay.

I understand the model does not technically need a password but it is something I want (rightly or rongly) and it was working okay since R3.0 which to me indicates that it can work and just something broke.

The reasoning can be found throughout the document (search for
"passphrase").

I do and see that it is optional which should mean it works. From the page you say:

> > "Therefore, using a passphrase at all should be considered optional."

If it is not supposed to work  or is not supported it should be said  "do not use passphrase with key" instead of saying "is optional" as this lead people to understand that while not needed it works.

[Andrew David Wong]

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

On 2016-12-16 03:27, cubit wrote:
> 16. Dec 2016 05:58 by a...@qubes-os.org:
>
>> I recommend disabling your key's passphrase (i.e., using a blank
>> passphrase).
>
>
>
> This is disappointing to hear. Removing the password sounds like
> a kludge than a fix to something that had been working okay.
>
>
>
>
>
> I understand the model does not technically need a password but it
> is something I want (rightly or rongly) and it was working okay
> since R3.0 which to me indicates that it can work and just
> something broke.
>
>
>
>
>> The reasoning can be found throughout the document (search for
>> "passphrase").
>>
>
>
>
>
> I do and see that it is optional which should mean it works. From
> the page you say:
>
>
>
>
>

>>> "Therefore,using a passphrase at all should be considered

>>> optional."
>
>
>
>
> If it is not supposed to work or is not supported it should be
> said "do not use passphrase with key" instead of saying "is
> optional" as this lead people to understand that while not needed
> it works.
>
>
>

You're taking that passage out of context. If you read it in context,
it's clear that "optional" means optional from a *security* standpoint.

You're also ignoring the part that I quoted for you previously. Here
it is again:

"You may experience trouble when attempting to use a PGP key with a
passphrase along with Split-GPG and Enigmail. If you do, you may need
to remove the passphrase from your (sub)key(s) in order to get
Split-GPG working correctly. As mentioned above, we do not believe PGP
key passphrases to be significant from a security perspective."

What this means for you:

You're experiencing trouble when attempting to use a PGP key with a
passphrase along with Split-GPG and Enigmail, so you may need to

remove the passphrase from your (sub)key(s) in order to get Split-GPG
working correctly.

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

iQIcBAEBCgAGBQJYU9yRAAoJENtN07w5UDAwNpUQALklVgty82Xp468B+ncoL/xO
eC8cmtPzy8bdXT8Q7DvhnyGbYHgx8tSfV5UoqkuVE8k8QBqKyMihbrwjX2r3b8iu
Las9J5vLPVLSCfwg1erAKzr8yU2TPgs5PXVQYAYBBUGUXG+vGx/0sfruQXPgvwyj
hKVbR4N4U84df0p+0+kKiepjsglpGcKEHGFzU3o2neDUvJGqlRqL3TKHNAnzFuki
5N0ypLJVyVEwnb6LzfFrGyrM4J1uyzWFdD+XGRridquE2r7QHEIoawGQdCfGxxad
0hEIVRL66p1qI5uoG86fTrbDFjx/+pLOqxTEibj9vf33sMqF0BLCsPYNQT+O0mmq
GNKg3OrsqWNXPsuTtv2LsnWhlUNac7NkiqKcwCA57wbYkZWR7awIF10+Tca2bKS9
YvgiVdrIxTixEplCD43cxcdVSOaA+XSwIZF8qr4QEwxlHfqwFBRc7Wr/b52viCc4
DaoZdfD9lTxqGf3PiGqnXd1CoiYhOf+CpJRPIsLhzw6OGre4eK0yJeZFegYz1L5F
4U73NfTDL8AgMlZ7Krf+mvzL5+0CCiidNBgjZO7L6Cw2Gj9jw75Du+4igJhupZRi
TGc/7rH8YI6j6cW1yYQuxvxm8Nj6OxegAfHfZqg0vbCKAiH154t5ZYtCfCIvOkWI
+Q5aNLo+WDXEAj3bTsov
=vxTK
-----END PGP SIGNATURE-----

[cubit]

16. Dec 2016 12:22 by a...@qubes-os.org:

You're also ignoring the part that I quoted for you previously. Here
it is again:

"You may experience trouble when attempting to use a PGP key with a
passphrase along with Split-GPG and Enigmail. If you do, you may need
to remove the passphrase from your (sub)key(s) in order to get
Split-GPG working correctly. As mentioned above, we do not believe PGP
key passphrases to be significant from a security perspective."

What this means for you:

You're experiencing trouble when attempting to use a PGP key with a
passphrase along with Split-GPG and Enigmail, so you may need to
remove the passphrase from your (sub)key(s) in order to get Split-GPG
working correctly.

I do not want to come across rude but that's not how I see it.   I was using passphrase fine over several releases and it just stop working for a reason I have yet to find out why.

Removing the password is not a fix it is a kludge or work around.   A fix is getting it back to its previous working state with password use intact.

If passphrase use is so seeming temperamental that you have to offer this kludge, it should be said do not use!

[cubit]

16. Dec 2016 05:58 by a...@qubes-os.org:

I recommend disabling your key's passphrase (i.e., using a blank
passphrase).

Some frustrating experiments later....

+ Changing my vault VM to fedora24

   - It remembers the keys password but does not honor the timeout settings, it always reprompts at 5 minutes despite "export QUBES_GPG_AUTOACCEPT=86400" being in .bash_profile 

   - Removing the password from my subkeys and it still prompts for a password and only works with the password I removed, not blank.  interacting with gpg on command line shows that the password does not exist all signing / decryption is automatic

Any reasons for the above behavior?

+ then changing vault VM back to debian 8

  - password removed and I can now read email and attachments without being bothered when looking at each and every email.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 16, 2016 at 07:23:18PM +0100, cubit wrote:
> 16. Dec 2016 05:58 by a...@qubes-os.org:
>
> > I recommend disabling your key's passphrase (i.e., using a blank
> > passphrase).
> >
>
>
>
>
> Some frustrating experiments later....
>
>
>
>
> + Changing my vault VM to fedora24
>
>    - It remembers the keys password but does not honor the timeout settings, it always reprompts at 5 minutes despite "export QUBES_GPG_AUTOACCEPT=86400" being in .bash_profile 

Hmm, it works for me...

>    - Removing the password from my subkeys and it still prompts for a password and only works with the password I removed, not blank.  interacting with gpg on command line shows that the password does not exist all signing / decryption is automatic
>
> Any reasons for the above behavior?

Make sure you use gpg2, not gpg.

> + then changing vault VM back to debian 8
>
>   - password removed and I can now read email and attachments without being bothered when looking at each and every email.

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

iQEcBAEBCAAGBQJYVDSmAAoJENuP0xzK19csLZ0H/3OYBirvjfy0B1iCQsEm+tnB
CX5uS10JBZK/yx2TW1CtIKgkrML0/uDdy01YdJK1JThDegYVsovS6pfS8GqBb6ZZ
H3lWRe2Jb2Av2cK7O89JXBbrZm2H7zjEHg/8ugz/pgmNCe85yz89Q1sE0ZIQNMxX
zG2d2nRqb5Z6cuF2fFQU9Qvv2n8C22pEn3+owpZZOPUkOk20Cd9C7uKtLP0EmWMt
fBsCUsAmxr7FsE9F5ip8ILWnhcU6xxcgDwJxSS2pTmMJ4molWL1yn7z26y4twM3X
Svhm+6uzp7QICgVcZHYy4wtkSoGsqjGuMVWM7rrqKDdh3iVbHiIPOTeImkwy/yI=
=U0hX
-----END PGP SIGNATURE-----

[cubit]

16. Dec 2016 18:38 by marm...@invisiblethingslab.com:

+ Changing my vault VM to fedora24

   - It remembers the keys password but does not honor the timeout settings, it always reprompts at 5 minutes despite "export QUBES_GPG_AUTOACCEPT=86400" being in .bash_profile 

Hmm, it works for me...

   - Removing the password from my subkeys and it still prompts for a password and only works with the password I removed, not blank.  interacting with gpg on command line shows that the password does not exist all signing / decryption is automatic

Any reasons for the above behavior?

Make sure you use gpg2, not gpg.

Both are installed in the Fedora 24 template but if I understand correctly, the qubes gpg wrapper now defaults to gpg2.

[Andrew David Wong]

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

Yes, but they use different keyrings, so if you update your key in one
keyring (by removing the passphrase from it), it will not necessarily
be updated in the other one.

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

iQIcBAEBCgAGBQJYVMgCAAoJENtN07w5UDAwRAMP/0xbqps+qY2eY/L1l+OM4/uI
ENdwGGTbqu24EAKATkxQJ6byMaMCUG06ziqZoKYS12+msCM3SlE2O6uv/Pezlb4D
ilso4iJyrgJDHKg83E2ciVdquZ3MBevAPHGcynpTV6ni6f9g+4mN2Py+QRFn7uPl
f9HefYl8EZOq1xJMqI0xWtNOl2Ekee1ueCxa7SAfA/zqG7AnRoEnpYMdnCqNN8TU
Xy66xr5vk+g2ZZ26qTbKvns0XCo1KMXCOOJLWTLHd/IcAUWp1o5zKqttWcMDCDfm
Ttb61Y1QROuyLyFnFtCF+jCYhk7dvQmvw9DkAN1N9xDztchjyQsKVQpqVcnsGsVm
oPRTnL3jF0S2j5GL0v9wc+Ab6mKhcChIZOdrQHctDhLigbBxBRgMPmu4BEGOM4Yb
ClMzseZ+efj2plHMQPIj3prLGweUqTmImrUxJVmHzvlQqGgF5umU5HkjSf5Zo5iZ
vkf4xNS1s3JsK+KxW65tHNBUM67PNvcdnYskiRPf57dD+8trJusH1Ho+GSoiehsB
sNhHeps043Ir5G/Pjz+neft6Jw7fd6kffU00UJY2kzDCVmD05whpT5cyZh9WOrm4
ffX4mGlAI71/IdUR2UIjvcUeOg4QvMfRTAC2MRyPOzOiy0j8K8PuuyyyKApKNrTG
G7FHS7oUkEIEEbqcvUAi
=FwXO
-----END PGP SIGNATURE-----

[5n7xyb+qph...@guerrillamail.com]

Hi,

I'm also facing the same problem. The split-gpg no longer caches the password through the set timeout on the QUBES_GPG_AUTOACCEPT variable.
I also don't want to remove the password from my private key since I used it in different devices and I don't want to use a different template as I have many things installed on my debian 8 template.
This stopped worked recently after an upgrade. Is there any way that this could be restored in the same state as it was working before?
In addition, does anyone knows how can one use the latest version of enigmail with thunderbird? The only working version of enigmail is 1.8.2 (it seems that this is a limitation from the split-gpg).

Thank you

----
Sent using Guerrillamail.com
Block or report abuse: https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 3:08 PM, 5n7xyb+qphld0j5ytif4l via qubes-users
<qubes...@googlegroups.com> wrote:
> I also don't want to remove the password from my private key since I used it in different devices and I don't want to use a different template as I have many things installed on my debian 8 template.

Using a separate (minimal) template may be a good idea regardless
simply to reduce the number of things which must be trusted to not be
actively malicious in order to maintain the confidentiality of your
pgp key.

I have several templates ranging from "extremely minimal" to "kitchen
sink" for exactly this reason, and would recommend the practice for
its own merit regardless of split-gpg / enigmail / whatever.

[Gaea]

Please what are the differences between:

Minimal:
Extremely Minimal
Full ?? VMs

Jean-Philippe Ouellet:

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 4:20 AM, 'Gaea' via qubes-users
<qubes...@googlegroups.com> wrote:
> Please what are the differences between:
>
> Minimal:

fedora-24-minimal + text editor, openssh, git, zsh, etc.

> Extremely Minimal

fedora-24-minimal + a text editor -- nothing else

> Full ?? VMs

All the crap. Browser, photo editor, media player, all the giant
pieces of software that pull in half the world as dependencies.


I have various others in between, such as one with only a browser (for
online banking and such).

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 1:11 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> I have various others in between, such as one with only a browser (for
> online banking and such).

I should clarify, this is a template with only a browser, and an
individual VM used for only online banking. The "and such" each have
their own respective VMs derived from the browser-only template.

[5nmnvk...@guerrillamail.com]

Uhm I see.That's a very good idea indeed.
But anyway, reporting to my initial question, is there a way that the QUBES_GPG_AUTOACCEPT timeout could be respected without having to type the password countless times? I don't want to remove the password from my key for the reasons stated earlier.

[Gaea]

Thanks Monsieur Ouellet.

I thought that there was a smaller version of Qubes that may be easier
for me. I am totally new to all this. Been with WINDOWS, but want
something more resistant to hacking & invasion of my privacy.

I managed to install Qubes 3.2. Now my google voice mail that records
MP3 like voicemail.mp3 wont play. In windows all I have to do is click
on (Play)

My laptop meets vt-d, vt-x, tpm, txt. It is UEFI, Legacy, UEFI-CSM
capable. Windows and Ubuntu which I tried both run in UEFI. But Qubes
refuses to Boot under UEFI. Tried all suggestions from forums.

I bought another hard drive to install Qubes in Legacy mode. I have to
swap Windows/Ubuntu HD & change BIOS to legacy, put in Qubes HD to fire
up QUBES. I am writing this in Qubes. Painful, but I really want to
leave WINDOWS behind. I don't see the point of running WINDOWS as a
QUBES VM.

Bye

Jean-Philippe Ouellet:

[Andrew David Wong]

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

On 2016-12-22 19:51, 'Gaea' via qubes-users wrote:
> Thanks Monsieur Ouellet.
>
> I thought that there was a smaller version of Qubes that may be easier
> for me. I am totally new to all this. Been with WINDOWS, but want
> something more resistant to hacking & invasion of my privacy.
>
> I managed to install Qubes 3.2. Now my google voice mail that records
> MP3 like voicemail.mp3 wont play. In windows all I have to do is click
> on (Play)
>

It sounds like you just need a media player. I recommend VLC, which you
can download after enabling the RPMFusion repo. Instructions are here:

https://www.qubes-os.org/doc/software-update-vm/#rpmfusion-for-a-fedora-templatevm

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

iQIcBAEBCgAGBQJYXOJvAAoJENtN07w5UDAw9zQQAM3oNGIBxopAeqfRPdAgNY5t
r+TZGTDjaadKPT4i6xqe28Uym8Yx2spD5flCxKcBCV5opXXPqDliBbH6Zl38R9o4
IYDh6ZTSQ/cVh7Qzkp0k95xct7QS9Y4VWQI7PUt3zCnpK8IRVvAWdc4eMHIV6nju
oX/l06peMUc2p2itbpymfT2Fb3OUMgkzjW2+i9ML9/BdGFaiPKTexcywS1kKRGj/
C1GXARfdbZk6lOpsWvItp9FOvLRy8Y66DJFkC81AsFE0nVUYi/426NqydbkoXlwy
tCP2EZwWrgS7eUMro8EQ4rKyLGUHJwXNSfXOetH97tTkH8wc+e0QFOTEjze64G+N
t9EYDZHl0FQV3BaVQzxOncoYbme31QmqX2DnsQk8Mdv1JUdOoZvlOVHQuSEkxdij
9CqRvaIC26V9yIm/mWaZvRTm94ycz9neKFj/VGx7qo8zYcidgKRoosES2kBfvSRM
5XgBXlzojZr6/dJhlu4uAAyJWxkAbGjFA0iNPQsjZha2IaxuH3TbFb0vQM1+X/jL
08eTXuW9cPXefKBOBE4YP6ORJOXZMhfhMPUvLiqYhMG97juY29K24dD66jCJ/fmJ
/mHc358K+R0wyyRaKmk0qJfO5zeJtHncPClyltai72zRqhVSPagBhSY9g5t/Hji6
bsD4aLX3dFTtB6QmBrzM
=VoUC
-----END PGP SIGNATURE-----

[Gaea]

Andrew David Wong:

> On 2016-12-22 19:51, 'Gaea' via qubes-users wrote:
>> Thanks Monsieur Ouellet.
>
>> I thought that there was a smaller version of Qubes that may be easier
>> for me. I am totally new to all this. Been with WINDOWS, but want
>> something more resistant to hacking & invasion of my privacy.
>
>> I managed to install Qubes 3.2. Now my google voice mail that records
>> MP3 like voicemail.mp3 wont play. In windows all I have to do is click
>> on (Play)
>
>
> It sounds like you just need a media player. I recommend VLC, which you
> can download after enabling the RPMFusion repo. Instructions are here:
>
> https://www.qubes-os.org/doc/software-update-vm/#rpmfusion-for-a-fedora-templatevm
>
>

Thanks Andrew.

Your suggestion works. I had actually followed web searches to RMFusion
site and other places and tried their recommendations and came up short.
And there it was in Qubes-OS docs. I am puzzeled that I did not hit it
in my searches. OR maybe I skipped Qubes-os site.

Following your pointer I was able to install VLC where others failed.
Once I had VLC installed and figured out file type associations now I
can listen to voicemail with a simple click.

Thanks

[5qdxzn+46d...@guerrillamail.com]

So, this still doesn't work under the debian-8 template. After the update the QUBES_GPG_AUTOACCEPT stopped work and has no effect whatsoever in the cache timeout.
Therefore it would be advisable if this variable could be removed from the documentation as it does not work and could potentially lead to confusions among users.

Since I'm running out of ideas or experiments in order to have the gpg cache working again, I'll probably consider to change my template vm from debian-8 to fedora-24 (possible the minimal). Before I do that, I'd like to know from the qubes community which kind of security setup is the most advisable for the vault and icedove/thunderbird ?

Many thanks

[Andrew David Wong]

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

On 2016-12-27 08:56, 5qdxzn+46dbca9vmtsno via qubes-users wrote:
> So, this still doesn't work under the debian-8 template. After the
> update the QUBES_GPG_AUTOACCEPT stopped work and has no effect
> whatsoever in the cache timeout. Therefore it would be advisable
> if this variable could be removed from the documentation as it does
> not work and could potentially lead to confusions among users.
>

Is this with or without an empty/blank key passphrase?

> Since I'm running out of ideas or experiments in order to have the
> gpg cache working again, I'll probably consider to change my
> template vm from debian-8 to fedora-24 (possible the minimal).

Works fine for me with the default fedora-24 template.

> Before I do that, I'd like to know from the qubes community which
> kind of security setup is the most advisable for the vault and
> icedove/thunderbird ?

What exactly do you mean?

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

iQIcBAEBCgAGBQJYYq+aAAoJENtN07w5UDAw8YEP/3YT+Eq4UFH6VPeAAGX72LFj
rak9nE7Nwje9f5ZaEzsNQHGTTKhICk7VedAdaMhOjAS1scagsCwGfMU8FO0mATGs
5Q9fLuzeEPaBogpJy2yABHJwZ+K9tUH8RJx/SCA9zLiJApTZ9d8OVmIWNYjY9ckB
J7zzMAvGfMh34YD4R+xQghj2aBG2HMzk81fO2e1RMhGJyAcRu8RYRb8RyRJAKqNQ
MvwwVwm25gsfW65QsMv4WS9az3AjyMDkSaVSVV1DTHvofPwE+Azu14DxGONsAls2
ruDOoI9TVLjffZIsCg3IYUMsfowg4b10Ty6aQfqVzDG2XmkHa5HD6ViFkugdo38Z
+8LS5uaX34scIm0/raC2clw3GSQBvlyqKJ6IKzVNqYeDConAQq7aOwB+u4KPcCUL
EcafiTobART9mQ5abc7K9wRk29pzunAENP5n94EI+JwqzUYgZg/3rZfCnjZ9aCz8
i9j8S0q2VwmIbz31NFgxTpHXYI8WutAEUU4KIQORsIJpEdaFbDDwzFcA/rozSCpL
R2UjO3s5usJvyp/wQDOf1vg2csQydKnIzjOG8ZgqHbDjO3XM0MYBswSLU6evaT8C
NOlSt0DPvKNJVIn4IJ4Khvs6XpssWTLJRUWrFp4EGJWPTendN7thp7Im1fLA2u4X
QKN6ZXDujQZv8Jc+lFHO
=0cqQ
-----END PGP SIGNATURE-----

[5qfppt+dta...@guerrillamail.com]

Is this with or without an empty/blank key passphrase?

Key is protected with a passphrase

Works fine for me with the default fedora-24 template.

Between fedora-24 or fedora-24-minimal, which one is more recommended in a security perspective? What I mean is, using the standard fedora template with all apps installed on it advisable or is it preferable to use a dedicated template or a minimal bare bone template to diminish the surface attack?

[Andrew David Wong]

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

On 2016-12-27 11:34, 5qfppt+dtaepv4a6ll7k via qubes-users wrote:
>> Is this with or without an empty/blank key passphrase?
>
> Key is protected with a passphrase
>

In that case, there's no need to change the documentation, since it
already works as described (i.e., without a key passphrase).

>
>> Works fine for me with the default fedora-24 template.
>
> Between fedora-24 or fedora-24-minimal, which one is more
> recommended in a security perspective? What I mean is, using the
> standard fedora template with all apps installed on it advisable or
> is it preferable to use a dedicated template or a minimal bare bone
> template to diminish the surface attack?
>

The minimal template has a smaller attack surface in general, but it
doesn't come with Split GPG pre-installed. There is probably not a
significant difference, since the Split GPG protocol tightly controls
inter-VM data transfer. There is no general recommendation here, since
the degree to which the full vs. minimal template attack surface
matters depends on your threat model. For some people, it makes more
sense to save the disk space by not having an extra minimal template
for it.

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

iQIcBAEBCgAGBQJYY2d4AAoJENtN07w5UDAwCW4P/0SmNpZmrS/p1zlxMOJNn81Y
BGxbcErD95vlKMkQnERSLFqCK2lTy9JykW0jR1cOJbpG2RWEn06zYe/a1jSm+HFL
9Nv0puMnCasyepoiMRXT/KtGlcbBpmSiRlOuavsJjB8m31X7ygedC4sP3aNix/Xb
ngeZWVUSXMjOG9xMRdjY7VUw2J4IqkAELEDs5LrFiavWzoN7QDjtm88LN43WbU/q
2eOidZC5zdUzptZaC2oNH1dWfWDo8WWSL8zRjGaf1i1628OAJA0INmC1S3Xa4t2W
yMxdN7OqBVMlMt1rXEgd316EgQ7PzQBQyhgMGsUMW0P/s1+BMqHZlwfV/hm+AnrZ
Dw8sg74L4sbzcX50om6RVgp3CL/5NWTQgcKZL1q/OezhYTyanwBhgcuhC6FUQz3Q
Gx0LLbOFE5QaB9S4k4+o47oHC2EZEclBfYMLHaXqJaFTdK+pFbxvtpHzRmJXEiBE
hSxNySxK5GpQhODlwz401oogDXudJsf8qRfs/ueS+7/a1uZttIRHVbIz8icEjbzP
y4nTItuRKC9K/Ku8A4QC/KFZmbgZpt9ueirlpnqwf/rXgk/Ytq57AxDzmZkvnl0J
o2o+o9beT6ScTYSzAxlsnUVsOIFjJmsDomX2wl7BrQB/VtlIkmH5hNiKE5unTbCj
g+8a+oL7knxlfsHa67zD
=OgX0
-----END PGP SIGNATURE-----

[5qtbx9+9hw...@guerrillamail.com]

In that case, there's no need to change the documentation, since it
already works as described (i.e., without a key passphrase).

Before the update was working fine with the password. Now the QUBES_GPG_AUTOACCEPT is no longer respect as one have to type in the password every single time. With all due respect, you are not trying to convert a bug into a feature and claiming that this is the expected behavior, right ?

The minimal template has a smaller attack surface in general, but it
doesn't come with Split GPG pre-installed. There is probably not a
significant difference, since the Split GPG protocol tightly controls
inter-VM data transfer. There is no general recommendation here, since
the degree to which the full vs. minimal template attack surface
matters depends on your threat model. For some people, it makes more
sense to save the disk space by not having an extra minimal template
for it.

Thank in that case I'll opt to choose the fedora 24 normal template.

[Andrew David Wong]

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

On 2016-12-28 06:41, 5qtbx9+9hwav8wa98xp4 via qubes-users wrote:
>> In that case, there's no need to change the documentation, since
>> it already works as described (i.e., without a key passphrase).
>
> Before the update was working fine with the password. Now the
> QUBES_GPG_AUTOACCEPT is no longer respect as one have to type in
> the password every single time. With all due respect, you are not
> trying to convert a bug into a feature and claiming that this is
> the expected behavior, right ?
>

Look, we've already explained (multiple times, in this very thread)
that PGP key passphrases may have to be disabled in order to get Split
GPG to work and why this is the case. Split GPG was designed with the
expectation that there would be no passphrase on the key. If it worked
well with a passphrase before the update, that was a fortuitous
coincidence. If, after the update, it no longer works well with a
passphrase (but still works just as well without one), then this
simply doesn't qualify as a bug according to the original design.

You've identified a certain property that used to exist but that was
never intended as a feature. Now that this property has ceased to
exist, you're claiming that a feature is missing and that a bug has
been introduced. That simply doesn't follow.

I understand that you want to use a passphrase on your key despite our
arguments against it (and despite offering no counterargument), and I
respect that. It's your right to do with your keys as you please,
whatever your reasons might be. However, I'm afraid Split GPG simply
wasn't intended to accommodate you. If you'd like Split GPG to support
keys with passphrases, then you're more than welcome to submit a patch
that implements it, and we'd be grateful for your contribution!

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

iQIcBAEBCgAGBQJYZAsUAAoJENtN07w5UDAwvQAP/jL0Vx13c/W5JNSjsYW0zb+3
6sc7P3KuNmFDpsgHC0R5kMpM1BtlDS9NNI4f8A6wa5U8lAJODWgi3ijzOoqX95yj
uTND54KYpUQF/TrTEWypsg08QxCXBWKeiKc9YGw68ArnjDWG4s6apN+ug1VTu4Ww
N1ATnPnfKR1kLW+CogIuoMS3jdHG6c5YVAUyjFt0Q61LgCoFf4t3VvkyY9k47G9i
7UIOf59brpmzmri5dCxKqdglTKjc1LRKpV4ETY5mZB1pslRnL+qeQpjhBJQrO6E0
DXzd2xWVHbfEhQNDoKo83+XUS5jlfxA/hqxLmP2OMCZQQeklHQRIlcqd6GlYUlUi
0LH5v16mrfLjE1n5Oj5X/ItOmy9DePnnc21DyYtrO5qAUgbtyfhOcsu+rpZv7O7S
nQUJ8Lcox/pnw0C/sdgOp6z71kQkkP9CLgcL9+Dcsz7iGlUuaELiOTSG52jjzjUB
h02M1u5C68m0uDjNF1jcIdsxB75pKEdAx3m8yShTqsZzMeS3VCyMwsci4G8ly2Ql
6WOFyOZw81BvhnF0UWSOhbqPiZQgXhxymjzz8FPSKjyLCJwOFKwb0sbJgamEihw9
sWrP8ZLee4fezT9QeiwzvslhESFd94nfNajPNSiNnLYjo/4x1Wo/ulpUcNQPVQhk
KNdYET1qD9EG/AcvqamW
=qoFo
-----END PGP SIGNATURE-----