Re: [Enigmail] [ANN] Enigmail v1.7.2 Available

[Nicolai Josuttis (enigmail)]

Strange.
Does it even happen if the person without encryption
is the only one recipient?
Because it is enough to have just one rule that forces encryption.
If that's the case, remove the rule.

Hope that helps
 Nico

Am 29.08.2014 22:09, Alexander Buchner schrieb/wrote:
> On 29.08.2014 20:51, Nicolai Josuttis (enigmail) wrote:
>> Hi Alexander,
>> 
>> what you want should be easy to reach: - Tab sending: Turn on
>> convenience mode - Tab Key selection: Turn on the first three
>> items (all except "always manually")
>> 
>> Then whenever keys for all recipients exist, the email
>> automatically gets encrypted (unless recipient rules say not to
>> do so).
>> 
>> All other emails are not automatically encrypted (unless
>> recipient rules force encryption).
>> 
>> If rules force encryption or you explicitly forces it (by
>> clicking on the key symbol) and keys are missing, the key
>> selection dialog will pop-up to give you the ability to choose
>> the missing keys (or disable sending/encryption).
>> 
>> Hope this helps Nico
> 
> Hi Nico,
> 
> thank you for your advice. Unfortunately your recommended settings
> don't work for me.
> 
> What I just now tested:
> 
> 1
> 
> - Tab sending: Turn on convenience mode - Tab Key selection: Turn
> on the first three items (all except "always manually")
> 
> Result: When sending mail to person who doesn't use encryption --> 
> Dialog "Enigmail Key Selection" pops up.
> 
> 2 - Tab sending: Turn on convenience mode - Tab Key selection: Turn
> on the first two items
> 
> Result: When sending mail to person who doesn't use encryption --> 
> Dialog "Enigmail Key Selection" pops up.
> 
> Can somebody else confirm this with 1.7.2 or am I the only one
> with problems here?
> 
> 
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
-- 
Nicolai M. Josuttis
www.josuttis.de
PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] [ANN] Enigmail v1.7.2 Available

[Nicolai Josuttis (enigmail)]

Hi Alexander,

what you want should be easy to reach:
- Tab sending:
  Turn on convenience mode
- Tab Key selection:
  Turn on the first three items
  (all except "always manually")

Then whenever keys for all recipients exist,
the email automatically gets encrypted
(unless recipient rules say not to do so).

All other emails are not automatically encrypted
(unless recipient rules force encryption).

If rules force encryption or you explicitly
forces it (by clicking on the key symbol)
and keys are missing, the key selection dialog will pop-up
to give you the ability to choose the missing keys
(or disable sending/encryption).

Hope this helps
 Nico


Am 29.08.2014 20:33, Alexander Buchner schrieb/wrote:
> On 29.08.2014 19:19, Olav Seyfarth wrote:
>> Hi Alexander,
>>
>>> The update overwrote my preferences again and activated the "convenient 
>>> encryption settings" without a warning.
>>
>> I use the attached settings and installing 1.7.2 did not change any settings.
>> I'll try to reproduce this by creating a new profile and installing 1.6, 1.7
>> and 1.7.2 in that order. How were your prefs in 1.6?
>>
>>> My preferences were 1. enrypt if I have a public key for the recipient (or
>>> a rule) and 2. don't encrypt if 1 isn't true without the "Enigmail Key
>>> Selection" window. I did this by deactivating "Key Selection: Manually if
>>> Keys are Missing". Is this still possible? At least it doesn't work the
>>> same way as with version 1.7.
>>
>> Yes, I do the same. Indeed, I think, that's what most people want/should set.
>> Attached are my settings. With them, I think you get what you describe above
>> or did I miss something?
>>
>> I think I never tried to send a message with attached images (tiny!) to the
>> list. I don't know whether they are stripped or not, we'll see. If so, I'll
>> put them on my website for a while and send links.
>>
>> Olav
> 
> Hm, I'm really confused right now.
> 
> What I want: After hitting "Send" I don't want to see any further dialog
> for missing keys etc... just encrypt it or don't encrypt it.
> 
> And you say you achieve this behavior by setting "Confirm before
> sending" to "Always"?! That would really astonish me?!
> For me it's: "Never"
> 
> Also setting "Key Selection" to "Manually if Keys are Missing" is not
> what I want.
> 
> Either we both talk about two different things or something really weird
> is happening for me?!
> 
> Alexander
> 
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Enigmail 1.7.1?

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,
thanks for the request.

Yes, we didn't have a 1.6.1.
The changes for 1.6.0 were so much that we called the new version 1.7.0.

Now, for 1.7.0 we just have fixes for two releases:
- - In the near future there will be 1.7.1,
  which will combine some important bug fixes
  for all the changes of 1.7.0
  without new (major) features.
  It will probably be out during the next couple of week(s), we assume
  (depending on how many serious bug reports we get).
- - The next major release shall be 1.8.0,
  which will be the next major version (don't know when).
  This version is what is currently available as nightly builts
  at https://www.enigmail.net/download/nightly.php

So, yes, "coder talk" or just working titles
for upcoming versions to give people an idea
when fixes will be available.

Hope this helps.
Best
 Nico

Am 28.07.2014 21:12, David schrieb/wrote:
> When the Enigmail release was 1.6 and bugs were fixed it was said
> 
> "fixed with 1.6.1 and 1.7.0"
> 
> Now I see "fixed with 1.7.1 and 1.8.0"
> 
> I never did see an Enigmail 1.6.1. And I do not see an Enigmail
> 1.7.1.
> 
> Is this just 'coder talk' for 'later in a future release'?
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 


- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJT1qmEAAoJEBwWpwr5LSj1jt8P/2dROodElHndPXvCLzZ+DT5a
X1BGFM0W1hfmPVL+6aCQQQkw8GSFbl4lcf+wMK6a/diyH+a+0wrfMYFibOWlHouZ
9NuiTrRHoqFICN3anRTitBCpelHP1e1w6Zm5Cig1zcQ7FuDgDMS+d6wpLEY6AIFt
kOWzdnzP3sJaKBiZoQswZIjoyfFP2GYzKIqcrenIXhWsuPhX7mGRn/lP+b7XuKJp
4Ff2d/bva9op0ranDE1A/MGuTMaF7xWKrZR4Yg4PxiqG5UYeWtCgzC8w8ieiqLZ5
5pWa39BdeDUUL3kqrfNS9ai/0dclQSg18Xpbm4UtKMpjaFfwxaSk7DMqijAlhT8s
c+iRrPE8p2lJTHi5ZR31lLovMR7l+wEdL+npmkucHiehlmjJ0g55uJl+rKwSpvlq
qoA/ogrL4N/kZPnoppCXD3vFcOk63tczWHlJCdmI1pfTKpqCOUHvJZrsPv4HAxb6
FtbyZcYcYoqKGnQHUqj0sFo4Qcof4MCqPB6EP2jx+j3pvl4+uJCYXStNK1HCQ9KE
MjvsLWEgX/twHLZ7DyJVxw5GIQL8DowfiWBC6/DAHs4c0e5Hm/SBm+cr8ORKg0LK
cAJVy9NoLRyzU43sDdZ9PuhgFgQpDLFqAZcff5/vUDGDJwIJFh7uQWmMW2jssHWC
oB7vGAOKBWO7cPTGmMFq
=1x0t
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] last chance to beta test the upcoming version 1.7

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

don't know.
May be Patrick has time to do it.
I am about to leave for vacation
(and I need it after 6 months of Enigmail in all my spare time).

 Nico

Am 08.07.2014 00:07, Daniel Kahn Gillmor schrieb/wrote:
> On 07/07/2014 06:01 PM, Nicolai Josuttis (enigmail) wrote:
>> OK, thanks a lot. We added a warning dialog for those switching
>> to 1.7
> 
> yep, i did see the warning dialog.
> 
>> to double check preferences because we assumed that there are
>> issues. Although we didn't THAT issue. Too much changes there
>> 
> 
> is this something fixable before the release?
> 
> --dkg
> 
> 
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTux86AAoJEBwWpwr5LSj1aeoP/A6fIwo4hABiqce0iOEOexXA
NXN/50XD7lRE8XgC9akYe3kJu0b5VQGZPOk75k2w+KGrfD06AhZ9VTuSVYr9eUhr
TJoMViV0pvxRRJbu88W1anH18jYfhj8uLW6Ovgyb3phVeA/sR1C9FoAwdWClXLC5
KUunXHGG+rQWkaz6fuJf0Cc1gKUX+HsxATaVIr0p7nqTKsYVp9Cd1bj3R/cCYzEd
QfivzI52ej0GvVi3bHKxNF35HHKOmg7zD+ex8m7yhfp7t2hCBPnw4FjuJXBc1TX9
9Zp0FeFV4b0Ows7QgDD0lM4mIw0PeLcJ0KkIxwZh3wVN9Xig1ZK95fr90MDqJPxH
HNJkBUdqBLeMYAd5ORAfwWncUedgwSn+DyqL2ZdggOr6YGbRwTx+gPKIfnZH42EY
3a4+zDba8hQ1ARAPn+QHUu1Iu9+BzLiUI+RTyZywaqd+SRpF/Yej2txV3CO/K6Fh
XL/5aoqRey7WFn7UJ/J4qUIE90kYyDKE7DEk9N4fjJUHHGCfB92zyMPr9lpLk8t9
R+BGptX503r1lr6ShxTHaCbAFgsGoW0qeJa69Vm/ckUHmWkS85KeOifbqXXg7jL7
awWiklrYixTCNjeP5ZOMNWjhK32l7bUVzp+g/GmqqYu0bdetxuwWypaPk7kiXKRp
GF+bmiO0FOioVcunY5AY
=tZ7B
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] last chance to beta test the upcoming version 1.7

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OK, thanks a lot.
We added a warning dialog for those switching to 1.7
to double check preferences
because we assumed that there are issues.
Although we didn't THAT issue.
Too much changes there 

Best
Nico


Am 07.07.2014 23:54, Daniel Kahn Gillmor schrieb/wrote:
> On 07/06/2014 03:57 PM, Nicolai Josuttis (enigmail) wrote:
> 
>> after several months and a huge amount of updates, Enigmail 
>> version 1.7 is close to be delivered. While we still process all
>>  the translations, the code and behavior should be done now.
>> 
>> As we fixed a couple of bugs recently, we are looking for final 
>> testers before everything gets freezed on Tuesday. Thus, for 
>> those who have time to test enigmail, please do so on Monday and
>>  send us detected bugs ASAP (especially if these are significant
>>  bugs).
> 
> thanks, i've gone ahead and uploaded a beta built from git commit 
> af19e586642d into debian's experimental repository, so folks who 
> are running debian can try fetching and testing from there.
> 
> I noticed that when i built it, unused.txt was created with the 
> following content:
> 
> --- unused labels: enigmail.alwaysTrustSend.label 
> enigmail.disableRules.accesskey enigmail.disableRules.label 
> enigmail.encryptedsend.label enigmail.openpgp.label 
> enigmail.sendPGPMime.label enigmail.setupWiz.details.subtitle 
> enigmail.setupWiz.pgSign.noSign
> enigmail.setupWiz.pgSign.signAllMsg 
> enigmail.setupWiz.pgSign.yesSign enigmail.signedsend.label
> 
> unused properties: keyValid.valid ---
> 
> Also, i notice that when i start composing a message, the message 
> will be signed by default (That is, Sign messages by default used 
> to be checked for me).  looking at the preferences now, it looks 
> like it is unchecked, but new messages are still signed by default.
> however, if i switch to "force sign", and then go back to "Use
> Defaults for Signing", the message switches to "Message will not be
> signed".
> 
> When i check the preference checkbox manually (Enigmail > 
> Preferences > Signing/Encryption Options?), then the "Use Defaults
>  for Signing" behaves as expected.
> 
> So i suspect that something about that preference didn't get 
> transferred properly.
> 
> Thanks for all your work on this.
> 
> --dkg
> 
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net To unsubscribe or make 
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
>
> 
- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuxjGAAoJEBwWpwr5LSj1MGoQAJgFOjAN2GMeRDQ5zwG1eLYP
2uNWOYSaqUc9ZwbwgsAdC400+JbOM69OWPZEcyvXGrPuWz0VHQS+6+g5zERCb/i0
7sdVIFrhYehdTU0zxVz3bZy10vlEVbj5Qclh6UKcWKEKMVke6YMIEln1rbfiO6T0
jyNZy1xTVXMbHEHGvq2i/lDWN4o4UZcXFReD6WRrpJeOPODaOh1KSIdleSw1n+Mb
fY9mrrVdWLBxV8PqOF4Y5qnlFOQTzwrraoR2X6sM2DuZc3f4VwQaho/4BGL0FQQ3
v0yTvCVrBeCWRaUJkrihJ1DdPVlf6XNeQQHJeCzVuFbRKDzpkr72Cajhg/wMujGz
JYH0kF7dXO3M7oh3oGGpNkmlLfHy33zqs1givnZjrb6j2guX1NtT5uiQ7hDcII3W
xtEOutB0liqpbWw+6BtSGtKt16ECz2wxPVGe5EMwqGH7fanhSZ0maX167M6ZCZyb
3cxFqEB6ESNLYDmnY329BjQjc4YqkqnpJYx8x/oUmEmvVGb+VSreU2XpuvtLI/Vl
zlHThPeyA9+UhZSu314/lKUWyXpopZV3C2rLkaoRWKXik31/TMFFkO1L7tDcIlGF
EWGB/VRr0JpPRjHkQkTI1Dym0w61sXMpA54OZVRJvUufy7CY0rM9TaRf9QMNrYvP
KTGGr0vOXU4FT7O0KgFR
=J4Tm
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] last chance to beta test the upcoming version 1.7

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OK, thanks a lot.
We added a warning dialog for those switching to 1.7
to double check preferences
because we assumed that there are issues.
Although we didn't THAT issue.
Too much changes there 

Best
 Nico


Am 07.07.2014 23:54, Daniel Kahn Gillmor schrieb/wrote:
> On 07/06/2014 03:57 PM, Nicolai Josuttis (enigmail) wrote:
> 
>> after several months and a huge amount of updates, Enigmail 
>> version 1.7 is close to be delivered. While we still process all 
>> the translations, the code and behavior should be done now.
>> 
>> As we fixed a couple of bugs recently, we are looking for final 
>> testers before everything gets freezed on Tuesday. Thus, for 
>> those who have time to test enigmail, please do so on Monday and 
>> send us detected bugs ASAP (especially if these are significant 
>> bugs).
> 
> thanks, i've gone ahead and uploaded a beta built from git commit 
> af19e586642d into debian's experimental repository, so folks who 
> are running debian can try fetching and testing from there.
> 
> I noticed that when i built it, unused.txt was created with the 
> following content:
> 
> --- unused labels: enigmail.alwaysTrustSend.label 
> enigmail.disableRules.accesskey enigmail.disableRules.label 
> enigmail.encryptedsend.label enigmail.openpgp.label 
> enigmail.sendPGPMime.label enigmail.setupWiz.details.subtitle 
> enigmail.setupWiz.pgSign.noSign enigmail.setupWiz.pgSign.signAllMsg
>  enigmail.setupWiz.pgSign.yesSign enigmail.signedsend.label
> 
> unused properties: keyValid.valid ---
> 
> Also, i notice that when i start composing a message, the message 
> will be signed by default (That is, Sign messages by default used 
> to be checked for me).  looking at the preferences now, it looks 
> like it is unchecked, but new messages are still signed by
> default. however, if i switch to "force sign", and then go back to
> "Use Defaults for Signing", the message switches to "Message will
> not be signed".
> 
> When i check the preference checkbox manually (Enigmail > 
> Preferences > Signing/Encryption Options?), then the "Use Defaults 
> for Signing" behaves as expected.
> 
> So i suspect that something about that preference didn't get 
> transferred properly.
> 
> Thanks for all your work on this.
> 
> --dkg
> 
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net To unsubscribe or make 
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuxiyAAoJEBwWpwr5LSj1CH8QAKOenyJ8bX7IvsHSgDticDLa
8iA6nT1oDkM5VzwbvEsxh76GhpsvywFvJl3TNWDgrs5rxBtzq12cTbAVLnId/aaZ
p7OYtxb4FfVPEmGw6jZ+8d9Y5FvQnzCrVLgw2OT1pwSGMnGUAG7DCzVvp3bTvzX7
PYGji6hJfudg970mJflGdbbjGzikpXxGg7k1/2xagYfLPH9gPMggl5r0CYFmy6mg
xhh1eZYStw4FfIfUZYrH+6KUpm+UBGjigEJtoSGsYM/8eZhd6KQvgaFpxLKPlqz7
UNTdNUmibEZ2iDcMaZWfvDsAQzRG+2LaTduy+/qQy2PGaaeBl68ZAnIj32ieaeeg
UVkDp7AQCGn5EN4aQpI1rFChOH83JVoZDx5GWUGMefZLqiZnTTSX1O3aUc/zpHqE
kDYkrZlu9UjVmiuL3U2TQaJBlkqK5NYcW1tzvCHPFdwsx0lF1EaMCVK3btV5M6lu
d/bKw/EMocgG3bfMYdM8idfznO4mVGgDxke8eahShrWmTSp4KnpPNCoYRGijREYy
gU/4k3T/6qb0xKCLTL1yDoO1bKONePDfB0BmxiJk4iyTWYOAWRoh+eIINzVLAWNX
olZjhe9HvqatOYzBVb/vM+bsOm7aFP8YrSgN2Usqrf7vimPD5/1ECmIJpl3dM8/g
Fb3QbiwLeC9WYSHkMyfh
=trdR
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] last chance to beta test the upcoming version 1.7

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

