Re: [Enigmail] test implementation for auto encryption available in test-branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20.04.14 15:30, Nicolai Josuttis wrote: 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? The only place this is relevant is in install.rdf. Release numbers are not only technically driven. Therefore I only modify this once I decide to create a new release. 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). 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 - -Patrick -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEVAwUBU1PeTck25cDiHiw+AQgvpQf/dICgR5tO9dPqSqpL2jxtHmlfRGarvlKG siPu3CbyZE6PA7RETFAusUcAFXsmQ33KnOfKozn/lQUHcgduFC4JvwVnbLpW8k5Z uIyY33kE+5RA/GR1z8gdn8qumy2ZDY4cZSZCm5o+vLTEXXcRW8BtSgoudObbBhl5 9VYjnDzCa8VnlMy2ogwjlo+I/Y9wPgUNLzvGO7eOYRLVEyaW9K13oyD4NVeMR+D7 Lo6pzwamZW5KKIF0DLkdFPUZumxAlzQbsECCTV16I5ws3AzaqE6OKNBLH5qs7pBK D1YEN93b++Jpp3tnvVX9WPyKfM+UudYhbp37qgXSacdYxm93ZfdW/Q== =uGLX -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
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
Re: [Enigmail] test implementation for auto encryption available in test-branch
-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 current labels can be improved) ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net - -- Nicolai M. Josuttis www.josuttis.de -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
Re: [Enigmail] test implementation for auto encryption available in test-branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/2014 00:12, Nicolai Josuttis wrote: 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 think the display of your new options at the same time as the second check box item (Always trust people's valid keys) presents a confusing display. A display logic should be decided that prevents them both being displayed at the same time. 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). see below - - 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) The question of 'dangerous' puzzles me somewhat. Where is the danger in trusting a key ? You are implying that one should not encrypt to a person whose key is untrusted - whether in the sense of its validity or of its owner's trust. There could be danger to some people in the mere act of being seen, by an observer, to be using encryption and in those circumstances, the trustworthiness of the owner or the key would be irrelevant. But even if the key validity has been fully ascertained, and the owner is 'fully trusted' in the sense that applies to the web of trust, one would have to consider the nature of the material (secrets) being written in the message - - and here again, the gpg trustworthiness of the owner and the key validity are not the most relevant factors. What is more relevant are the personal qualities of the owner - will he betray you ?, is he a stooge planted by the enemy/competitor? These are not questions that gpg web of trust or key validity can answer. My thoughts are that the more emails that can be encrypted, the better. A higher volume of encrypted mails provides a better safety screen for all so it is better to 'trust all keys' and to be extremely careful what you write if you do not know the recipient. 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.
Re: [Enigmail] test implementation for auto encryption available in test-branch
On 04/20/2014 07:12 PM, Daniel Kahn Gillmor wrote: 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. --dkg signature.asc Description: OpenPGP digital signature ___ enigmail-users mailing list enigmail-users@enigmail.net https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
