On Wed, 15 Feb 2017 00:31, d...@fifthhorseman.net said:
> afaict, GnuPG only supports (1) at the moment (this is probably OK).
There is a plan to add a rewrite feature to gpg so that for example you
can easily add an archiving key to a message. But that is something we
need to shift to 2.3.
> H
On Tue 2017-02-14 15:08:25 -0500, Werner Koch wrote:
> I don't think that --throw-keyid is a useful thing for use of gpg
> in mails - it does not really help in this use case because that meta
> data is easier available by other means.
I absolutely agree with this assessment, and i also agree with
> ... while adding another option may fix every small problem at hand, it
> creates a huge one that is even harder to fix: We have way too many
options
> already.
Some years ago I had the wild urge to set up Prolog code that would
determine the necessary command-line flags to sustain certain opera
On Tue, 14 Feb 2017 15:27, d...@fifthhorseman.net said:
> I'm open to other suggestions about how to achieve this behavior.
There is an old FIXME in the code which needs to be removed:
/* FIXME: Store this all in a list and process it later so that
we can prioritize what key to us
Daniel Kahn Gillmor writes:
> On Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote:
>> I don't. I strongly believe that adding command line switches should be
>> the absolute last resort.
>
> I'm open to other suggestions about how to achieve this behavior.
I have none, and tbh I did not even
On Tue 2017-02-14 05:28:07 -0500, Justus Winter wrote:
> I don't. I strongly believe that adding command line switches should be
> the absolute last resort.
I'm open to other suggestions about how to achieve this behavior.
GnuPG's general stance appears to be that the only way to interact with
t
On 13/02/17 17:54, Lukas Pitschl | GPGTools wrote:
> As fallback gnupg could return the information that no cached passphrase was
> found,
> allowing the MUA or plugin to then re-try without the option that enables
> „silent“ checking.
Maybe GnuPG already does this, but instead of a two-step pro
Daniel Kahn Gillmor writes:
> [ Unknown signature status ]
> On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote:
>>> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor :
>>>
>>> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
Step two: Encrypt using gpg --throw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kahn Gillmor wrote:
>
> You don't get the luxury to decide on this transition yourself,
> i'm afraid. Mailpile has to deal with *other* MUAs doing
> throw-keyids, just like those other MUAs have to deal with it
> if/when Mailpile starts doing
On Mon 2017-02-13 18:35:17 -0500, Bjarni Runar Einarsson wrote:
> Sounds like a nice optimization... but option bloat is a thing too.
for an API, there's nothing wrong with explicitly specifying the thing
that people should *want* to be doing as a separate interface.
GnuPG has some level of diffi
On Mon 2017-02-13 11:54:04 -0500, Lukas Pitschl | GPGTools wrote:
>> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor :
>>
>> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
>>> Step two: Encrypt using gpg --throw-keyids.
>>>
>>> This is easy on the sender's end, but whether thi
> Am 13.02.2017 um 17:34 schrieb Daniel Kahn Gillmor :
>
> On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
>> Step two: Encrypt using gpg --throw-keyids.
>>
>> This is easy on the sender's end, but whether this feature can be
>> used as a matter of course depends on how it impact
On Mon 2017-02-13 06:41:51 -0500, Bjarni Runar Einarsson wrote:
> Step two: Encrypt using gpg --throw-keyids.
>
> This is easy on the sender's end, but whether this feature can be
> used as a matter of course depends on how it impacts the
> experience of the recipient.
Agreed that the recipient's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
Context: I am trying to figure out how much visible metadata I
can remove from an encrypted e-mail before it becomes completely
unusable.
Step one: stripping stuff from the message headers is relatively
easy; minimal messages with all recip
14 matches
Mail list logo