after several months and a huge amount of updates,
Enigmail version 1.7 is close to be delivered.
While we still process all the translations,
the code and behavior should be done now.

As we fixed a couple of bugs recently, we are looking
for final testers before everything gets freezed on Tuesday.
Thus, for those who have time to test enigmail,
please do so on Monday and send us detected bugs ASAP
(especially if these are significant bugs).

All you have to do to test this version is:
> - DOWNLOAD the file enigmail-nightly-all.xpi 
> https://www.enigmail.net/download/nightly/enigmail-nightly-all.xpi 
> into a local file (don't load it directly into your firefox
> browser) - In Thunderbird choose Extras -> Add-Ons-Manager and
> select the configure icon on the upper right -> install Add-On from
> file and select the stored file - press install now - restart
> thunderbird

And, yes, we have changed a lot, which might look surprising at first)
mainly to focus on "John Doe"; that is not to overwhelm newbies by too
much details.
For this, especially in non-expert-mode menus, icons,
and preferences were highly simplified,
while at least in expert mode, you still should be able
to do everything as with v1.6.

Happy testing and
THANKS A LOT FOR ALL YOUR SUPPORT
 Nico

- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuaoUAAoJEN75/ICKHETQdvkP/2nRzncQqwmCLTejeyXoZ96u
UJ7K1o7ufKpiBocGHfe6RpWVmA7NJb0HBkJwHpzOt5x9j+H+TsYTDboe/guIGhsP
BGtd+8bHKoFCYPrOvpWjFGxdFiRzWizbR/bnOtv28YSqFo1t/oiP8fe1CRS1gUNK
QwU7BXE9I/syp1Y69OnJg1fzpxpTWwPoICd/2IzWA71gsvF9vCrLoJYcVPPJxTnR
rkfi7lX5YhDCsVPYOa4YvY6fEIz4tBUcABg5c4WwGIgIHURJ7IO6OOwE4o+ix2VR
xMgfR9zQptqt6nvY9SH/qdshobYUVK43Z32/uWg6Xqa7X0koc+Is70pq8QBlMfwp
GpRLma1QqmZKkpB+YSEwfDRfKekzWYfmWlWttgEfSlBstAwnwzmLpNiJrPuNdmOT
VU5N7MPBH5uYug0yUYJbRo6uSeYIQbRtyuAKHkcDFwfujaklfuHbNnbGLEfh6XJo
muJcs237U9UdmhLlkqIKKZyGYcxb/RNqsOA12tnCw6ArRxYEr/gLLo+S84tm8sEU
azY7qOgV7afWn9pz/fFLlqyG+iUGnnnU4bpwwQp3c2XipOaA0axNgntEXJkqZGTj
h8NzvbZGxSUn9Dm2l4w/srfkuy4S3oula1kcJZ7siwlyR3xKyZeX3YxlTDtpi0/q
kiaffk0/xR0SyH6rR6GN
=pjBM
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] sign message and attachment

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ah,
may be, that should become a non-expert button ...

Am 06.07.2014 18:42, Ludwig Hügelschäfer schrieb/wrote:
> 
> On 06.07.14 18:23, Nicolai Josuttis (enigmail) wrote:
>> extensions.enigmail.encryptAttachmentsSkipDlg
> 
>> May be, we should add a button to "un-remember" all choices ...
> 
> It's already there: OpenPGP -> Preferences, Display Expert
> Settings and Menues. Select "Advanced Tab", click on "Reset
> Warnings" button.
> 
> Ludwig
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net To unsubscribe or make 
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuYqTAAoJEBwWpwr5LSj1mNcP/ipWYU5gtQ4usMPsIPnRAG0v
zJ958cQ3MIQ+WPf5JD4Rm/K5oj0tgYvC9/mUbKuzvE+df169BLIkv8H7+hfqMpjD
X81jJu6o5RcFyb9tr784ceFWKUwgnrq1MLsBd/+a/mKLZsOvYWrQFwmtYcN0/bLq
edBiEPjJainICgg60r+Q8XIUhXkOsYB/6e/Fz0XCkaAo+k5NEpVGjuvc3p5aTVFU
LsaAeTsjNOx4rH+pEwcmVdHILhrGDGg/+PpzRNYeMuyFV61R/+9ZDl/CDPZyJFeq
5gYoiq6GzUpP2xqB7xbHYRlO7hElGyDp8kwaCvtjRmwjLvNoroFX0dZ2bzNcb2zz
Mx3WUlcQASuvPQ4J0lk+CdqpRAJ9B+zB/OwwH5jW7Vs3JT0Kwz2tCs+ceYnd1+4N
UY1DCDdEjpRPn2uHaAPFIU1kN+F9qAQB7xpy0LdVRAFBPEnZTRGujvdTqVVzL/le
ookAVwxyMaqygnXSPaNEdV/g1AKxeoQIrO+Qzbv53+jrbhyv1dnLWWs7b/E2Zl43
JI2cSEcsWeC1TpKWZ7P+/Mtpfa1gXuMxg6ncYk0j9peH7LoHYbzRUigoay2gd9An
2YkblmP0/HCt7L1eyoszqSpG55Q58zMe98nA/+pd10TyO+LhOFnwyctnUBqEW3Dj
AE2X3H6XOhzmFLbc4hig
=siXi
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] sign message and attachment

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

extensions.enigmail.encryptAttachmentsSkipDlg

May be, we should add a button to "un-remember" all choices ...

Best
 Nico

Am 06.07.2014 18:12, David schrieb/wrote:
> When sending a email that is to be signed *and* with an attachment
> there is a popup that asks how you wish to handle the attachment.
> Sign? Don't sign? And it offers to 'remember' your choice.
> 
> The only way that I know to change this 'remember' setting is to
> edit a line in prefs.js.
> 
> I forget the wording. Would someone please remind me?
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de
PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuXfiAAoJEBwWpwr5LSj1VX4P+wZklzalsZsa9CGv7kKTGz5z
/XDjAmOI5Tf+geSP/j7MMEbCSLDkWeO9NyBO5C8lliTopWYFd2IqyPpVgzzIZ64M
KasWMCbOuc2beD/g5B19TiFnoxGcLlQoxDoCsUyBOVTSjFSyZE5fIwOyRy+XYIbM
ujAn8o+NiGhEf2Hd6FEIJG+aZByHJieiUK6UvV92oC5VpWhdy7hbGSL7ipe+AHkt
0nA4/ODXt2QWXN+bxKB4JAOd9Lh1/3sPzHpzQa+d211PHJhUR9uZpJsbsbum9bjU
eSmlTy1jFRp2qewcKj6n7w3IzDrFnP0tgE3CyYixOX6RAGVknvvuCzdNNncLVwct
FCrKe1hZAMzZ7I2muOjeNdoGZA7L6JvG5Cpv61tnVK1rmlxK+O3nbzXeaUPyAR6F
cr11THZlOvcHG1hkEq0Fg/yrE0s+EYLKKFB1Ig/CWiouRECa+iSJvmHovgQCZr22
HpjY2uF49dZuQZ35CMmFe2aFq4HPi/pguL4wP4HDDNF1xpDVdOaSGw4bL8MUEjN2
iWCLYYCbfKRDlgbd0DPEpIc+3Br1BhoUMwBAtKU2hhNe6l6Dq+0XHfsnE1gYo6qK
iguwJwUdMwxmKG2+rstfDz5Rj0xmtkxGrIr9JtfcpKAQEUOwt3mVirZQWX1M/bWM
+iXjSj0X2CZTtD+Vxu09
=Za4L
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Request for Translation

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Onno,

very good point.
Thanks for this feedback.
We will add a check for the next version to avoid this in future.

As far as I know this applies to the following labels:
> ui/locale/en-US/enigmail.properties:usingAgent= 
> ui/locale/en-US/enigmail.properties:offlineSave= 
> ui/locale/en-US/enigmail.properties:onlineSend= 
> ui/locale/en-US/enigmail.properties:sc.wrongCardAvailable= 
> ui/locale/en-US/enigmail.properties:keyAndSigDate= 
> ui/locale/en-US/enigmail.properties:noEncryption= 
> ui/locale/en-US/enigmail.properties:addKeyToRule= 
> ui/locale/en-US/enigmail.properties:specificPubKeyFilename= 
> ui/locale/en-US/enigmail.properties:specificPubSecKeyFilename=

Fortunately, none of these labels is new with v1.7.
Thus, we didn't make the problem worse. ;-)

Best
 Nico


Am 04.07.2014 14:57, Onno Ekker schrieb/wrote:
> One more thing :-)
> 
> In enigmail.properties i see several strings with more
> placeholders (e.g. offlineSave"Save %S message to %S in Unsent
> Messages folder?"). I think you should use %1s and %2s here,
> because the order in which the two arguments are may vary from
> language to language. See also this page for reference: 
> 
>
>
> 
Please keep in mind that in order for all localizers to
> check/change such strings you shouldn't change the string itself, 
> but rather add a new string like offlineSave2 in this case.
> 
> Onno
> 
> 
> 
> On Fri, Jul 4, 2014 at 2:30 PM, António Manuel Dias 
> mailto:ammd...@gmail.com>> wrote:
> 
> Hello.
> 
> On Fri, Jul 4, 2014 at 1:24 PM, Onno Ekker  > wrote:
> 
> It would also be nice if you give the labels and accesskeys the 
> same name. For instance, now there's a label called 
> enigmail.keyMan.keyProps.label with accesskey called 
> enigmail.keyMan.keyDetails.accesskey. This makes it very hard to 
> find the correct accesskey, because you first have to find the xul 
> file where it is used.
> 
> Structuring the dtd and properties files so that label and 
> accesskey are together would also be nice, because that way you
> can see at a glance that the accesskey is in the label and you
> only have to worry about choosing unique accesskeys...
> 
> 
> I second this proposal.  It can be very hard to choose the right 
> access keys, not knowing to which label they correspond and also 
> what access keys are already used in the corresponding context 
> (dialog, menu).
> 
> Best regards,
> 
> -- António Manuel Dias
> 
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net 
>  To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
> 
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net To unsubscribe or make 
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
- -- 
Nicolai M. Josuttis
www.josuttis.de
PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net



- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuTgrAAoJEBwWpwr5LSj17fwP/1aqlNfm5E9bqBBX4B+1yOsm
RAv1vUyudI3DGVzXUyvaXNWMK8QgQ2fBv74BonclmdTHTVGbRDN4fIoeylzC3HJ9
qAccubNAuChokD/BptHCH8G7Wd47Cv/DVK0C4ILpSb7WQJz9RdmyjV2xj41i6B/r
3AtElqDVIVV6w/lQwcETcYWQjitI4jYZCUiQnjLkRFz0upN9jA1dExbnt3AhevXs
+5+LSaUyqft6oVT6p5rMF0X71NwmR8Z7Pm5pu/uP+ILWO1PkgFB+PC6ZEKCIc/t1
S+vtPcLvNrLZiAJYLt9szserXvtjhsVLCV4SbmLMbWQR4QWF2WzXu62OSadFFGbj
c8FKxq9evEKMyBM9asoOSk0m1jNWznJybYFp+IhHDKYXSKSqEBtaNGK09LwmlBmE
KIgdaobECCDTBFnrJWdLrePdSR7rxOaISZZU8TwvF1Fm4GZjktm+nD8zQKRpg1rq
KZzyuzWb+TqoNF8UGuSJzVG0m9Go+UsZBPQ3wreZHrm8b2LwBIifL3A9P956Pa4M
WQBW7wdeTToIGx5L+eeSZmgMAsEMvBStab4T+94MTEsHqmlnTePUfJlqqeAK2Dze
odfKWzfhBHNS4b6JW33rYsNSu4z5uhvXUa5usI0C0F6PXZf0g1V8Y2BXdMjfDJhh
0CKbxqexNpyILwudN6Ez
=Q6OL
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Request for Translation

[Nicolai Josuttis]

Hi Onno,

very good point.
Thanks for this feedback.
We will add a check for the next version to avoid this in future.

As far as I know this applies to the following labels:
> ui/locale/en-US/enigmail.properties:usingAgent=Using %S executable %S to 
> encrypt and decrypt
> ui/locale/en-US/enigmail.properties:offlineSave=Save %S message to %S in 
> Unsent Messages folder?
> ui/locale/en-US/enigmail.properties:onlineSend=Send %S message to %S?
> ui/locale/en-US/enigmail.properties:sc.wrongCardAvailable=The SmartCard %S 
> found in your reader cannot be used to process the message.\nPlease insert 
> your SmartCard %S and repeat the opera
> ui/locale/en-US/enigmail.properties:keyAndSigDate=Key ID: 0x%S / Signed on: %S
> ui/locale/en-US/enigmail.properties:noEncryption=You have activated 
> encryption, but you did not select a key. In order to encrypt mails sent to 
> %S, you need to specify one or several valid
> ui/locale/en-US/enigmail.properties:addKeyToRule=Add key %S (%S) to 
> per-recipient rule
> ui/locale/en-US/enigmail.properties:specificPubKeyFilename=%S (0x%S) pub
> ui/locale/en-US/enigmail.properties:specificPubSecKeyFilename=%

Fortunately, none of these labels is new with v1.7.
Thus, we didn't make the problem worse. ;-)

Best
 Nico


Am 04.07.2014 14:57, Onno Ekker schrieb/wrote:
> One more thing :-)
> 
> In enigmail.properties i see several strings with more placeholders (e.g.
> offlineSave"Save %S message to %S in Unsent Messages folder?"). I think
> you should use %1s and %2s here, because the order in which the two
> arguments are may vary from language to language. See also this page for
> reference:
> 
> 
> Please keep in mind that in order for all localizers to check/change
> such strings you shouldn't change the string itself, but rather add a
> new string like offlineSave2 in this case.
> 
> Onno
> 
> 
> 
> On Fri, Jul 4, 2014 at 2:30 PM, António Manuel Dias  > wrote:
> 
> Hello.
> 
> On Fri, Jul 4, 2014 at 1:24 PM, Onno Ekker  > wrote:
> 
> It would also be nice if you give the labels and accesskeys the
> same name. For instance, now there's a label called
> enigmail.keyMan.keyProps.label with accesskey called
> enigmail.keyMan.keyDetails.accesskey. This makes it very hard to
> find the correct accesskey, because you first have to find the
> xul file where it is used.
> 
> Structuring the dtd and properties files so that label and
> accesskey are together would also be nice, because that way you
> can see at a glance that the accesskey is in the label and you
> only have to worry about choosing unique accesskeys...
> 
> 
> I second this proposal.  It can be very hard to choose the right
> access keys, not knowing to which label they correspond and also
> what access keys are already used in the corresponding context
> (dialog, menu).
> 
> Best regards,
> 
> -- 
> António Manuel Dias
> 
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net 
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 

-- 
Nicolai M. Josuttis
www.josuttis.de
PGP Fingerprint: EA25 EF48 BF20 01E4 1FAB 0C1C DEF9 FC80 8A1C 44D0

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Request for Translation

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

thanks for this feedback.

As a programmer I fully agree.
We (programmers and translators) have the same goal here,
because the current mess is a problem for programming and
maintenance of the code.

We didn't though have enough time to clean things up for 1.7.
Sorry for that.

I promise that it will become better.

Best
 Nico


