-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24.04.14 20:52, Mike Acker wrote:
> On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote:
>> FWIW, i fully agree that the right place to fix this misbehavior
>> is in GnuPG itself, not in enigmail. I care about non-enigmail
>> users of GnuPG, and i
Daniel Kahn Gillmor wrote:
> [skipping a bunch of discussion covered elsewhere in the thread and
> jumping directly to the UI/UX proposals]
>
> On 04/22/2014 05:00 PM, Philip Jackson wrote:
>
>> and perhaps if the time since {valid] status was conferred is greater than
>> some specified interval,
Daniel Kahn Gillmor wrote:
> On 04/24/2014 06:39 PM, Mike Acker wrote:
>
>> one more time: all that happens in ENIGMAIL calls GnuPG passing a user (
>> -u ) argument . if that argument is just an e/mail address GnuPG won't
>> have enough information to find the key you want if there are two or
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/04/2014 22:19, Daniel Kahn Gillmor wrote:
> [skipping a bunch of discussion covered elsewhere in the thread and jumping
> directly to the UI/UX proposals]
>
> On 04/22/2014 05:00 PM, Philip Jackson wrote:
>> What about some consideration of the
[skipping a bunch of discussion covered elsewhere in the thread and
jumping directly to the UI/UX proposals]
On 04/22/2014 05:00 PM, Philip Jackson wrote:
> What about some consideration of the time elapsed since [valid] status was
> conferred ?
Is this the right time limit that a user should be
On 04/24/2014 06:39 PM, Mike Acker wrote:
> one more time: all that happens in ENIGMAIL calls GnuPG passing a user (
> -u ) argument . if that argument is just an e/mail address GnuPG won't
> have enough information to find the key you want if there are two or
> more keys in the keyring with that
On 04/24/2014 06:39 PM, Mike Acker wrote:
> On 04/24/2014 04:23 PM, Daniel Kahn Gillmor wrote:
>> On 04/24/2014 02:52 PM, Mike Acker wrote:
>>> On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote:
FWIW, i fully agree that the right place to fix this misbehavior is in
GnuPG itself, not in en
On 04/24/2014 04:23 PM, Daniel Kahn Gillmor wrote:
> On 04/24/2014 02:52 PM, Mike Acker wrote:
>> On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote:
>>> FWIW, i fully agree that the right place to fix this misbehavior is in
>>> GnuPG itself, not in enigmail. I care about non-enigmail users of
>>>
On 04/24/2014 04:59 PM, John Clizbe wrote:
> Good luck with changing the behavior of GnuPG ;-)
Werner has suggested that 2.1 would actually perform key selection
differently, perhaps because the proposed keybox store has no innate
sense of linear order in the first place. dunno when that'll happe
Daniel Kahn Gillmor wrote:
> On 04/24/2014 02:52 PM, Mike Acker wrote:
>
>> which, as noted, is why they have per recipient rules
>
> I know that Enigmail has these rules, and that they are a way to work
> around GnuPG's suboptimal key-selection-from-email-address routine. I
> think there may be
On 04/24/2014 02:52 PM, Mike Acker wrote:
> On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote:
>> FWIW, i fully agree that the right place to fix this misbehavior is in
>> GnuPG itself, not in enigmail. I care about non-enigmail users of
>> GnuPG, and i definitely don't want to have the headache o
On 04/23/2014 10:33 PM, Daniel Kahn Gillmor wrote:
> FWIW, i fully agree that the right place to fix this misbehavior is in
> GnuPG itself, not in enigmail. I care about non-enigmail users of
> GnuPG, and i definitely don't want to have the headache of synchronizing
> key selection routines of mul
On 04/23/2014 09:18 PM, John Clizbe wrote:
> Philip Jackson wrote:
>> On 22/04/2014 01:30, Daniel Kahn Gillmor wrote:
>>
>>> 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.
Philip Jackson wrote:
> On 22/04/2014 01:30, Daniel Kahn Gillmor wrote:
>
>> 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 keyri
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/04/2014 01:30, Daniel Kahn Gillmor wrote:
> Hi Nico--
>
> thanks for your work on this; i'm really glad to see people thinking it
> through in detail.
>
> Responses in more detail below, along with a more radical proposal that
> hopefully w
Hi Nico--
thanks for your work on this; i'm really glad to see people thinking it
through in detail.
Responses in more detail below, along with a more radical proposal that
hopefully we can use to think through the desired behavior.
On 04/21/2014 04:11 PM, Nicolai Josuttis wrote:
> Let me try t
-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".
>
> th
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:
>
> Automatica
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
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 t
Hi Nicolai, all--
On 04/20/2014 09:30 AM, Nicolai Josuttis wrote:
> a first implementation to provide the ability to
> automatically encrypt messages if all valid keys are known
this is a neat idea, but...
> without the need to have a rule for it
> into the sub-branch (derived from master):
>
-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 downlo
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
> 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 mas
-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
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 b
28 matches
Mail list logo