Am 04.07.2014 14:30, António Manuel Dias schrieb/wrote:
> Hello.
> 
> On Fri, Jul 4, 2014 at 1:24 PM, Onno Ekker  > wrote:
> 
> It would also be nice if you give the labels and accesskeys the
> same name. For instance, now there's a label called 
> enigmail.keyMan.keyProps.label with accesskey called 
> enigmail.keyMan.keyDetails.accesskey. This makes it very hard to 
> find the correct accesskey, because you first have to find the xul 
> file where it is used.
> 
> Structuring the dtd and properties files so that label and
> accesskey are together would also be nice, because that way you can
> see at a glance that the accesskey is in the label and you only
> have to worry about choosing unique accesskeys...
> 
> 
> I second this proposal.  It can be very hard to choose the right
> access keys, not knowing to which label they correspond and also
> what access keys are already used in the corresponding context
> (dialog, menu).
> 
> Best regards,
> 
> -- António Manuel Dias
> 
> 
> 
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net To unsubscribe or make
> changes to your subscription click here: 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTuSqYAAoJEBwWpwr5LSj1R1UP+gJDAzNUDGe7dw6FlsHvPz1N
Laq3CisEot/Y+kILMJmqhSXJRuyPg9MpOdUBLOqqs7i/pUVkqmlHi/RlggBmz1qy
8F5moVSI1ADaTDKfLSgyvMN+eoxIAOog1EG+CB1/eb0mNtDCITU0wSrMiVCXi3Jr
somxW3XdlX2hxlcCRbktOXqrCA0zV4aHcWo7sn/78W1utI5S4vKTDuJUp5gwt+9e
6/M50Q+zwwoO01LDbPyLIL7U/qjRDfnhtmAoraHFXRfsXJbWyK8rvJ8Rjkd+RLfj
v7ojcQrMdF39xY3GrhPAE/uktPlIkyb6qJpuNksLJ26jJEzpALENZ3RvFqw/1Lj1
VK2DO6L31r/5vx4ZxJTxNK6Zx8o+CJ5WkgfM3+9EhFLumZM4gQsNEry9eNmF1bq9
/+pcg6hY2Fof2MmtNLT7ExyVUSLcvy+Xu+EeRr6Yc9ZRBgnjW0gHK8cnli5ER1V7
QyipO5FNktPrFs6PCSt/YiOIu5L7G7E50eL52ri2HSlGocjZi3N8CBcn7bsIU/XR
VahjkgwLFdkV/TATTw+NyMizfQQYi2U/Pg07nf3VIVtgcI7zzBxqu3Rvf/hej+RC
607QPVTLh2SsGd65V7Auf1AgsFleEK53gOAF082PkXixZxGEVVPJa0Y3uUntTOs/
Fxpm20xIYiX925XFNU1l
=R60f
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Ubuntu uses old enigmail-Version

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

For what it's worth, I'd just like to let you know:
Enigmail Version 1.7, which will be a significant improvement
(especially regarding a convenient handling of encryption),
is around the corner.

Am 03.07.2014 10:50, Alexander Buchner schrieb/wrote:
> Hi,
> 
> if some people on this list use enigmail with Ubuntu, I would
> kindly ask them to support the following wish (bug report) for
> Ubuntu to update the package to a recent version: 
> https://bugs.launchpad.net/ubuntu/+source/enigmail/+bug/1296699
> 
> There is already a debian package for version 1.6, so I thought it
> would be easier to convince people to update the package in Ubuntu
> too.
> 
> Regards Alexander
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTtTbkAAoJEBwWpwr5LSj1WIwP/29a2vykFWErjmUghSvbj9Nd
eqD3Jd9dfWrYNiVzRhWyM6ANLLWdyq5IPMfrg5zbUQQWYHlMeqLqAAzt8M9hglia
a85AoZRUSOwaKtFof6OLtq5EeNbl8NkU1avzs79Ec3bX5e/Hzsycta6pY8Pu+uDI
F4nfSrz/y287uNpUxR9UoRs2gDb8iAwBkmMkYbxb3SzF+u3yh2JhoAMhg5CqkZLy
dJWWEqBsgLlb6jbkiCx2ODE2qyZkeZCUTDhJ3yHg5+05Wlgwkt0drdTD1pKoZN4q
aBEettzthvfySm6bShLfi1NtmXypF8JDzl4dRTHmjGU46Hnktgt8EQsB/GQjKlrg
yBDAb++zZCta7tBn1JiNg9cssZHxnxTKYhBdcgK68qDtnssewXmRmtyQ5RnVAXE3
Zd9JSWkifGXOeAWiyXscpryxbMg7oS09oYWI8nLL5DQlV1+ehfKPno3nxi0ZcWC4
RLlzSVVYu0zIdgMZN6lOk7b/GE7N1mwmNh8eJPhy1deYWlf9ofB9FTTDwBdBNShK
BxvOSzK5JqUTp10gDyG/9q+uZJ9vBbralXXCVUBbVbTpORd9cJzk6bgStpQpLtCy
nXj87twrDfK2hvNe1NgR+TyhcIrmSdfuIzuxt3XVDQ+GQvzA6quOwyHEnvskiY9q
CCu0MHiH48NwpggsAtGg
=i+SG
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] new nightly built with several updates

[Nicolai Josuttis (enigmail)]

Am 16.06.2014 09:20, Kosuke Kaizuka schrieb/wrote:
>> I just fixed it and pushed it so that it should be in the next
>> master (in Monday or Tuesday).
> 
> Thanks, I understood.
> 
> https://sourceforge.net/p/enigmail/source/ci/7421a268856dac582c38e7e83d0318c9ca08c35c/
> No need to backout the changes for signYes and signNo?
> 
Oh yes, of course.
Changed SignYes and SignNo back.
Pushed into master.
Thanks a lot
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] new nightly built with several updates

[Nicolai Josuttis (enigmail)]

Hi Kosuke Kaizuka,
thanks for the quick feedback.

Am 15.06.2014 18:40, Kosuke Kaizuka schrieb/wrote:
> Hi Nicolai,
> 
> 
> Hi Nicolai,
> 
> I have tried Enigmail nightly 2014-06-15 with Thunderbird 31.0b1 on
> Win7, and new features seem to work fine.
> 
> During preparation of ja-JP localization on my local, I got several
> questions about locale files.
> 
> 1. enigmail.defaultSignPlainMsg.label is duplicated in enigmail.dtd
> line 220 and 228. Also, this entity seems not to be used at all.
> 
I didn't check which labels are no longer needed yet.

> 
> 2. What does %S in signYes and signNo in enigmail.properties stand
> for? Only "Message will be signed" or "Message will not be signed" is
> shown in compose window OpenPGP menu.
> 
> signYes=Message will be signed %S
> signNo=Message will not be signed %S
> 
Oops, I just saw that this is an old label I changed,
which I should not do.
I should have introduced a new label instead.
The new label will probably be:
 signYesWithOptionalDetails
 signNoWithOptionalDetails
and the meaning of the %S is to optionally place some details
about why the message is (not) signed.
The only supported detail for that is so far:
 signDueToEncryptionMode=(due to encryption mode)
So that a resulting message might be:
 Message will be signed (due to encryption mode)
There might be more details come sooner or later
(to better explain resulting signing/encryption).

I just fixed it and mushed it so that it should be in the
next master (ion Monday or Tuesday).

Best
 Nico

> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 


-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] new nightly built with several updates

[Nicolai Josuttis (enigmail)]

Thanks Philip,

That's exactly the kind of feedback I wanted to have
to fix final flaws.

Please allow me to look at details later (currently traveling)
and may be I ask for details then personally.

Best
 Nico

Am 15.06.2014 14:06, Philip Jackson schrieb/wrote:
> Hi Nico,
> 
> Looks good at first glance.  Time will tell how it performs.
> 
> 
> On 15/06/14 09:49, Nicolai Josuttis (enigmail) wrote:
> 
>> - In the account specific menu you can now select the
>>   general defaults for signing/encryption/pgpmime
>>   - The decision to automatically sign when the
>> email is (not) encrypted now is processed FINALLY
>> after applying all defaults/rules/manual-settings
>> It therefore has new labels.
> 
> I find this explanation a little difficult to understand but what I take from
> what you have written is the following :
> 
> In the account specific settings of Thunderbird, in the OpenPGP Options, if I
> select (tick) the check box 'Automatically sign finally non-encrypted 
> messages'
> this action will be applied as an final (ultimate) action after all other
> defaults/rules/manual settings have been applied.
> 
> So if all other actions work to declare that a particular email should not be
> signed, then this option will ensure that it is signed anyway.
> 
> But an initial test proves that it doesn't work that way.  If in the write
> window, I select OpenPGP/Message will be signed/Force not to sign :  then the
> message is sent unsigned.
> 
> So it seems that I have misunderstood your quoted text above.  Perhaps it is 
> the
> use of the word 'finally' that is ambiguous ?
> 
> Perhaps we could suggest something more clear if you say what message you
> intended to convey.
> 
> Best regards,
> Philip
> 
> ps.  for this message, it should be signed by default.  My initial attempt at
> clicking the send button produced an error "Bad pass phrase" "send failed".
> 
> I wasn't even invited to enter a passphrase.  So I have disabled signing to 
> get
> this message away.  I don't yet understand if this is an effect of the latest
> nightly build.
> 
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> To unsubscribe or make changes to your subscription click here:
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] new nightly built with several updates

[Nicolai Josuttis (enigmail)]

Hi all,

last night a new nightly build version of enigmail was built,
which contains several changes and fixes.

You can find it at:
 https://www.enigmail.net/download/nightly.php

To try it out:
- DOWNLOAD the file enigmail-nightly-all.xpi
   https://www.enigmail.net/download/nightly/enigmail-nightly-all.xpi
  INTO A LOCAL FILE
  (don't load it directly into your firefox browser)
- In Thunderbird choose
   Extras -> Add-Ons-Manager
  select the configure icon on the top right
   -> install Add-On from file
  and select the stored file
- press install now
- restart thunderbird

The changes are:

- New handling of default/rules/final-decisions
  for encryption/signing/pgp-mime
  - new account-defaults
  - new key selection properties
  - new compose menu entries (both pulldown and popup menues)
  - new status bar button icon look&feel
  See a summary of the new behavior below

- We have a workaround now to try to handle
  PGP/Mime emails screwed up by a Exchange Server <=2010.
  see https://sourceforge.net/p/enigmail/forum/support/thread/4add2b69/

To summarize how encryption/signing/pgpmime is handled now:
- In the account specific menu you can now select the
  general defaults for signing/encryption/pgpmime
  - The decision to automatically sign when the
email is (not) encrypted now is processed FINALLY
after applying all defaults/rules/manual-settings
It therefore has new labels.
  - Note: If no automatic signing is selected,
signing is not bundled to encryption
  - You now have a button there to jump to the global settings
- In the preferences -> key selection
  you can now simply turn on or off the possible steps
  of the key handling individually.
  This replaces a radio boy where you could only choose
  one of a couple of options, where the consequence were not
  always clear.
  The recommended default settings are:
  - use recipient-rules
  - use keys from key manager
  - start manual key selection if keys are missing
- With the status bar icons you can now FINALLY choose to
  sign/encrypt or not to sign/encrypt
  (which means after hitting these buttons,
   rules/defaults no longer count to decide whether to sign/encrypt,
   even if additional recipients are added while composing)
- With the compose menu entries you can do the same PLUS
  - see the current status of the email
  - switch back to process defaults and rules

I am happy about any feedback.

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] signing problem.

[Nicolai Josuttis (enigmail)]

Thanks,
question (also asked in the ticket):

>> I post an email to a person that is signed and encrypted. I select to
>> 'send-later' and the email goes to the Outbox. Signed and encrypted.
>> All is okay.
>> 
>> I 'edit' that message and change the To: line to send the same email
>> to someone else that is only to be signed. With 'send later' the

> What exactly do you mean by "I 'edit' that message"?
> Do you create a copy, which you move to the draft folder or what?

Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net


___
enigmail-users mailing list
enigmail-users@enigmail.net
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Video of my privacy & enigmail talk at NDC conference available

[Nicolai Josuttis (enigmail)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi "Suspekt",

thanks for the feedback.

the cryptographic experts warn strongly about using SHA1.
See for example Minute 31:30 of the following talk (in German):
 
http://media.ccc.de/browse/congress/2013/30C3_-_5337_-_de_-_saal_2_-_201312271715_-_kryptographie_nach_snowden_-_ruedi.html

The essence is "SHA1 is broken".
See also by the same author
 http://www.cryptolabs.org/hash/WeisCccDsHash05.html
The author offered the following bet in 2005(!):
 I would prefer to bet for Britney Spears being a virgin
 over the safety of SHA1
;-)

Without being an expert, that's seriously enough
strong warnings by experts I trust.

Best
 Nico

Am 09.06.2014 10:37, Suspekt schrieb/wrote:
> Hi Nicolai,
> 
> 
> Am 08.06.2014 18:21, schrieb Nicolai Josuttis:
>> Hi,
>> 
>> at http://vimeo.com/channels/ndc2014/97501375 you can find my
>> talk last week (June 5, 14)
> Hi Nicolai, some thoughts on you talk. First things first: I
> watched the video, liked it and it was really interesting. I
> believe at ~57:50 min you are a bit too harsh with SHA1. If I
> understand the SHA1 problems correct, then SHA1 has to be 
> considered cryptographically broken, but there is no reason to
> panic. That is because the attacks are rather theoretical than
> practical for now. Nevertheless we should move away from SHA1 so
> your recommendation to use SHA512 is reasonable I think.
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 


- -- 
Nicolai M. Josuttis
www.josuttis.de
mailto:n...@enigmail.net

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTlYoFAAoJEBwWpwr5LSj1X3kP/21f7kWlUOMwGUx4z2afbls8
I1Riup//zkuYlHzA1vunL59VWOAT0uEhxQDEILtuW20D3IxbaeOBIlAO4CP8q5wl
oz80A6n2cD8p+sIBFPGpoy5nvJQio5inNGAsPPRclkeS+00NRMXxQqsJOvhrh18t
1oLZPOId/7f1fuUHjJhvhLjNFKK3kD96ns4oXmcYLClvGHbM+lQ0fgn9WkOZj2WZ
uIRtgcWN43a0i54hqiNxjUw67oe+plKzIMkn9L1gH80g5FNOa8sR56h4DmH1u2Km
fnQPHCg8sVb7Gxi7M3TPyHtfpNRib7zw+QiTKsm+Cb6Zw+m9Eroau/TSDVryXPnK
8wohrgk0kt62envP7bPrdFZjj9V+632UniUl1k1Sa9O+1VpafknkixbIrSBRyM0T
S5DVCylYNMzEZHpE/LJHMUA2YoncymvmNSffpCyesXlZf7sVJv+DAFmATZYUzgzU
vZxJC35qte1sOrNBeII5QeRZm6Zrz+6qjCTj3owN8bXzgmUozJ/A8jcOB8c3sx0C
Iea8cG/1n6SSLeMqAOGBE3prUckEsoUhJOt+cieZn1WPvVtzN1voDVyOE2MhOKyd
at4yZKjlaZFN+qas/sH8Ol/HeqA2xgo8oktAKvhD9FX5E9JaVBoTf9gl6Xk5Aq+3
NHXJmGIzcTnlNNBfM0Hz
=L0G3
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] Video of my privacy & enigmail talk at NDC conference available

[Nicolai Josuttis]

Hi,

at
 http://vimeo.com/channels/ndc2014/97501375
you can find my talk last week (June 5, 14)
at NDC about:
- the motivation of privacy,
- how to deal with it in practice and
- enigmail as an example.

May be we should put a link t the enigmail website.

Enjoy
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de



___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] Video of my privacy & enigmail talk at NDC conference available

[Nicolai Josuttis]

Hi,

at
 http://vimeo.com/channels/ndc2014/97501375
you can find my talk last week (June 5th 14)
at NDC about
- the motivation of privacy,
- how to deal with it in practice and
- enigmail as an example.

May be we should put a link t the enigmail website.

Enjoy
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] on/off/default in a menu

[Nicolai Josuttis]

Hi,
all thanks a lot for the feedback.
That's very valuable feedback.
Let me answer some feedback using Olavs email.

Am 07.06.2014 21:06, Olav Seyfarth schrieb/wrote:
> is it necessary to be able to reset to defaults? It complicates things...
> 
Well, it's not a reset to the defaults;
it is a reset to the state an email would have without
having enabled the "finally forcing to sign/enc or not to sign/enc"
(therefore "use defaults and rules").

This reset is e.g. useful if I force encryption but then want to decide
to add other recipients and to see which state rules give.
As this is not the common case, it is not provided via the status bar icons.
But we could easily make it an advanced menu item.

> What's a default for in that situation (composing a new message)? In my 
> opinion:
> just to have a decent initial state. Nothing more. After sending, that what 
> was
> changed is irrelevant.
> 
after sending everything is irrelevant.
I am talking about the compose menu.

> Another thing that put me off: what IS the default? I use many accounts and to
> not recall on every account which settings I currently employ. Good UI design
> must enable the user to know what to expect from an action like "use default".
> _
> 
Note again I wrote "default & rules":
That implies now:
- initial default
- enc/sign cause due to a reply to an enc/sign email
- processed recipient rules
- auto encryption
- rule to sign if (not) encrypted
That's a lot, but probably nobody wants to disable any of these features.
The resulting UI is the best I found to deal with that.
(with the help of Patrick I reversed engineered, which option
 might cause which effect, and the situation is not easy to understand;
 I can send you a excel sheet if you are interested).

> I propose to distinguish between standard (rename to "simple?) and expert 
> view:
> 
> 
> *1* Simple view
> 
> All is set to fully automatic (opportunistic encryption without interaction) 
> and
> that default cannot be modified (in standard view only).
> 
The new default for the ordinary user will be:
- enc off
- auto encrypt if keys valid
This is so simple and easy to use so that I bet that 90% of users
will use this mode.
And usually even experts need no or only a few rules.

But something must always be possible:
Finally manually force to encrypt/sign or not to encrypt/sign.
This is nothing we can skip in any mode.
This is feedback I got already from people trying out the new features
(and BTW, this is also what GPGTools provides for Apple).

> To allow exceptions, the user may use the icons or menu. Three entries there:
> 
>   Sign message [tick indicates current state]
>   Encrypt message [tick indicates current state]
>   Switch to expert settings
>   --
> 
As I wrote, IMO that's definitely not enough.
Even beginners always have to be able to disable encryption explicitly
if it is automatically selected.

The rest is more or less what I programmed
without the ability to switch to expert mode
(we already have basic and expert mode, we don't need
 one more confusion; as I wrote if it is useful,
 we can make "rest to default&rules" an expert mode entry).

> Note: no PGP/MIME menu entry to switch it. A common user doesn't want to know
> what PGP/MIME is. I'd even go as far as to enable HTML (since it's TB default)
> and PGP/MIME in simple view.
> 
As I wrote, this is disabled in the non-expert mode now.

But you are right, whether PGP/mime should be default and whether HTML
should be enabled by default is indeed something we should discuss.

> *2* Expert view
> 
> The user may control everything as before / as you want to change it if it's
> OK with Patrick.
> 
Of course, this is still possible, but with a lot of clean-ups.
For example: In the past the option to sign if (not) encrypted
was applied after the default but before the rules.
Thus, if a rule force encryption signing was not forced although
forcing to sign was set. Very confusing.

Now, there is a much cleaner model:
a) use account specific defaults
b) process rule to force answering in the mode of the mail you reply to
c) use auto encryption if selected and all keys valid
d) process rules (first feature that might force not to sign/encrypt!)
e) process final setting (final interactive directions, includes
   options to "sign if (not) encrypt")

Steps a) to d) count as "defaults and rules"
Step  e) is what you can force with the icon buttons and menu items

> That said, I think that we should discuss severe changes within the team 
> first,
> then ask the list for feedback, rediscuss internally and then implement it.
In general I strongly agree, BUT
a couple of thoughts/notes about this:
- I did discuss all changes with Patrick, directly.
  So, he knows.
- One problem is that what you propose takes too long.
  It not only required fast feedback it also required
  the need to explain everything in ahead.
  Therefore, I only ask if I really need directions or help.
- A

Re: [Enigmail] on/off/default in a menu

[Nicolai Josuttis]

Thanks for the feedback.
I thought about it and the new interface I just programmed is as attached.
Thus, on the first three lines
you see the currently resulting status regarding
- signing
- encryption
- pgp (experts mode only)
with SOMETIMES (but we can extend that later) details about the reason.

For each of this status infos there is a sub-menu
that allows to switch between the 3 possible states:
- use defaults and rules
- force yes
- force no

Note that in contrast to DKG's (hope it's OK to write it that way)
all options are always signaled for two reasons:
 - show what is currently set
 - stability in the UI (an important general UI rule for the ability
   to select UI entries fast)

Note that the status bar icons serve indeed as corresponding toggle
buttons, where however you can only force yes or force no.

That is:
- The simple interface for enigmail is the icons:
  - They signal the status and allow to
finally force signing/non-signig and encryption/not-encryption
(nothing more, so after clicking them you really can only
 turn signing/encryption on or off)
  - The tooltips have the same labels as the menu entries.
- The menus provide then in addition:
  - the ability to see/modify the status in case the status bar
is disabled
  - the ability to disable any forced state for an email
(thus to switch back to "use defaults and rules")
  - the ability even to see the resulting pgp mode
(expert mode only), which wasn't possible yet

Hope it's not too confusing, but it is definitely better than
the old interface, where we e.g. could not directly force not to sign
(the icon buttons changed the default so you also had to disable rules).

I am currently working on minor details.
But the goal is to have the whole fix ready
for the nightly build after this weekend
(including Monday, which is a holiday here)

Feedback welcome.
Best
 Nico


Am 06.06.2014 22:52, Daniel Kahn Gillmor schrieb/wrote:
> Hi Nicolai--
> 
> On 06/06/2014 04:39 AM, Nicolai Josuttis wrote:
> 
>> I am about to make the enigmail UI more convenient/self-explaining.
>> So, I have the following problem:
>> I want to give three choices for encryption (and other options):
>> 1) use default setting and rules
>> 2) turn encryption on
>> 3) turn encryption off
>>
>> Unfortunately there is no 3-way-toggle button.
>> But I want to give these three options in a menu.
> 
> i'm assuming you're talking about the OpenPGP menu in a single compose
> window.  is that right?
> 
> At the moment, there are four options:
> 
>  Sign Message
>  Encrypt Message
>  --
>  Use PGP/MIME for This Message
>  Ignore Per-Recipient Rules
> 
> and they get little checkmarks when they're set.
> 
> It seems like you could apply these options just for encryption, leaving
> the "Sign Message" alone, right?  Is there some sort of "default"
> signing scenario that people might want to revert to?
> 
> All the options presented seem rather clunky to me, and (worse) they
> present a problem for feedback -- if you're in the default state,
> looking at this state should let you know whether the given message is
> going to be encrypted or not.
> 
> have you thought about how to address this view in the icons in the
> status bar (the pencil and the key) as well?
> 
> Unfortunately, i'm having a hard time coming up with something better.
> 
> I looked around at ideas about tri-stated checkboxes:
> 
>  https://en.wikipedia.org/wiki/File:Checkbox_States.svg
>  http://guijournal.com/2011/05/gui-design-tri-state-checkboxes/
> 
> but they don't seem particularly useful to me.
> 
> Here are the things i'd like to come out of this decision:
> 
>  0) to see at a glance what the state of the message is
> 
>  1) to know if i'm using the defaults or not
> 
>  2) to be able to move from the default to a forced-setting other than
> the current default
> 
>  3) to be able to move from the default to a forced-setting that is the
> same as the current default
> 
>  4) to be able to move from one forced-setting to another
> 
>  5) to be able to move from a forced-setting back to the default
> 
> Some of these might seem more like things that humans want than others.
> 
> (3), for example, seems unlike something that a regular human would
> think about.  But it is relevant in the context of "as i write this
> draft, the defaults might change and i don't want to worry about that"
> 
> 
> If there are three (or four?) categories that i want to be able to have
> all these features on, it's pretty complicated!
> 
> Here are two more proposals to consider:
> 
>  A) explicit default/non-default action

[Enigmail] on/off/default in a menu

[Nicolai Josuttis]

Hi all,

I am about to make the enigmail UI more convenient/self-explaining.
So, I have the following problem:
I want to give three choices for encryption (and other options):
1) use default setting and rules
2) turn encryption on
3) turn encryption off

Unfortunately there is no 3-way-toggle button.
But I want to give these three options in a menu.

So, which approach is the best:

a) 2 menu entries which you can turn on and off:
   ---
  force to encrypt
  force not to encrypt
   ---
and you can select at most one of them
- selecting one disables the other if selected
- clicking on a selected entry turns it off

So possible states are:
   ---
  force to encrypt
  force not to encrypt
   ---

   ---
x force to encrypt
  force not to encrypt
   ---

   ---
  force to encrypt
x force not to encrypt
   ---

If neither of them is ON, default settings are used.

b) 3 menu entries where you can select exactly one:
   ---
  use defaults and rules for encryption
  force to encrypt
  force not to encrypt
   ---

So possible states are:

   ---
x use defaults and rules for encryption
  force to encrypt
  force not to encrypt
   ---

   ---
  use defaults and rules for encryption
x force to encrypt
  force not to encrypt
   ---

   ---
  use defaults and rules for encryption
  force to encrypt
x force not to encrypt
   ---

c) 4 menu entries (one for the topic, three for the choices)

   ---
send encrypted
  according to defaults and rules
  yes
  no
   ---

So possible states are:

   ---
send encrypted
x according to defaults and rules
  yes
  no
   ---

   ---
send encrypted
  according to defaults and rules
x yes
  no
   ---

   ---
send encrypted
  according to defaults and rules
  yes
x no
   ---

Note that in the menu we would have these choice for
signing/encryption/PGP/Mime.
Thus, with 4 entries for each topic, we get 12 menu rows.

Or do you even have a better idea?

Best
 Nico


-- 
Nico

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Documentation needs Update / Error Message

[Nicolai Josuttis]

Seems not to be a problem of enigmail but of the GPG layer below.
May be you find out at
 http://lists.gnupg.org/mailman/listinfo/gnupg-users
what the exact way to request the keys via hkps is
(under windows) and then we could add a corresponding patch.
 Nico

Am 04.06.2014 00:54, Suspekt schrieb/wrote:
> Am 04.06.2014 00:47, schrieb Daniel Kahn Gillmor:
>> On 06/03/2014 06:17 PM, Daniel wrote:
>>> Am 03.06.2014 23:48, schrieb Daniel Kahn Gillmor:
 the above doesn't look like it's being run from a cmd prompt.  If
 you're running windows 7, click the start button, and then in the
 search box, type "cmd" (without the quotes) and hit enter.

 you'll get what passes for a terminal environment on windows.

 In that box, try running the gpg commands and seeing what output
 you get -- i think this should produce more copious logs than
 you're currently seeing.
>>>
>>> Dooh, youre right of course, i should go to bed...
>>>
>>> So cmd says:
>>>
>>> C:\Users\Daniel>gpg --charset utf-8 --display-charset utf-8
>>> --keyserver-options ca-cert-file=C:\Users\Daniel\s
>>> ks-keyserver.netCA.pem --keyserver-options debug --command-fd 0
>>> --no-tty --batch --fixed-list --with-colons --
>>> keyserver hkp://hkps.pool.sks-keyservers.net:11371 --search-keys
>>> susp...@gmx.de
>>> gpg: suche nach "susp...@gmx.de" auf hkp-Server
>>> hkps.pool.sks-keyservers.net
>>> SEARCH susp...@gmx.de BEGIN
>>> info:1:1
>>> pub:4229D21B:1:4096:1401723665::
>>> uid:Daniel :1401723665::
>>>
>>>
>>> SEARCH susp...@gmx.de END
>>
>> hm, i'm having a hard time reading the line breaks in this, and i'm also
>> not seeing anything close to it when i do the search myself.
>>
>> I get *lots* more content, including indications of what IP address was
>> used, etc.
>>
>> even if the certs don't match at least i get the following info from gpg
>> 2.0.22:
>>
>> 0 dkg@alice:~$ gpg2 --no-tty --batch --fixed-list --with-colons
>> --keyserver-options debug --keyserver-options
>> ca-cert-file=/tmp/mysteryca.pem --keyserver
>> hkps://hkps.pool.sks-keyservers.net --search susp...@gmx.de
>> gpg: searching for "susp...@gmx.de" from hkps server
>> hkps.pool.sks-keyservers.net
>> gpgkeys: curl version = libcurl/7.37.0 GnuTLS/3.2.15 zlib/1.2.8
>> libidn/1.28 libssh2/1.4.3
>> gpgkeys: search type is 0, and key is "susp...@gmx.de"
>> * Hostname was NOT found in DNS cache
>> *   Trying 162.243.93.15...
>> * Connected to hkps.pool.sks-keyservers.net (162.243.93.15) port 443 (#0)
>> * found 1 certificates in /tmp/mysteryca.pem
>> * server certificate verification failed. CAfile: /tmp/mysteryca.pem
>> CRLfile: none
>> * Closing connection 0
>> gpgkeys: HTTP search error 60: server certificate verification failed.
>> CAfile: /tmp/mysteryca.pem.pem CRLfile: none
>>
>> SEARCH susp...@gmx.de FAILED 1
>> gpg: key "susp...@gmx.de" not found on keyserver
>> gpg: keyserver internal error
>> gpg: keyserver search failed: Keyserver error
>> 2 dkg@alice:~$
>>
>>
>> i'm not sure what to suggest.  maybe someone with windows experience or
>> a windows test installation can chime in here?
>>
>> --dkg
> OK thanks for taking the time! Maybe Ill try it tomorrow again using a
> VM with a fresh install, its Windows, so everything is possible...
> time for bed now...
> 
> Daniel
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 

-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] auto-send-encryption option now available in nightly build of enigmail

[Nicolai Josuttis]

Hi Philip,

just a short first sentence for those looking whether this email
is on interest:
 Today I fixed a bug with the new behavior,
 so that the +/- computation should be (more) correct now
 (with the next build available on Monday).
Details:

Am 11.05.2014 15:05, Philip Jackson schrieb/wrote:
> 
> On 09/05/2014 18:41, Nicolai Josuttis wrote:
>> Hi all,
>>
>> yesterday I merged my changes to support the option to automatically
>> send encrypted if all keys are known (and valid).
>> With this, you can probably skip a lot of recipient-rules
>> and still use encryption whenever possible.
>>
>> The built is available as nightly built now.
>> See:
>>   https://www.enigmail.net/download/nightly.php
>>
>> You have to enable this feature in the sending preferences
>> (some other preferences there have changed and a help button was added).
>> See:
>>   http://hide-my-data.com/en/images/sendingprefs_140509.png
>>
> I have today just installed the latest nightly build and tried out your
> interface.  I like the presentation and especially the substantial 
> descriptions
> produced by the 'help' button.
> 
that's great!

> There are a few improvements that could be made to this help text, typos etc 
> --
> please see below.
>>
>> Note that whether emails are automatically sent encrypted
>> is now signaled in the compose message status bar on the lower right
>> of the compose message window WHILE you edit the recipient list.
>> See:
>>   http://hide-my-data.com/en/images/enigmail-icon140509.png
>> Currently:
>> - Having a yellow background signals you want to encrypt/sign;
>>   a grey background signals you don't want to encrypt/sign.
>>   These are buttons you can use to enable your request to encrypt
>> - A plus signals then if encryption/signing will happen due to rules
>>   or auto encryption.
>> - A minus signals no encryption/signing.
>> - A red icon signals a conflict.
> 
> I find that the buttons do change as recipients are typed into the list but I
> don't see any change in background colours.  For me, the background is always 
> a
> light blue (the basic light blue of Thunderbird).  Maybe that is what you call
> grey ?  I never see a yellow background.  Do the colours depend on Windows /
> linux implementations ?  Or is it just the icon colour which is meant to 
> change ?
> 
Well I am talking about Windows.
However, the change in background color (of the whole icon)
I would expect to see on any platform.
If you click on the icon, dies the background change?

> In the OpenPGP / preferences/sending tab, I selected 'manual' with 'all keys',
> encrypt 'if possible', confirm 'if rules change..'
> 
> I only see the plus signs if the recipient is already in my 'per recipient
> list'.  If I select a recipient whose public key I have but it is not signed 
> by
> me, I don't see any + sign. So it doesn't look as if 'auto encryption' will 
> happen.
> 
I made a bug, which I fixed today.
So, if you use the nightly build available tomorrow (Monday)
that should be fixed.
If not, please tell me.

> If I click on the two icons in the status bar showing + for someone in my 'per
> recipient rules' to cancel signing and encryption, the + signs remain but I
> thought they should change to minus ?  The icons themselves toggle between
> yellow and grey.
> 
The last sentence is the effect I meant with changing the background.
In general, the backgound color shows your general preference for this
email. Then + or - signal changes according to recipient rules and
auto encryption.

> For recipients for whom I have no rule, clicking on the status bar icons to
> permit or cancel signing/encryption doesn't produce a + or - sign.
> 
Yes, because you change the general wish, which will be followed
if no encryption is forced (having a +)
or non-encryption is forced (having a -).

> I expect I have misunderstood something? I presume there is no conflict with
> settings elsewhere eg Thunderbird/tools/account settings/OpenPGPSecurity.
> 
Well, I am not sure whether the interface is very intuitive,
but in general this has been the interface before (modulo some bugs).

> Does this whole 'manual' part of Preferences only apply to replies and not to
> original message compositions ?
> 
no, it should apply to all messages.

Thanks for the feedback on the help texts.
Best
 Nico

>>
>> After seeing the interface of GPGMail, I wonder whether this
>> interface is too complicated.
>> What do you think?
>> I also would like to have these icons at the top rather at the bottom
>> (e.g. at the 

Re: [Enigmail] auto-send-encryption option now available in nightly build of enigmail

[Nicolai Josuttis]

Am 10.05.2014 11:18, Olav Seyfarth schrieb/wrote:
> 
> Hi Nico,
> 
> thank you for your work, I like the enhancements very much. Up to now (not
> tested much) the nightly seemst to install and work fine. I like the new 
> sending
> settings dialog, have one remark though: it should be made clear, probably in
> help, to what manual settings "automatic/lazy?" (german: "bequem") 
> corresponds.
> 
BTW, the English name is "convenient". ;-)

> If it's possible to set exactly the same behaviour of "lazy" by certain 
> "manual"
> settings, then maybe it would be a clearer interface to not have the radio
> button at all but a button "revert to default" (which sets to "lazy"). Sorry I
> only come up with that idea now I saw what you implemented.
> 
We had roughly such an  interface as an intermediate version
(in fact, two buttons one for "convenient", one for "expert" or so)
and as a result Patrick came with this proposal ;-)

Note that you can switch to convenient/bequem while seeing what this
selects and then switch back to manual with your settings before
you switched to convenient.
So, that demonstrates the convenient defaults.


> Concerning your question whether the interface is too complicated: I think 
> not,
> it tries to make transparent what's happening behind the scenes. I agree 
> though
> that for Aunt Sally users one might want to enhance the send button, reading
> "Send unencrypted" / "Send encrypted" with longer mouseover-texts.
> 
Which send button?

> Olav
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 

-- 
Nico

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] auto-send-encryption option now available in nightly build of enigmail

[Nicolai Josuttis]

Hi all,

yesterday I merged my changes to support the option to automatically
send encrypted if all keys are known (and valid).
With this, you can probably skip a lot of recipient-rules
and still use encryption whenever possible.

The built is available as nightly built now.
See:
  https://www.enigmail.net/download/nightly.php

You have to enable this feature in the sending preferences
(some other preferences there have changed and a help button was added).
See:
  http://hide-my-data.com/en/images/sendingprefs_140509.png


Note that whether emails are automatically sent encrypted
is now signaled in the compose message status bar on the lower right
of the compose message window WHILE you edit the recipient list.
See:
  http://hide-my-data.com/en/images/enigmail-icon140509.png
Currently:
- Having a yellow background signals you want to encrypt/sign;
  a grey background signals you don't want to encrypt/sign.
  These are buttons you can use to enable your request to encrypt
- A plus signals then if encryption/signing will happen due to rules
  or auto encryption.
- A minus signals no encryption/signing.
- A red icon signals a conflict.

After seeing the interface of GPGMail, I wonder whether this
interface is too complicated.
What do you think?
I also would like to have these icons at the top rather at the bottom
(e.g. at the end of the subject text field).

And, BTW, for those who don't have this status bar:
You have to enable it in the compose message dialog
with something like: View -> Toolbars -> Status bar

Have fun.
Feedback welcome.
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de



___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] question regarding a new sending preferences layout

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

see the attached new dialog
(roughly implemented in the pushed branch AutoSendEncrypted)

Questions:
- - Should the manual preferences be kept
  when switching to convenient and back to manually
  OR is it good enough that switching to convenient
  switches back to defaults and then when you switch
  to manually you have to do your changes again?
  (a lot easier to implement)
- - Do we have a function to recursively disables elements?

- -- 
Nico

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTaARMAAoJEN75/ICKHETQ+FEP/3AZ+dy65J2J2z4i1mFBLec+
DFW9FXx8jq1k8/3zVca22uI+ny/Kx3hgjUYq2o29wquDVIP02rjZVV4OIebtohZ/
qajgqkyod6+eI9Djc5tq9AJXEOZH1yUqJ7WNFaavKniTTAg8ZGrykNpHm+NQPtR4
ZKbSsgp24/oZxmdCkeylbeGhFTQz/LeJz9C81zdZGYvLZo+n4bhcN0Y1Gz6T1986
1p9Hm/zVRqaowCNZgDS0BUFrsCldfKLsYzGLEgUk0Y8r7Z65WS3y8JrZjOU87uUO
ikqnTkdvBeKcYfyckutf4H9Bp4qu62WEH+ixLhBbbRT9+lBLr13hz1ls2CRuFqWY
9tdd6Fxq8872/8C8V1nbwvxyg+7jK54H0L41vUgKV4o1KxjN4FS6fvpLg/bsrpEu
+z30hC0BEPSK+LWjgn3hnLlWia23xquG0ncFIIGd/3VNxRxdH8QP/lpScS6Zh6J/
bYfv08oDTjwPCGptZfdjCZ2wU6Ii3V5g4hWLemZw1/rAfYfR1tR118Bn4g3AQQ8v
mNu2yfJLQ+B+6Xnc7NW4cjvbyQNl5vkFAxgD4HVtpSf8O8KX8M5ZZgiPQDcpxnO1
gT12ICFY9+cU8SBvpyQjNAz1F6oQi+Wu+xhWb2+OglYq8KhtX8ine8J/jgHhMy3u
8AiUyqpVsaElwOUlX/vT
=P5bO
-END PGP SIGNATURE-
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] question regarding a new sending preferences layout

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Good idea,
I can change the dialog accordingly.

However, my problem is that although dkg wrote:
> In other discussions about crypto that aim for the idea of
> "whenever possible, even if i'm not sure of the proper identity or
> other details", the word that seems to have the most consensus
> behind it is "opportunistic".
I have no clue what opportunistic means.

I am not familiar with this word (and I am a technical guy).
But we should use terminology that's easy to understand.

And Wikipedia's explanation at least sounds not like being
appropriate here:
> Opportunism is the conscious policy and practice of taking selfish
> advantage of circumstances – with little regard for principles, or
> with what the consequences are for others.

What's wrong with "convenient"?



Am 05.05.2014 18:25, Patrick Brunschwig schrieb/wrote:
> 
> On 05.05.14 02:13, Daniel Kahn Gillmor wrote:
>> On 05/04/2014 11:41 AM, Phil Stracchino wrote:
>>> It appears to em that terms like 'thorough', 'careful' are 
>>> scarcely even applicable to what you're trying to accomplish 
>>> here.  Mode 1 is basically 'Encrypt whenever possible' or 
>>> 'Encrypt always'.  Mode 2 is harder to define -- the best I
>>> can come up with is, 'Encrypt manually ONLY'.
> 
>> In other discussions about crypto that aim for the idea of 
>> "whenever possible, even if i'm not sure of the proper identity
>> or other details", the word that seems to have the most
>> consensus behind it is "opportunistic".
> 
> How about adding the following radio buttons:
> 
> (*) Opportunistic encryption ( ) Manual selection of encryption
> options 
> |--| |
> To send encrypted| |
> (*) keys signed by me or other people I trust   | |
> | |  etc.| 
> |  | |
> ( ) if rules changed encryption | 
> |--|
> 
> The stuff in the box is only active if "Manual selection of
> encryption options is chosen". If "Opportunistic encryption" is
> selected, then everything in the box is inactive, but displays the
> settings that result from choosing opport. enc.
> 
> -Patrick
> 
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 

- -- 
Nico
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTZ+NhAAoJEN75/ICKHETQhjUP/A1kd81N3R9bMWBAnWn5v88R
CYlyslPl9WGeLg4OOgx0N1w907PZQCVDG/d7cew5EiPIyKyx64o1aYLsdnsuVkWv
PLqGHN1Pqt60ZIOhAmlf2YK+TBahsVIGLGw88PcNwa41n2Nt4ozX672DQHCDuzcJ
QXCz1TZYge7eKrcVv3/ZZxShbBdfekzCDjecUTPow/1c1SrvYHkr2wcYfnWgqtXg
v7hzlGYZuiojZ2ct3Fr2m8C+FgKy1BiI2+zy5EXGh5yUNTIYZnoYu2HLmNwRsP4v
+dtH5SHshd7NZFCz9FvIz5nZ8LcIPOj3QJKkFLPqbHQaCnWit/fNVNU0uRraMd1A
rxZa9zUz48IC5a9nKnnqWh3BxnR7UN+a+w3qmZJuEfKmnD7qwWCnbbcB1fqW1fbq
VxSMYjk6L0hlQhZs/mfgRaCcRWwWRbbB7rdlCYJI5eVMuN11AcQR9rhJBcDVz14m
PD+IK7zHl++2LWirA+bDL3SJn8wNiBY4Qu4F1MoKpLmMEKqjFAL33l8y1sH32caG
2QWda9uZRC78YjYejZKdQWNM3OmJhT5AIQT6TINX9lK9G+KGTp3QFYWCUjAf6Cxx
4B3XtHA1PqPMxeaxg0SnElzhm5MW0jFlPgb/bd1PpewxzdaK1xajiXe52C7IQ3jg
3k6cE2Le473Zcaj0ALWw
=mReV
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] question regarding a new sending preferences layout

[Nicolai Josuttis]

Thanks for all feedback.

Hmmm,
we have the radio boxes.
The intent of the buttons would be to set these readio boyes
to useful defaults.
So, the buttons really should be named:
- reset preferences for to convenient encryption
- reset preferences for ... encryption.

But as nobody is exited, I can remove the buttons again
and only provide a help button explaining details
(beside the detailed tooltips each button has)

 Nico


Am 04.05.2014 17:45, Patrick Brunschwig schrieb/wrote:
> On 04.05.14 17:06, Ludwig Hügelschäfer wrote:
>> On 04.05.14 16:39, Olav Seyfarth wrote:
 Heavy encryption maybe ?
>>> H.
> 
>>> auto-magic
> 
>> Sounds very good!
> 
>>> vs. manually-controlled ?
> 
>> Well, rules would be active in this mode, if I understood it 
>> correctly.
> 
>> Maybe: "Classic"?
> 
> 
> Please don't use buttons, they imply that the an action is
> triggered, and usually either the dialog is closed or a new dialog
> is opened. I think you want to use radio buttons or checkboxes. The
> advantage with both is that you can provide a longer description
> (even a paragraph) than just a label.
> 
> In this sense, none of the single words is clear enough for me.
> 
> -Patrick
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] question regarding a new sending preferences layout

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for the feedback.

Am 04.05.2014 14:41, Philip Jackson schrieb/wrote:
> On 04/05/2014 14:00, Nicolai Josuttis wrote:
>> Hi,
> 
>> please look at the attached dialog. You can see a couple of new
>> feature that all should help users to set encryption options.
> 
>> Without explanation: - Is it self explaining? - Any improveents?
> 
>> I especiylla wonder about the text of the middle button 'Thorough
>>  encryption' Alternative names are: Careful encryption Accurate
>> Encryption Elaborated Encryption (I don't want to have 'Safe
>> encryption' because that raises too many questions). What would
>> you prefer?
> 
> I haven't seen the interface you mention BUT
> 
> I would avoid 'thorough', 'careful', 'accurate' : these three in
> English will imply that they are an alternative to 'careless' or
> 'shoddy'.  Any and all encryption is expected to be thorough and
> careful and accurate, and 'safe'. Any exceptions that might be
> anticipated would be put down to human error or (in the case of
> 'safe') to the greater expertise of an adversary and not to a 
> deliberate choice on the part of the sender.
> 
>> Just as a explanation: - Convenient encryption would select: -
>> accept ALL keys (trust-model always) - auto send encrypted if I
>> have accepted keys - Confirm before sending: never - Thorough
>> encryption would select: - accept only valid keys (WoT model) -
>> never automatically send encrypted (except rules) - Confirm:
>> always
> 
> I fear that it will be difficult to find a choice of 2 short labels
> for your 'convenient' and 'thorough' buttons which will be clear
> and not misleading.

It's not the goal to be perfect,
The goal is to let user choose easily a matching model.
So the general choice is:
- - I want to encrypt and prefer the convenient way
- - I want to encrypt and prefer the careful ways (non-convenient)

That's something people can understand (IMO).

Anything in more detail is simply frustrating for the average user,
who just wants to replace sending emails as postcards by sending them
as letters.


> Perhaps the 'convenient' could be labelled 'handy but with risks'
> and 'thorough' could be labelled 'thoughtful'.
> 
I am feeling pretty strong about convenient (or may be handy)
currently, because that's exactly what it is.
And while I agree that careful sound as opposite to careless,
it is important to note that this button has a context:
The other button 'convenient'.
So consider both options in the face of the facts that
these two options are what you can choose from and not isolated.

> In any case, I fear that a complementary explanation will be
> required in the form of a 'help' button to explain to beginners the
> subtleties of the decision making process required to chose between
> the two options.
> 
That's why there is a help button ... ;-)
The explanations are already there.
To quote what I programmed yet:

-
--
Enigmail Help

Defining Preferences to Send Ecrypted

In the Sending Preferences you can choose your model for encryption.
There are choices because in general two options are possible:

*Convenient Encryption*

With these settings, emails are encrypted whenever possible. This
is like sending emails as letters instead of postcards. Unlike
postcards letters usually hide their contents while in transit.
However as with letters, you can't be sure that nobody is opening the
letter while it is in transit, but some technical effort is necessary
for that.

Technically, the risk is that you accidentally use "faked keys"
you got from somewhere or somebody claiming that the key belongs to
the person you want to send emails to.


*Thorough (Careful/Accurate/Elaborated) Encryption*

With these settings, email are encrypted using only keys you can
trust (either signed by you or signed by people you trust). This
follows the default trust model of PGP, which accepts keys as "valid
for encryption" only, if you explicitly signed them or enough people
you trust signed them.

While this model eliminates some additional risks, it requires
that you actively sign keys and declare owner trust.


If you just want to switch from sending emails without
encryption to sending emails encrypted whenever possible,
convenient encryption is probably your choice.

If it is key for you that content you send encrypted
can't be read by other people or organizations,
choose thorough encryption.
- 

[Enigmail] question regarding a new sending preferences layout

[Nicolai Josuttis]

Hi,

please look at the attached dialog.
You can see a couple of new feature that all should help
users to set encryption options.

Without explanation:
- Is it self explaining?
- Any improveents?

I especiylla wonder about the text of the middle button
 'Thorough encryption'
Alternative names are:
 Careful encryption
 Accurate Encryption
 Elaborated Encryption
(I don't want to have 'Safe encryption' because
 that raises too many questions).
What would you prefer?

Just as a explanation:
- Convenient encryption would select:
  - accept ALL keys (trust-model always)
  - auto send encrypted if I have accepted keys
  - Confirm before sending: never
- Thorough encryption would select:
  - accept only valid keys (WoT model)
  - never automatically send encrypted (except rules)
  - Confirm: always

Any feedback is welcome.

AND:
If you want to try out the new features
(except the new buttons convenient/thorough/help)
here is a xpi file:
 https://www.enigmail.net/download/beta/enigmail-1.7a1pre-test2.xpi
(thanks to Patrick for providing that).

Either load the xpi file directly into Thunderbird or
save it with Firefox and then open it via
 extras -> Add-ons ...
  and in the tab select the top right "cogwheel" button
  and choose the option to install add-on from a file

Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] UserSelection dialog improvements

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,
I just pushed some updates for the UserSelection dialog,
which might be on interest
(wait one night for the next build).

Features:
a) sort matching but invalid items to the top
   Thus if you couldn't send due to an expired key
   or so, you don't have to scroll down now
b) sort invalid (disabled/revoked/expired) keys to the end
c) split whether to encrypt&sign into two checkboxes
   so that this handling becomes more intuitive
d) allow to select keys with unknown trust
   even if not "always trust" is enabled
   (still signaled as "not appropriate")

The effects will especially apply if the "always trust"
option is disabled (the goal is not to frustrate people more
than necessary if this preference is disabled).

Fixes:
a) fix buggy handling of invalidAddr
   (wrong keys sometimes listed on top as invalid)
b) fix buggy processing of whether to encrypt in the
   UserSelection checkbox (probably my bug ;-( )
c) fix strange effect of "refresh keys"
   (removed invalid keys on top and could
activate keys although nothing change in the key list)

And hopefully no new bugs. ;-)

I am also pretty close to push a new test version for
"auto send encrypted if all keys are valid"
(in fact this patch is a part of it, moved into
 the master already).

- -- 
Nico
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJTYtliAAoJEN75/ICKHETQ+LEP/0Gcueqte7Y685ZS+dS5jPRV
kVDMXpLq63jhKDoz0kXhFJZF7VauAB5hxeqXOHXOdgPBYT1V4+tiF72q+oc52SAU
7pIztXnYe6r4TJILN0qdHBkMnnLa7zEtDsZPpaSTAkZcHN4oClfesp9DHwCCrsfx
oiHBMy7hHxGusBOzJwJlqShhfRUgqo/r4nNeHD0NQQRH8RUrTYuyLTs/8eQrTJ39
xYvWOkGWtZb0CSjpK0Btwh/GxecBaHtVk++FjpC+FFX3cbeJQqRYPkt9Uu2n4+rg
rU3L6y5tMlIW/uOHnfRmQOxTylAsHq1FdVDBBz3NzpcKXwkZDdV0Pj4qJgW8D/Ut
7SF/ObQKEJlJVSH+GsONXh0Vk3cTiqwLg61RoxxcSvCEJ9zST46s5uizotQ+u+1r
DrdN/cKHRLWlJEfB8HjaRuDIrUq2MtGmOgMyVSxpsyrL4u5xvNB7Mus5BxIWtHWV
981Mou2yDsKzds0rOeL61zjHGpCzvHiD+fBODcppk9ELryfDYHHJi6KzJ7UpA/6j
xNsj4PUBj/b2lnwMgZQLMLLwcjOvhr4+XXxutb14JPcf7tzbInqqBnhct1So9036
ppzQckSEdtQ0L1hOLpKJbJh/VBvVF+qln8y0mi0TAdQ9ShWxpXFgdqUIHxFt8aij
DwJocvng7O/GBg6cP7rz
=VO4A
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for this helpful feedback.

Am 22.04.2014 23:00, Philip Jackson schrieb/wrote:
> On 22/04/2014 01:30, Daniel Kahn Gillmor wrote:
>> On 04/21/2014 04:11 PM, Nicolai Josuttis wrote:
> A key, userid pair could, of course, be compromised very soon after
> it has been given 'valid' status but the greater the elapsed time,
> the greater the risk of compromise.  Of course, if the secrets are
> trivial, the risk is of no importance but then neither would the
> encryption be really vital.
> 
> This, for me, is the greatest element of risk in
> 'auto-encryption'.
> 
well, but this argument also applies to manual encryption.
The only difference is that the user don't have to explicitly
select "encrypt". But if he/she would do that, the effects/checks
are the same.

>>> So may be we allow to change both options into the following:
>>> 
>>> Accepted keys to send encrypted: - All valid keys according to
>>> the web of trust - All except disabled/expired/revoked keys
> 
>> how about:
> 
>> For a given e-mail address, encrypt messages to:
> 
>> * all keys valid for that e-mail address * all usable keys that
>> claim to belong to that e-mail address
> 
>> Note that enigmail's current default behavior is to simply choose
>> the *first* key in GPG's keyring that claims to be associated
>> with the e-mail address in question.  This is true, even if the
>> first key in the keyring with a given e-mail address is *not
>> valid* for that e-mail address, and another later key *is valid*
>> for that e-mail address :(
> 
> Whoops !
> 
REALLY
We should fix that.
And I probably can because that's NOT how auto-encryption
is implemented.
I loop over all email addresses until I find a matching one
with enough trust/validity.
THUS, auto-encryption would be even an improvement ... ;-)

>>> Automatically send encrypted - never - if we have accepted keys
>>> for all e-mail addresses
> 
> 
> 
>>> And for the first option of the first option we NEED a very
>>> short but compelling explanation (ideally as help text), which
>>> I still try to find reading all the documentation. May be: -
>>> According to the web-of-trust, a key is valid if: - it is your
>>> key (has ultimate owner trust) - you signed it - another owner
>>> you fully trust signed it - at least 3 other owners you
>>> marginally trust signed it
> 
>> this may or may not be true, depending on the certification
>> patterns. It's certainly possible for users of gpg to modify how
>> gpg interprets the network of identity certifications it knows
>> about.  See "--marginals-needed" and "--max-cert-depth" and
>> "--trust-model" arguments to gpg.
> 
> Yes, personal configuration decisions at this level work against
> the setting up of a standard system / explanation for
> auto-encryption.
> 
wecan add "by default" or "for example"
The point is that the novice has to know what that means
(if the change underlying setting they probably know more anyhow).

>>> But, BTW, I just saw that we also use the term "trusted"
>>> instead of "valid" in the key manager. So currently "trusted
>>> key" is used more or less consistently as non-technical term
>>> for "valid key".
> 
>> Any place you find enigmail using "trusted" to mean "valid" is a
>> bug, and needs to be fixed.  it's not surprising that there are
>> more cases that still linger in the codebase; gpg didn't clarify
>> its own terminology until several years ago, and enigmail has
>> done some cleanup on this recently, but seems to be reintroducing
>> some of the conflated terminology in some places. We should
>> really try to avoid that.
> 
>> (for example, the recent "trust the keys of all recipients"
>> should probably be something like "don't validate keys of
>> recipients" -- we don't know if the keys in questions actually
>> belong to the recipients, and we don't plan to actually indicate
>> any ownertrust in them)
> 
>>> So, let me ask again: May be you and we all can live with the
>>> term "trusted key" (as contrast to trust for owners),
> 
>> no, i think that's one of the root causes of a lot of ongoing
>> confusion. non-expert users and expert users alike will be
>> confused if we use the same term ("trusted") to mean two
>> different things.
> 
> 
> Quite correct.  This confusion at the se

Re: [Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 21.04.2014 18:49, Daniel Kahn Gillmor schrieb/wrote:
> On 04/21/2014 07:09 AM, Nicolai Josuttis wrote:
>> Thanks a lot for this feedback, Daniel. These are very compelling
>> arguments. Seems I fall into the trap of making it "too good".
> 
> thanks for reading and taking this seriously.
> 
>> The new approach I suggest would be just to offer:
>> 
>> Automatically send encrypted? - Never - If all keys are known and
>> valid
> 
> yep, this looks pretty good.  But you might instead want to phrase
> the last part as:
> 
> "if we have valid keys for all e-mail addresses"
> 
> conceptually, the thing we're hoping will be valid is the
> *certificate*, which is a combination of user ID and key material,
> along with some additional cryptographic assertions about it.  A
> valid certificate mean "we believe that the key in this certificate
> belongs to the person identified by the user ID in this
> certificate".
> 
understood and no problem because is is understandable wording for the
naive user.

> Note also that OpenPGP certificates can have multiple User IDs, and
> you might believe that one User ID is valid, but another might not
> be.  For example, I recently acquired a new e-mail address, and
> added it to my OpenPGP certificate.  I haven't called publicly for
> new certifications of that e-mail address, so most people are
> unlikely to have verified it.
> 
> So when we say "we have a valid key" we're omitting a bunch of
> details. We're really trying to say "we have a key that we believe
> is correctly bound to a user ID for the e-mail address that you're
> sending this mail to".
> 
>> And let the option "Always trust people's keys"
> 
> I think this option is misleadingly-labeled in the first place.
> It should say "use keys without verification" or "accept keys of
> unknown validity" or something like that.  the point is (a) this is
> not "trust" in the OpenPGP sense of ownertrust, so this term should
> be avoided here and (b) the keys that you will use if you set this
> flag may or may not actually belong to the people to whom you are
> sending the mail, so "people's keys" is misleading on its own.
> 
>> then have the effect whether this means again: - (disabled:) use
>> the rules of the web of trust for validity or - (enabled) auto
>> send encrypted if all keys are known and not
>> disabled/revoked/expired/mistrusted.
> 
> this makes sense to me (though see below about "/mistrusted")
> 
>> So, my question is: What is the right term for "not expired and
>> not revoked and not disabled" (the term should work for
>> non-experts).
> 
> I'd use a term like "well-formed" or just "usable", but i don't
> know of any consensus around either of those terms.
> 
But thats hard to understand for non-experts.
Let me try to find a wording both experts and novices can live with
(IMO that's key for a better acceptance of PGP).

We have owners.
We can specify how much we trust them.
We have keys.
Keys belong to email addresses.

So the hard part is how the following:
- - a key is valid means different thing for experts and novices
- - we trust a key is nothing useful for an expert
  but for a novice.

Now we have to formulate an option:
- - we accept all keys except disabled/expired/revoked ones.
AH, may be "accept" is a word we can use
(I used it here incidentally...)

So may be we allow to change both options into the following:

Accepted keys to send encrypted:
- - All valid keys according to the web of trust
- - All except disabled/expired/revoked keys

Automatically send encrypted
- - never
- - if we have accepted keys for all e-mail addresses

And for the first option of the first option we NEED a very short but
compelling explanation (ideally as help text),
which I still try to find reading all the documentation.
May be:
- - According to the web-of-trust, a key is valid if:
  - it is your key (has ultimate owner trust)
  - you signed it
  - another owner you fully trust signed it
  - at least 3 other owners you marginally trust signed it

But, BTW, I just saw that we also use the term "trusted" instead of
"valid" in the key manager.
So currently "trusted key" is used more or less consistently
as non-technical term for "valid key".
So, let me ask again:
May be you and we all can live with the term "trusted key"
(as contrast to trust for owners),
meaning that they is technically valid.
(i still think this is the best self-explaining term for novices).

So the other option would be to specify the 

Re: [Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

Am 21.04.2014 01:29, Daniel Kahn Gillmor schrieb/wrote:
> 
> this is a neat idea, but...
> 
;-)

>> In fact, you can choose between:
>>> Automatically send encrypted?
>>> - Never
>>>   No automatically encrypted sending except explicitly triggered by rules
>>> - With full trust
>>>   Automatically send encrypted when all keys are known and valid and have 
>>> full trust
>>> - With marginal trust
>>>   Automatically send encrypted when all keys are known and valid and have 
>>> at least marginal trust
>>> - With unknown trust
>>>   Automatically send encrypted when all keys are known and valid and have 
>>> no explicit mistrust
> 
> the above terms are deeply confusing.  "valid keys" are not the same as
> "trusted keys".  In OpenPGP, a "valid" certificate means that we believe
> that the key belongs to the person named in the User ID.  a "trusted"
> key means that we're willing to believe OpenPGP certifications made by
> this key.
...
> 
>> I think it's a really bad idea to make encryption contingent on trust
>> settings; it should only be contingent on validity.
> 
> let me explain this a bit further:
> 
>  * setting non-zero ownertrust on someone's keys puts you at risk of
> being willing to believe any faulty certifications that they make.
> 
>  * therefore, you should only set ownertrust on a key if you think that
> the keyholder makes reasonable certifications.
> 
>  * any tool which changes its behavior in ways unrelated to reliability
> of a keyholder's certifications on the basis of how much ownertrust
> you've set on the key will encourage some people to set ownertrust for
> these other effects.
> 
>  * the result will be that those users will end up willing to rely on
> certifications that they really do not want to rely on.
> 
> does this make sense?  any auto-encrypt mode needs to be based strictly
> on certificate validity (for the e-mail addresses being sent to, not for
> any other User ID on the key), and *not* on key ownertrust.
> 

Thanks a lot for this feedback, Daniel.
These are very compelling arguments.
Seems I fall into the trap of making it "too good".

The new approach I suggest would be just to offer:

Automatically send encrypted?
- Never
- If all keys are known and valid
And let the option
 "Always trust people's keys"
then have the effect whether this means again:
- (disabled:)
  use the rules of the web of trust for validity
or
- (enabled)
   auto send encrypted if all keys are known
   and not disabled/revoked/expired/mistrusted.

BUT KNOW I have a significant question:
I meant "valid" in the non-expert sense of
"not expired and not revoked and not disabled".
But you are right in the PGP world valid means more
(taking the web of trust into account).
So, my question is:
What is the right term for
"not expired and not revoked and not disabled"
(the term should work for non-experts).
Similar, do we have a term for
"not expired and not revoked and not disabled and not mistrusted"?

Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de



___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



Am 20.04.2014 21:38, Philip Jackson schrieb/wrote:
> Hi Nicolai,
> 
> I've downloaded and installed the 1.7a1pre-test version.
> Patrick's link shouldn't just be clicked on though.  Firefox
> downloaded it and tried to install and then rejected it as 'not
> being suitable for Firefox' and then presumably deleted it (because
> I couldn't find it in the downloads directory).
> 
> However, one question :  in the preferences/sending tab, how do 
> your new options cohabit with the second check box item 'Always 
> trust people's valid keys' ?
> 

> Does that option cancel your 3 options for full, marginal, unknown 
> trust levels?
> 
No, it's the other way round:
Currently the options don't affect each other (which might be wrong).

That is:
- - I can select to auto send encrypted emails
  to people for which the keys have unknown trust
  although "always trust" is NOT selected.
- - I was thinking about some alternatives, though.
  One is that if not "always trust all keys" is selected
  I disable the last (two) options.
  That would be a visual feedback for what you asked.
- - Another is that the auto-send-options only ask whether to send
  encrypted if all keys are known and "trusted"
  and what "trusted" means is derived from the
  "always trust all keys" option".

In any case I am not sure whether the whole approach
I programmed is good/intuitive.
So allow me to explain some details of the current implementation:

- - Option "always trust all keys" is enabling or disabling the option
  --trust-model always
  This is documented in the GPG manual as:
  > Skip key validation and assume that used keys are always fully
trusted.
  > You generally won't use this unless you are using some external
validation scheme.
  > This option also suppresses the "[uncertain]" tag printed with
signature checks when there is no evidence that the user ID is bound
to the key.
  Sounds pretty dangerous (but is often selected).

- - My options affect whether and how the Key Validity and Owner Trust
  columns of the key management are considered.
  For example, if I need marginal trust,
  both columns have at least to have that level.
  (Note that validity/trust is sorted according to:
- disabled/revoked/expired
- explicit mistrust
- unknown trust
- marginal trust
- full/ultimate trust
   )
  "auto send encrypted" would never happen with keys being in the
  first two groups. No option should change that IMO.
  For the other three groups,
  I have provided the three auto-send-enc-options.

However, now we have different trust models
(one by GPG and one by the key manager)
THis also can be confusing.
On the other hand,
dealing with what is defined in the key management dialog
can be more intuitive than dealing with the rules of
the web of trust.

Consider for a moment we would have no recipient rules
and people don't know the rules of the web of trust.
The simple approach for the novice either would be:
 a) You can disable auto encrypt.
Then you have your general default about whether to encrypt
which you can change for each mail.
 b) You can select to auto encrypt if all keys are known
(ignoring the trust level, but not mistrust or revoke/expired).
This is like selecting "always trust all keys"
(and as dangerous)
 c) You can select to auto encrypt only if keys are known
AND you have declared some trust.
In my implementation you can either require
at least either marginal or full trust.

The current approach I implemented gives you this principle,
with the behavior that for b) and c) "always trust all keys"
doesn't matter.
If I give "always trust all keys" a semantics here,
the effect would be to let c) and b) behave the same
if "always trust all keys" is enabled.
May be that's more intuitive.
Especially if I disable the last two options
when "always trust all keys" is selected.

But is all might be too complicated ...
(for novices or experts or both?).
Hmmm, questions over questions ...
As I wrote: I am not sure.
Opinions please.

 Nico


> - Philip Jackson 
> Tel : (+33) 468 49 80 53GnuPG Public Key : 0x23543A63.asc
> 
> On 20/04/2014 19:35, Nicolai Josuttis wrote:
>> The new model provides different options to auto send encrypted 
>> based on the owner trust of the keys.
> 
>> Options are roughly: - never auto encrypt (except by rules) - 
>> always auto encrypt if all keys known (except keys with
>> mistrust) - auto encrypt if all keys known and having full owner
>> trust - auto encrypt if all keys known and having at least
>> marginal trust (yes, the curren

Re: [Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

> On 20.04.14 15:30, Nicolai Josuttis wrote:
>> as announced some weeks ago, I just pushed a patch for a first 
>> implementation to provide the ability to automatically encrypt 
>> messages if all valid keys are known without the need to have a 
>> rule for it into the sub-branch (derived from master): 
>> AutoSendEncrypted
...

Am 20.04.2014 16:48, Patrick Brunschwig schrieb/wrote:
> Even though setting up a build environment is easier than in the
> past, I still don't think that everyone will want to do so. I have
> created a package to download for Windows, Linux and Mac OS X:
> 
> https://www.enigmail.net/download/beta/enigmail-1.7a1pre-test.xpi

Thanks a lot, Patrick.

For those testing it I have a specific question:
The new model provides different options to auto send encrypted
based on the owner trust of the keys.

Options are roughly:
- never auto encrypt (except by rules)
- always auto encrypt if all keys known (except keys with mistrust)
- auto encrypt if all keys known and having full owner trust
- auto encrypt if all keys known and having at least marginal trust
(yes, the current labels can be improved)

Question:
- Is this too fine grained?
- Or is this even confusing
  (because now if I select the second option,
   it ignores "always trust all keys" being off).
Another simpler model would be:
- never
- if all keys are known
- if all keys are known and trusted
  (but here we must define what "trusted" means)

Also I wonder whether the options should be in the "sending"
or "key selection" tab.
I preferred "sending" because in principle this option
has the power to allow especially newbies to
ignore recipient rules by still encrypting if useful
and possible.
- Either having the keys is enough
- Or having the keys and explicitly having raised trust
  is enough.
  But then the difference between full and marginal might be helpful.

Nico


-- 
Nicolai M. Josuttis
www.josuttis.de

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] test implementation for auto encryption available in test-branch

[Nicolai Josuttis]

Hi all,

as announced some weeks ago,
I just pushed a patch for
a first implementation to provide the ability to
automatically encrypt messages if all valid keys are known
without the need to have a rule for it
into the sub-branch (derived from master):
 AutoSendEncrypted

In fact, you can choose between:
> Automatically send encrypted?
> - Never
>   No automatically encrypted sending except explicitly triggered by rules
> - With full trust
>   Automatically send encrypted when all keys are known and valid and have 
> full trust
> - With marginal trust
>   Automatically send encrypted when all keys are known and valid and have at 
> least marginal trust
> - With unknown trust
>   Automatically send encrypted when all keys are known and valid and have no 
> explicit mistrust

With this patch I also change the ability to ask for confirmations
before sending with more options:
> Confirm before sending?
> - Never
>   Don't display information dialog about signing/encryption before sending a 
> message
> - Always
>   Always display information dialog about signing/encryption before sending a 
> message
> - If encrypted
>   Display information dialog about signing/encryption before sending an 
> ENCRYPTED message
> - If unencrypted
>   Display information dialog about signing/encryption before sending an 
> UNENCRYPTED message
> - If rules changed encryption
>   Display information dialog about signing/encryption before sending if 
> encryption was changed by a rule or auto-encryption

Because this is a non-trivial patch, I want to give the opportunity to
validate it before it is merged into the master.
You have to switch to the sub branch:
 git checkout AutoSendEncrypted
and build and install the xpi:
 configure
 make
 make xpi

NOTE: At least one thing is MISSING:
- the migration from the old preference
   confirmBeforeSend (bool)
  to the new
   confirmBeforeSending (int)
  QUESTION:
   To test the migration I need a new version number in the code
   The code still has 1.6.
   Is 1.7 appropriate?
   Where the THE right place to change that?

Please give any feedback you have.
The goal is to push it ASAP into the master
(as both features are something I'd really like to have).

Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Public key for enigmail

[Nicolai Josuttis]

BTW,
having two OpenPGP entries in two menu bars seems
to be a bit confusing.
Should we change the second to something like
 "Privacy" or "PGP Privacy" or "PGP Options" or so?

Am 14.02.2014 17:58, Patrick Brunschwig schrieb/wrote:
> 
> The easiest way is to open the OpenPG Key Manager (menu OpenPGP ->
> Key Manager), search for your email address and use Edit > Copy
> public keys
> 
> -Patrick
> 

-- 
Nico

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Public key for enigmail

[Nicolai Josuttis]

what you can do for example is:
- start to send a new email
- enable in the OpenPGP menu on the main menu bar:
   'Attach My Public Key'
- use this as attachment
  (it contains exactly what you are looking for)
- If an attachment is not appropriate:
  - send this email to yourself
  - open the attachment
  - copy and paste the contents



Am 14.02.2014 16:24, David Schilling schrieb/wrote:
> Thank you, but i'm trying to register at s ite that needs my public PGP
> key to register. I'm sure you know what i'm talking about-20-40 lines of
> leters and numbers. When i go to register they need a valid PGP key for
> correspondence. Thanks for your time
> On 2/14/2014 9:56 AM, Lachezar Dobrev wrote:
>>   There is an 'Attach My Public Key' option in the OpenPGP menu when
>> composing a new message.
>>
>>   Other than that 'My key' is technically any key that you have the
>> secret key for. Those can be viewed using the 'Manage Keys' in the
>> OpenPGP menu: they will have 'pub/sec' in the 'type' column. If you
>> can not see the 'type' column you may need to show it using the button
>> at the far right of the table header.
>>
>>   Commonly when you open the 'Manage Keys' screen and do a search for
>> your e-mail one (or more) key pairs will show bold (you have a secret
>> key for it).
>>
>>
>> 2014-02-14 16:47 GMT+02:00 David Schilling 
> :
>>>
> 
> How can i find my public key for enigmail, i'd like to send it to
> someone, and i can't find it for the life of me
> 
>>>
>>>
>>> ___
>>> enigmail-users mailing list
>>> enigmail-users@enigmail.net 
>>> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>>
>> ___
>> enigmail-users mailing list
>> enigmail-users@enigmail.net 
>> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 

-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Opportunistic encryption?

[Nicolai Josuttis]

It seems multiple people are going into the same directions.
I am currently also trying to improve the handling here.

In fact, I am about to prepare a paper that
- in detail explains the current implementation
- suggest improvements
regarding whether and when a message is send encrypted.

In fact the document will handle the questions:
- How do we decide whether to encrypt?
- How do we find the keys?
- Which options do/should we have to influence this process?

Because I started trying to understand the current state
and the code was really hard to read,
I submitted a pure code refactoring, Patrick applied already
with patch
 a37cb82adbb585c888a150e19740f3151a1510ae
So note that the code has changed (not in behavior
just as it is written).

I expect to have the design paper ready during the next couple of days.
Note BTW, I think it is a good idea at least to have the option
to automatically send emails encrypted in case we know all keys.
However, in this whole process a key question is how to deal
with bcc addresses (or if bcc addresses are present).

Best
 Nico


Am 10.02.2014 22:37, David schrieb/wrote:
> On 2/10/2014 3:59 PM, Jean-David Beyer wrote:
>> On 02/05/2014 09:48 AM, jan wrote:
>>> implement much automation into Enigmail. One major task would be
>>> automating to find keys for recepients and encrypt emails if
>>> possible.
> 
>> What good is it it encrypt e-mail to most of the recipients? If you
>> send it unencrypted to even one, have you not given up on
>> encryption? The black hats would not need to decrypt all the
>> messages sent, only one, and if one is unencrypted, that sure makes
>> their job easy.
> 
> 
> 
> 
> 
> How do you plan to send encrypted emails to people that do not use
> encryption?
> 
> 
> ___
> enigmail-users mailing list
> enigmail-users@enigmail.net
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
> 
> 

-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

IT communication  http://it-communication.com
SOA in Practice   http://soa-in-practice.com
C++ Standard Library  http://cppstdlib.com



0x8A1C44D0.asc
Description: application/pgp-keys
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] A meta comment for this discussion list

[Nicolai Josuttis]

Remember:

The pain with non-face2face conversation is that trust easily gets lost.
For this reason email is something so work very careful with,
because you easily assume that the other guy meant it worse than he/she did.

And, always keep in mind that it is a great pleasure that people here
use their free time to make enigmail better and help users.

Thus, we have to operate on the assumption that all people here do their
best.
And we all should appreciate that.

And, Jean-David and Doug, please continue to distribute.
We need all of you to help and improve.

-- 
Nico


0x8A1C44D0.asc
Description: application/pgp-keys
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] https://thedaywefightback.org/

[Nicolai Josuttis]

may be we should also add a banner ...
(and distribute the idea)
 Nico

-- 
Nico


0x8A1C44D0.asc
Description: application/pgp-keys
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Key Manager - column display

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Philip,

I can't confirm what you describe.
I also use Win7 64 bit.
I have all columns enabled and see all columns.
I there is not enough room, the horizontal scroll bar at the bottom
helps (you didn't overlook it, did you?).

Thus, if you really have the problem as you describe, something else
is different/broken.

Just another comment:
Enabling and disabling columns in this dialog uses the standard
technique of Thunderbird.
You have the same button in the main window to configure
which column to display for emails.
This might not be obvious, but it's consistent...

Hope this helps
 Nico

Am 02.02.2014 00:35, Philip Jackson schrieb/wrote:
> Hi,
> 
> I've now had a little more time to try the various possible
> columns that may be displayed in Key Manager.
> 
> It appears to me that, effectively, 'name' and 'fingerprint' are 
> alternatives that may not both be displayed at the same time.  In 
> any case, as soon as I select 'fingerprint' as a display column, 
> the 'name' column disappears off the left hand edge of the key 
> manager window even if it was the only column to be displayed 
> before the 'fingerprint' column was selected.
> 
> 'Fingerprint' will display in conjunction with other columns but 
> not with 'name'.
> 
> In fact the display is even more weird than that. I tried to set
> up the columns as shown on page 27 of the Enigmail Handbook v1.0.0 
> (which seems to be the latest edition ?) -- viz. Name, Key ID, 
> Type, Key Validity, Owner Trust, Expiry.
> 
> I get as far as Name, Key ID, Type but as soon as I select Key 
> Validity, the name column disappears off the left hand side.  The 
> horizontal slider goes far over to the left as well.  I can slide 
> it to the right but this just causes all the columns to disappear.
> 
> Other combinations of columns have undesirable effects too.
> 
> This I observed with Windows 7 64 bit, using Enigmail version 
> 1.7a1pre (20140101-0013).  I have checked it again with v1.6 and 
> find these same effects.
> 
> - Philip Jackson 
> Domaine le Theron Chemin du Theron 34210 Siran France
> 
> Tel : (+33) 468 49 80 53GnuPG Public Key : 0x23543A63.asc
> 
> 
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
- -- 
Nico
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS7gHiAAoJEN75/ICKHETQaVUQAJcIeenmdg1tKyBwatYxJztC
2Z7jF0/MNsIcgScRbb3IXZQY4AV/g+Exwhi83H/Z6fbhUCL6W4AXf1NO0TtD+G+r
9pJoKSC8enea7JAzRTGlytP9AATEDGJy5n9GyErZVO5ixOE7IeMHXpzOmECM3moT
0ZmeJvcKjpZEExRSiSvV9r5zy+yuuZLdZeXDtcHR0AOh/te5XAPkiXz/ZIiah6IB
2U1ipJYgk0g1lXkN8kBWNSe4kAQqqQNuwlnnxJ2sSy+V8CjNwb9wa1WaiPKLSTZL
17n1ZDNP/Dafau8qkAc7is0hkqW/xlLODrAnuPde3SfS1ELZYwvUs7ZcPVES9yxL
qRsfPoCxGvWNwC9+bMvEGPQKigFe+ayKA+e0S4ZexCJ3bIr4JGaXvJvXLqKqovZX
b9pivGdO0ExqjO3vCukTfdLEFmejLoXbQrDyjbkJ1RQJaLXGqWLYhHnmSdTzJ4wl
CVjlBPiu6QYTs01oYq2EUlBmLf/CSZIHLtZQLoK0VGJ30GcaLvLSz2GjJsyRzvHm
twF66Fy29nNJtdIV9+A9sOre7fQaYEBOa0V3O05q9wW+Jqdt8Gb5QI/Vr+TSMEpE
X0uZ/Mj+4KqyJ0DCdqZeZuCTo0KgtHB5UiYKWMrXhGAC3bf4EFxmUF5veQrMFKXf
j0ksPUeUe7wy3E4QIon3
=U6Y0
-END PGP SIGNATURE-


0x8A1C44D0.asc
Description: application/pgp-keys
___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] what is a good way to deal with conflicting recipient rules

[Nicolai Josuttis]

Am 31.01.2014 15:25, Nicolai Josuttis schrieb/wrote:
> 
> Hi,
> 
> currently, not many of the people I exchange emails with use PGP.
> For this reason, I have some receiver rules (usually enabling PGP)
> and by default encryption disabled.
> 
> Now, if I send emails to multiple receivers I always have to
> check "ignore receiver rules" or
> get the dialog about missing keys for receivers.
> 
> I wonder now, how we could make that better (less annoying).
> 
> I have thoughts about a couple of improvements,
> but I am not sure which one is the best:
> 
> - May be we add an option so that the dialog for missing key
>   has "send message without encryption" ON by default
>   (while any additional selection of a missing key turns this off).
> 
> - May be we should add an option so that I can enable
>   that recipient rules have less priority when multiple
>   users are selected.
>   Or even more general, provide a general option to chose between:
>   - conflicting recipient rules start dialog for missing keys
>   - if there are conflicting rules, choose the weakest ones
> (ideally with an optical feedback that we have this case here)
> 
> - Also the list of suggested keys when keys are missing
>   should (optionally)
>   - not propose invalid/disabled/revoked keys
oops, sorry, forget this, we have that already
>   - only list names that "somehow" match
> (i.e. a part of the name email address should match).
> But details are hard here to decide.
> 
> - Provide an ability to ignore recipient rules with one click.
> 
> Has anybody else ideas or opinions or comments?
> I definitely want to solve this issue sooner than later
> to make my life with enigmail easier.
> And of course any solution should go in the right direction
> for enigmail in general.
> So, before I go into the wring direction, I welcome any feedback.
> 
> Best
>  Nico
> 

-- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

SOA in Practice   http://soa-in-practice.com
IT communication  http://it-communication.com


___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] what is a good way to deal with conflicting recipient rules

[Nicolai Josuttis]

Hi,

currently, not many of the people I exchange emails with use PGP.
For this reason, I have some receiver rules (usually enabling PGP)
and by default encryption disabled.

Now, if I send emails to multiple receivers I always have to
check "ignore receiver rules" or
get the dialog about missing keys for receivers.

I wonder now, how we could make that better (less annoying).

I have thoughts about a couple of improvements,
but I am not sure which one is the best:

- May be we add an option so that the dialog for missing key
  has "send message without encryption" ON by default
  (while any additional selection of a missing key turns this off).

- May be we should add an option so that I can enable
  that recipient rules have less priority when multiple
  users are selected.
  Or even more general, provide a general option to chose between:
  - conflicting recipient rules start dialog for missing keys
  - if there are conflicting rules, choose the weakest ones
(ideally with an optical feedback that we have this case here)

- Also the list of suggested keys when keys are missing
  should (optionally)
  - not propose invalid/disabled/revoked keys
  - only list names that "somehow" match
(i.e. a part of the name email address should match).
But details are hard here to decide.

- Provide an ability to ignore recipient rules with one click.

Has anybody else ideas or opinions or comments?
I definitely want to solve this issue sooner than later
to make my life with enigmail easier.
And of course any solution should go in the right direction
for enigmail in general.
So, before I go into the wring direction, I welcome any feedback.

Best
 Nico

-- 
Nico

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] per recipient rules not in menu

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I still suggest to have this option entry enabled even without the
expert mode enabled ;-)
And I could easily push a fix/patch ;-)

Am 30.01.2014 14:29, Anna Morris schrieb/wrote:
> 
> 
> On 30/01/14 13:06, Philip Jackson wrote:
>> Did you check the OpenPGP/preferences in Thunderbird ?  If
>> 'Display Expert Settings' is not selected in preferences,
>> Thunderbird does not display the OpenPGP/Edit per recipient rules
>> (and others are misiing too).
> 
> thanks, this fixed my problem - good call!!
> 
> :)
> 
> Anna
> 
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

SOA in Practice   http://soa-in-practice.com
IT communication  http://it-communication.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS6lpeAAoJEN75/ICKHETQmEwQAIdTg52plI/KygxSu+qAc2B6
SIRbO7mjD5pMWLrsnrH8VUMwM7+N3dMBDoElMKSbXNuFjW4ieKhDMH5BPqxyia3g
w1V9MFic5V6MO6bVHyCB5AYOFpxF1Qsvw0OrZFL4jJU88sit+gWGoOJabyXZjxMo
Ik2pBzax+DFenBqm2s8irTR5PLv94vcNYXqTNSYkGo9vbYVq7byL73q0a0PXBaB+
XeqlpUV5RHmkxGqlvGQo0H7oVSp+4ieRl2oq5A2TjjcTdse12+5i3WAxncikMuP1
1UyR2lrlR6HNFB1z4B7gp/blt+MKP++zjrS1CHSCV8L05nag19wFzm5nV6jzxW9p
1jRz0/YClLibZP6i+sr0mUYblM7pIJtSYqkNmLOfaUU4kKR+U2+8ITY1UnVzXvlz
/jvHtwQCX+HYBrrbG4G+IWMNE4Bnp2gOshO5HmuAVhxiZBLEhaWEm5falqdU58OU
nKDuS6pN7kUbxmQjFd8QzIw1EuQHFbkcmNpFs7Yrjbz88zZV5nbFi22ck8uJeyf7
T0XFvkKslB7C/1JpXWIY0CwS0B2CvEfSLG+QYRkEES1oNXRij97VEIf5HLsfHbeg
Xktjyt2XIHC+NRE1dp/WSjIe9NGZUKVvazJ0OhL98zl/Q/EqELyudjyxFTeXfu3c
v/6PNrpwMsBXVkrHN6nq
=NrQc
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] Process details about fixing bugs and adding new features

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks Patrick,
making it standalone is a HUGE step.
For what it's worth: I just compiled successfully enigmail
with cygwin on my Win 7 system and could load the resulting xpi
into my Thunderbird.

Before I start to help to fix/add issues now directly
instead of requesting them, I wonder how in general contribution
directly in the source code is organized:
- - What is the policy for modifications in the git repo?
- - (When) Should improvements be discussed before done?
- - Is there a review process?
- - How is ensured that fixes don't break existing stuff?
- - Should there usually be a branch for each new feature?
- - Is there a convention such as that each fix should have
  an ticket in its name?
- - Or can I forget about all these questions because I can't commit
  directly and have to submit patches?
...
Or (meta question) are answers to all these questions somewhere given?

Finally:
- - I am glad to help to improve the web site accordingly
  (such as explaining this process once I got it).
  How can?
  (ideally the web site also would be a git repo)

Best
 Nico


Am 12.01.2014 17:35, Patrick Brunschwig schrieb/wrote:
> This is a message targeted to everyone who builds Enigmail on their
> own, in particular all Enigmail package maintainers for Linux and
> *BSD.
> 
> I have rewritten the build system of Enigmail from scratch. The new
> build system is now completely decoupled from the 
> Thunderbird/SeaMonkey tree, i.e. as of now (or the next Enigmail 
> release) it is no longer required to build Enigmail from within a 
> pre-built Thunderbird tree.
> 
> The new build steps are now as follows: 1. ./configure 2. make 3. 
> make xpi
> 
> The resulting XPI file will reside in the build/ subdirectory.
> 
> The top-level make supports the following targets: all   - 
> build all of Enigmail xpi   - create XPI file clean - 
> delete all generated files distclean - delete all generated files 
> incl. results of "configure".
> 
> The new build system should also allow for cross-compilation, but I
> did not try this yet. The web page will be updated soon.
> 
> -Patrick
> 
> 
> ___ enigmail-users 
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
>
> 
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86
+49 (0)700 / 5678 
+49 (0)700 / JOSUTTIS

SOA in Practice   http://soa-in-practice.com
IT communication  http://it-communication.com

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJS6lnOAAoJEN75/ICKHETQqMUQALsTnwG5E1g61/3yE39s/bRo
MsNh+fJAZM4gZCmRdtbZfxCLshe4YXnn5QkGmTSVCIuaOWJOdUcCnoxRqUcFiJiu
1W8/ZFF953FMhnc264ZOOMOAXNg0TeQ4kKWBRTZalywNWnKoPgkp2ES0kGR31QeN
3fxZ0GjVIeu/BTULb1HRY0mIJ/vbef/0xvNQqxKsPsbUQkeYmvyPW714rv7G0mUg
0tsYNmBtCv3a1DxbLR+LuN4qRxrZsbun6IqPoJuKCrJruTk9MAwlrcBO7+6G/7M7
z/KMNfykXuY1ttrB7xn25zXlCz2wAzVrQ8ZL/HkFup4msIS8qlRKZuqjjTU35Z4Q
Rczy/CbEXQy3+dHO4saT6iyAZcpIKGyytvQH4/QCvIt4PCkBLAQY6z2cIi9aed3U
4sDdniIECHN8EOiBebBn5NtjNNa1sX7ZXEVGSxj6YLZR3pD3IPoHCvQ4MBzWj6KE
UwN5kOVFDxYJybeRXJQ/TaR4bKsW/a2QalVrxh7Dii7phbASal3moF8bIRx1QI4O
0PlfkehlUvV6vd0h4p+oDu2pyvVy2Ia6jAU5TGHmqc7vYHpdCS9hOeXssolWk+ut
4J84YCcfVuRnuW0I0fxajjJLL8as6Vj6pDkCPf88pRdY3IMpdfXXIJ8m823zypyl
bbHd50ALfe4Qp2v79eeN
=iv9O
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] update quick starting guide

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So the source of the QSG is LaTeX and we (sorry, you) generate the web
pages from it?
(This would be great news, because LaTeX is something I am VERY
familiar with (having written all my books and some manuals with)).

Can I have details about where to find the QSG sources, then?
(Ideally, they should be part of the GIT repo, shouldn't them?)
What is the current state?
Is somebody working on it right now?

Best
 Nico

Am 03.01.2014 17:58, Ludwig Hügelschäfer schrieb/wrote:
> On 03.01.14 17:41, Ludwig Hügelschäfer wrote:
> 
>> (...) I don't know whether there is a common source which is not 
>> published.
> 
> There is a LaTeX source, held by Robert: 
> https://www.enigmail.net/list_archive/2011-September/014377.html
> 
> Ludwig
> 
> ___ enigmail-users
> mailing list enigmail-users@enigmail.net 
> https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
>
> 
> 

- -- 
Nicolai M. Josuttis
www.josuttis.de

+49 (0)531 / 129 88 86


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSxvOdAAoJEN75/ICKHETQRRwP+gILOJkvMyCCEtdT2Hd+kaM4
yumyDXAeiRcfujOxwj+bMJwohhkVc1O1WTpw6zv1Ru4qGGU2JeR+xZf0o5KnTMHM
y1vePcRQMA/DhQ8YR8iD5SModywg8nMeujUzRPZ2eZHGi7EG9MKNgCC+yP4MtQIk
POz/dD8ZVWnNbbXDeRzUMjnIJe6QijwxZjFLVX9XSZO+UfBREm/WCZ/49J7/G5pI
WsofIT7l+S/r0SUvTeguOm3TgxThzRenQG7H8SX6+5nVKsZMvlhfGrpwzUQ4yUMQ
h0TPBYxDKKqa9ndPpaejMHgKTe0hottrc+Czz0KdCZbDACr0Ws5LyDfe8wQ6c7Gn
lQGo9lPYfcxO2k7sfsQwbb6NwTdIF382hhIcRePbB5o+waftTBJYvAqMN7MbT5Zh
RtO4kaMF2otikDwfdGeXx2eEyAbcgkkjd6z19+OPln6iCBDinSHzGK4JeDfTmB0C
wwe5kRdrnNIsi8V25RYOoMP5lTZF2tJ2AlCijnK+VmW5WMg7UdrfAeP2nx4RLocU
iG70t7V4WMb1rVlDsD84IiOZAd24u5uetXKoIn1OA6R7mKuCBJv4B224JXKtxZE7
RubB0b2Q8AFi96ryQWVS0CsbrNA9EhUN+QWH/j7UhAk3dImmZ1uXVWItP+XmsvuB
g9pI9z/TfEPsFna5stxK
=pb0B
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

Re: [Enigmail] Improve experience for first time users significantly

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the feedback.

For more see below.

Am 03.01.2014 16:17, Patrick Brunschwig schrieb/wrote:
> 
> On 31.12.13 14:45, Nicolai Josuttis wrote: [...]
> 
>> I was very confused because again and again I found no way to 
>> define per-recipient rules (although several places referred to 
>> them, such as when sending an email the menu entry "Ignore 
>> Per-Recipient Rules").
> 
> When we initially discussed the "basic" user mode in the team, we 
> considered per-recipient rules an advanced feature. I personally 
> believe that this is still true, therefore I'd prefer to hide the 
> corresponding menu entries (as I intended but apparently failed).
> 
Well, think I still disagree
(but you may be more experienced).
It depends a bit what a non-expert is:
- - If it is somebody who only tries enigmail out, then
  setting privacy options explicitly each time
  is probably OK.
- - If it is somebody (like me) who wants to establish
  privacy in his own email correspondence,
  then the usual scenario will probably be:
  - disable privacy (encryption) in general
  - but enable it for those you know that they can deal with it
  Then, it is a must to be able to see and modify the rules easily.

>> Thus, it should be possible "for dummies" to define and see
>> these rules.
> 
>> My suggestions:
> 
>> - Provide in the OpenPGP Status Bar -> Details menu the same
>> menu entry as for the popup menu for email addresses: "Create
>> OpenPGP Rule from Address..." This would have been for me the
>> "natural place" for that (and it really took me a long time to
>> find it at the email address). But keep the other too (because
>> others might have other "natural places").
> 
> I presume you mean a rule for the sender's address?
> 
Indeed

>> - When a rule is defined, replace the ability to define a 
>> recipient rule by the ability to EDIT the existent recipient
>> rule. Thus, (at both places ;-) ) replace: "Create OpenPGP Rule
>> from Address..." by "Edit OpenPGP Rule from Address..." starting
>> the modify rule dialog with the current settings instead of from 
>> scratch. (If switching the menu entry is not appropriate rename
>> it to "Create/Edit OpenPGP Rule from Address...".)
> 
> This works, if the per-recipient address is for exactly 1 email 
> address. But you cal also have rules like "ends with"
> "@example.org", and rules with multiple email addresses. The menu
> entry would therefore only edit an existing rule if the email
> address matches exactly.
> 
I see the point.
First, adding a new rule makes no sense in any case here. So this has
to change.

Depending on the effort I suggest something like:
- - If there is an exact match,
  start the rule editor for that exact match
  (this is what novices will expect).
- - If there is no exact match, you can:
  - start the rule editor ;-)
- optionally with only the rule(s) that would match
  - start the dialog with the rule that would currently apply
and IF there is a change in where the rule applies to
print a warning or add questions to ask whether to add
or replace the existing rule that covers a different group
of receivers.
Alternatively, as a simple approach:
- - If there is a rule that already applies,
  always start the rule editor instead.
  That's probably the easiest and most intuitive solution.

>> ...

>> - Ensure that users understand that the "Display Expert Settings"
>>  also influences the global and email menus. I was very
>> surprised about that, assuming that I only enable or disable the
>> additional setting tabs. May be a better wording is enough such
>> as "enable expert mode (options and menu entries)"
> 
> Good idea.

>> - Give better feedback, which algorithm is used for the key. One 
>> reason is that key certification (such as the heise crypto
>> campaign in Germany, see 
>> http://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html)
>
>> 
> 
> see
> http://www.heise.de/security/dienste/Krypto-Kampagne-2111.html)
>> require the information whether this is a RSA or a DSA/ElGamal 
>> key. THUS: - The setup wizard should mention which algorithms is 
>> used in the summary - In the key management/selection dialogs add
>> a algorithm column
> 
> I don't see why a beginner would really care for the algorithm
> used. Once you'll need your fingerprint, you'll probably get to the
> key details window, where you'll see the fingerprint and the
> algorithm(s) used.
> 
Again, what do we consider as a beginn

Re: [Enigmail] update quick starting guide (was: Improve experience for first time users significantly)

[Nicolai Josuttis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 03.01.2014 16:05, Patrick Brunschwig schrieb/wrote:
> 
> ...
>> On 12/31/2013 08:45 AM, Nicolai Josuttis wrote:
>>> Hi all, ... 2) Improvements on the documentation 
>>> 
>>> 
>>> Well, obviously, you have not enough time to maintain the home
>>>  page and quick starting guide (though, I might be able to 
>>> help). So, at least you should say so and stop to refer to the 
>>> quick starting guide and refer to the handbook instead.
>>> 
>>> Also, you should remove the hint to install GnuPGP first. - 
>>> This especially might to imply to remove the hint that the 
>>> Add-on requires GnuPGP. As any requirement is a burdon, you 
>>> should remove that hint or replace it by "uses GnuPGP" or so.
>>> 
>>> Hope this helps for the moment and is useful feedback. Feel 
>>> free to contact me directly at n...@josuttis.de. Best Nico
>>> 
> 
>> ...
> 
> You're most welcome to fix/improve/rewrite the mentioned documents.
> I'll be very happy to publish. I'm aware that the quick start quide
> and other documentations should be improved especially as any new
> features (such as automatic downloading of GnuPG) are not covered.
> 
> Thanks, Patrick
> 
How is the quick starting guide currently written?
Is there a common code base (such as a Wiki or GIT repo) for both the
HTML and PDF version, which allows others to easily fix/update things?
Thus, how could I get the ability to edit/update the guide?

- -- 
Nicolai M. Josuttis
www.josuttis.de

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSxuNmAAoJEN75/ICKHETQSbkP/0l+LUqN8WpRUHIP2kvmyNPX
s5sa2M431tTeVrje7V3fYQJmHwHoqU2gZ5T8z2adLEp1gC6qgV7FqAin4A2mHLwl
tRFLMWTABHi5DtLVRDnF4Kg/4/ETJZyPiic2IBlOtuhd0KvMlA1aY4wdYaAiar/h
vy6OLcnsjSWVm+dKnC3XNfqOAhsQOqKX5ugCy//Xg1bnQLV3FJWTVpeCesAPLoOm
96BUt+Dp3b9cVTNSjZt2UQIkdgNeF5DN9DRo/6fhNYvmzDVMV7TmHJUP5bvcjbQg
4/YddOiWzk/kw8Z9vAmXuk6vvCcgq5qSUDkk4FXOqvtipt198kVxks5ZF8yUOL5h
uV6V5iO4EWbhmD7I3xujQDY6Tv7vDwn0Gz5nKe3ghIxZ8n8Iurq9ikTf/ocDK4+j
rDYnhrItAjU4u7lzlIka0/dRRQyBOpTW9e3hmKhJtEpziIrWJKhHKG5KYGAuWUxW
J0Sz+W/qJcu3OxMELUFEYYLcfIYa1VvNaiXu/vGWbQ9xZBobbxh/xUMjj04hTqsd
ZPbV7J89mA9PgP8fk0Ykb/W5BqJW/EEfscx5DDFQY0FgfkYblhusnYHD2doPgktb
nFBT9iSCVbxSOfVhYmo1XWZMk7zga114e80vHdXgq15KEbf8ZCPDUBFm2OH4nzpb
epBpPps52MwYwor58byH
=71G1
-END PGP SIGNATURE-

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net

[Enigmail] Improve experience for first time users significantly

[Nicolai Josuttis]

Hi all,

I just double checked how to install Enigmail with Thunderbird and have
a couple of (IMO important) improvements to help first time users to
start with email privacy.
My personal experience is based on
 Enigmail 1.6
 Thunderbird 24.2.0
 German version
But I tried to translate all entries into the documented English strings.

My feedback has two parts:
1) Improvements on the product
2) Improvements on the documentation


1) Improvements on the product
==

(highest priority according to my opinion first)

a) provide better access to "Edit Per-Recipient Rules"

I was very confused because again and again I found no way to define
per-recipient rules (although several places referred to them, such as
when sending an email the menu entry "Ignore Per-Recipient Rules").

Thus, it should be possible "for dummies" to define and see these rules.

My suggestions:

- Provide in the OpenPGP Status Bar -> Details menu
  the same menu entry as for the popup menu for email addresses:
   "Create OpenPGP Rule from Address..."
  This would have been for me the "natural place" for that
  (and it really took me a long time to find it at the email address).
  But keep the other too
  (because others might have other "natural places").

- When a rule is defined, replace the ability to define a recipient
  rule by the ability to EDIT the existent recipient rule.
  Thus, (at both places ;-) ) replace:
   "Create OpenPGP Rule from Address..."
  by
   "Edit OpenPGP Rule from Address..."
  starting the modify rule dialog with the current settings instead
  of from scratch.
  (If switching the menu entry is not appropriate rename it to
   "Create/Edit OpenPGP Rule from Address...".)

- Think strongly about providing the rules editor as a non-expert
  global menu entry.
  My first assumption was that because almost everybody will have
  individual settings for different receivers,
  the "Per-Recipient Rule Editor" should be a basic feature
  (for both defining the rules and listing the rules).
  As we refer to these rules pretty often in non-expert mode
  it is a bit odd not to be able to see the current settings
  (especially because of the next issue).

- Ensure that users understand that the "Display Expert Settings"
  also influences the global and email menus.
  I was very surprised about that, assuming that I only enable
  or disable the additional setting tabs.
  May be a better wording is enough such as
   "enable expert mode (options and menu entries)"

- Give better feedback, which algorithm is used for the key.
  One reason is that key certification
  (such as the heise crypto campaign in Germany,
   see
http://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html)
   see http://www.heise.de/security/dienste/Krypto-Kampagne-2111.html)
  require the information whether this is a RSA or a DSA/ElGamal key.
  THUS:
  - The setup wizard should mention which algorithms is used
in the summary
  - In the key management/selection dialogs add a algorithm column


2) Improvements on the documentation


Well, obviously, you have not enough time to maintain the home page and
quick starting guide (though, I might be able to help).
So, at least you should say so and stop to refer to the quick starting
guide and refer to the handbook instead.

Also, you should remove the hint to install GnuPGP first.
- This especially might to imply to remove the hint that the
  Add-on requires GnuPGP. As any requirement is a burdon,
  you should remove that hint or replace it by "uses GnuPGP" or so.

Hope this helps for the moment and is useful feedback.
Feel free to contact me directly at n...@josuttis.de.
Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de

___
enigmail-users mailing list
enigmail-users@enigmail.net
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net