Entering passphrase twice when sending PGP signed message

Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

[ Please keep the Cc to me if you want me to see the responses. ]

I tried to gpg-sign a message I was sending.  Everything went fine,
except for one detail: I was asked for passphrase twice, once (I
think) before the mail was sent over the network, and once immediately
afterwards.

Since I have archiving turned on, I assume the problem is that the
message is signed both when it is being sent and when it is being
archived.  That sounds like a bug.  What do you think?

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> [ Please keep the Cc to me if you want me to see the responses. ]
>
> I tried to gpg-sign a message I was sending.  Everything went fine,
> except for one detail: I was asked for passphrase twice, once (I
> think) before the mail was sent over the network, and once immediately
> afterwards.
>
> Since I have archiving turned on, I assume the problem is that the
> message is signed both when it is being sent and when it is being
> archived.  That sounds like a bug.  What do you think?

This happens if you use Gcc, and it is because the message is encoded
once for sendmail/SMTP/NNTP and once for the Gcc copy, as you assume.
But this can't be fixed easily, because the copy that is Gcc'ed is not
the same as the one that is mailed or posted.  An extreme example is
the `gnus-gcc-externalize-attachments', which make Gcc differ
distinctly from the SMTP/NTTP version of the mail.  The more subtle
examples are charset handling, news differ from mail, so making gcc
equal one of them still wouldn't solve the problem in general.

So unless someone has a clever idea how this could be solved, I think
we should consider it a feature.  There are alternative solutions,
e.g. Bcc, which would give you a exact copy of what is sent on the
(SMTP) wire.  Perhaps the g-g-e-a variable also save the MML PGP
headers directly.

Another approach would be to attack the source of the problem,
passphrases.  The gpg-agent seems like a good solution to that.

Re: Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

[...]
> So unless someone has a clever idea how this could be solved, I think
> we should consider it a feature.

Your examples are good, but I disagree with the conclusion.  Just
because suboptimal behavior is hard to fix doesn't make it a feature.
I'd classify it as a hard-to-fix bug, no more, no less.  Typing a
passphrase once per message is annoying.  Having to type it twice is
really really bad.

How about remembering the passphrase and reusing it the second time?
The passphrase would be forgotten the moment the mail sending process
is finished.  At first that sounds like a violation of passphrase
privacy, but think about it: as long as the string is not copied
around, it's no more dangerous to use it twice and delete it than to
prompt for it twice, deleting it each time around.

Re: Entering passphrase twice when sending PGP signed message

[Jesper Harder]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> [ Please keep the Cc to me if you want me to see the responses. ]

You can use "Mail-Copies-To" and/or "Mail-Followup-To" to request this
automatically.

> How about remembering the passphrase and reusing it the second time?

I think this is supposed to happen automatically -- or did you change
the default setting of `pgg-cache-passphrase'?

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> How about remembering the passphrase and reusing it the second time?
> The passphrase would be forgotten the moment the mail sending process
> is finished.  At first that sounds like a violation of passphrase
> privacy, but think about it: as long as the string is not copied
> around, it's no more dangerous to use it twice and delete it than to
> prompt for it twice, deleting it each time around.

This is supposed to work by default, but if you have multiple PGP
identities, there is a known problem.  For me, the passphrase is
cached so everything is decrypted automatically, but for signing I
have to enter it (twice).  I think pgg guess wrong about what id to
cache the passphrase under, so it doesn't find the passphrase when pgg
need it the next time.

Re: Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

Jesper Harder <harder@myrealbox.com> writes:

> The following message is a courtesy copy of an article
> that has been posted to gnus.ding as well.
>
> Hrvoje Niksic <hniksic@xemacs.org> writes:
>
>> [ Please keep the Cc to me if you want me to see the responses. ]
>
> You can use "Mail-Copies-To" and/or "Mail-Followup-To" to request this
> automatically.

I don't know about that, but in my day a simple `Cc' would have
sufficed.  I'm never sure about the exact semantics of these new
headers.  I don't even know what Mail-Followup-To does!

>> How about remembering the passphrase and reusing it the second
>> time?
>
> I think this is supposed to happen automatically -- or did you
> change the default setting of `pgg-cache-passphrase'?

No, it's set to t.  Do you mean that you can send (and archive) a
signed message without entering the passphrase twice?  Simon seems to
say that caching the passphrase works for encryption, but not for
signing.

Re: Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

> Hrvoje Niksic <hniksic@xemacs.org> writes:
>
>> How about remembering the passphrase and reusing it the second time?
>> The passphrase would be forgotten the moment the mail sending process
>> is finished.  At first that sounds like a violation of passphrase
>> privacy, but think about it: as long as the string is not copied
>> around, it's no more dangerous to use it twice and delete it than to
>> prompt for it twice, deleting it each time around.
>
> This is supposed to work by default,

Now I'm somewhat confused because your previous mail sounded exactly
the opposite -- like it's not supposed to work by default.  But then
again, I haven't studied the code, it might be a much more complex
issue than I'm aware of.

> but if you have multiple PGP identities, there is a known problem.

But I don't have multiple PGP identities, at least not for now.

> For me, the passphrase is cached so everything is decrypted
> automatically, but for signing I have to enter it (twice).

I haven't tried encryption/decryption yet.  I wanted to start with
something simple, such as signing, and stumbled on the
type-the-passphrase-twice thing which makes (to me) the whole
experience a rather unpleasant one.

Re: Entering passphrase twice when sending PGP signed message

[Jesper Harder]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>>> How about remembering the passphrase and reusing it the second
>>> time?
>>
>> I think this is supposed to happen automatically -- or did you
>> change the default setting of `pgg-cache-passphrase'?
>
> No, it's set to t.  Do you mean that you can send (and archive) a
> signed message without entering the passphrase twice?

Yes, it works for me.

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Hrvoje Niksic <hniksic@xemacs.org> writes:
>>
>>> How about remembering the passphrase and reusing it the second time?
>>> The passphrase would be forgotten the moment the mail sending process
>>> is finished.  At first that sounds like a violation of passphrase
>>> privacy, but think about it: as long as the string is not copied
>>> around, it's no more dangerous to use it twice and delete it than to
>>> prompt for it twice, deleting it each time around.
>>
>> This is supposed to work by default,
>
> Now I'm somewhat confused because your previous mail sounded exactly
> the opposite -- like it's not supposed to work by default.  But then
> again, I haven't studied the code, it might be a much more complex
> issue than I'm aware of.

Sorry if I gave the wrong impression, I (incorrectly) jumped to the
assumption that you wanted GPG to only be run once, thus removing the
need for two passphrase inputs.  I argued that running GPG twice was a
feature, but I wasn't very clear.  The passphrase cache should work by
default, both for signing and encrypting IMHO, so if this was your
only concern, it is only a Small Matter Of Bugfixing.

On further thought, one could argue that it should be possible to
customize the passphrase cache to a mode where decryption happens
automatically using the passphrase cache, but signing do require
password input every time, or at least a yes-or-no-p.  Since I use an
infinite passphrase cache lifetime, to be able to read encrypted
messages easily, I'd want this to make sure I don't sign something I
wasn't aware of.

>> but if you have multiple PGP identities, there is a known problem.
>
> But I don't have multiple PGP identities, at least not for now.

Hm, perhaps that wasn't the only criteria.  The passphrase seem to
work only for some people.

>> For me, the passphrase is cached so everything is decrypted
>> automatically, but for signing I have to enter it (twice).
>
> I haven't tried encryption/decryption yet.  I wanted to start with
> something simple, such as signing, and stumbled on the
> type-the-passphrase-twice thing which makes (to me) the whole
> experience a rather unpleasant one.

I agree.

Re: Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

> Sorry if I gave the wrong impression, I (incorrectly) jumped to the
> assumption that you wanted GPG to only be run once, thus removing the
> need for two passphrase inputs.

That assumption is not entirely incorrect: that was indeed my first
reaction.  But I've understood why it's not technically possible to
run GPG once, and I'd be more than willing to settle for passphrase
caching (which I even suggested!)

> The passphrase cache should work by default, both for signing and
> encrypting IMHO, so if this was your only concern, it is only a
> Small Matter Of Bugfixing.

Excellent.  I'll try to figure out what's going on there when I get
the time.

> On further thought, one could argue that it should be possible to
> customize the passphrase cache to a mode where decryption happens
> automatically using the passphrase cache, but signing do require
> password input every time, or at least a yes-or-no-p.  Since I use
> an infinite passphrase cache lifetime, to be able to read encrypted
> messages easily, I'd want this to make sure I don't sign something I
> wasn't aware of.

yes-no-p would be fine, but requiring the password every time is going
a bit too far.  Entering the passphrase and answering yes-no-p are
IMHO orthogonal.

Thanks for clearing things up.

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

>> On further thought, one could argue that it should be possible to
>> customize the passphrase cache to a mode where decryption happens
>> automatically using the passphrase cache, but signing do require
>> password input every time, or at least a yes-or-no-p.  Since I use
>> an infinite passphrase cache lifetime, to be able to read encrypted
>> messages easily, I'd want this to make sure I don't sign something I
>> wasn't aware of.
>
> yes-no-p would be fine, but requiring the password every time is going
> a bit too far.  Entering the passphrase and answering yes-no-p are
> IMHO orthogonal.

I agree, but to clarify, I think the passphrase cache should have a
few modes: (I'm not sure the modes marked with '(?)' are useful.)

* Disabled.
* Enabled for decrypt. (?)
* Enabled for sign. (?)
* Enabled for decrypt and sign.
* Enabled for decrypt and sign, but require confirmation for sign.
* Enabled for decrypt and sign, but require confirmation for decrypt. (?)
* Enabled for decrypt and sign, but require confirmation.

I.e., I didn't mean PGG should ask for a passphrase and then issue
yes-or-no-p, instead I meant that if the passphrase is cached, PGG
should use yes-or-no-p before using the cache.

Finally, if the OpenPGP implementation doesn't require a passphrase
(e.g., gpg-agent), PGG should never ask for a passphrase.  I'm not
sure if PGG can find this out automatically in a reliable way, so
perhaps this should be another modus operandi to add to the above set.

Re: Entering passphrase twice when sending PGP signed message

[Hrvoje Niksic]

Simon Josefsson <jas@extundo.com> writes:

> I agree, but to clarify, I think the passphrase cache should have a
> few modes: (I'm not sure the modes marked with '(?)' are useful.)
>
> * Disabled.
> * Enabled for decrypt. (?)
> * Enabled for sign. (?)
> * Enabled for decrypt and sign.
> * Enabled for decrypt and sign, but require confirmation for sign.
> * Enabled for decrypt and sign, but require confirmation for decrypt. (?)
> * Enabled for decrypt and sign, but require confirmation.
>
> I.e., I didn't mean PGG should ask for a passphrase and then issue
> yes-or-no-p, instead I meant that if the passphrase is cached, PGG
> should use yes-or-no-p before using the cache.

I still believe that caching should be orthogonal to using
yes-or-no-p.  That is, if confirmation is required for signing, I
should be required to confirm.  Then, depending on whether passphrase
has been cached or not, I may or may not also have to type in the
passphrase.

In other words, I'd prefer to have two knobs to twist:

- Cache passphrase:

  * Without time limit.
  * With time limit.
  * For the duration of sending of one mail (i.e. to guarantee that I
    only have to type it once for any single mail.)
  * Never cache it.

- Confirm signing/encryption:

  * Confirm signing.
  * Confirm encryption.
  * Confirm both.

On the other hand, does it really happen to you that you could sign
something by mistake?  When I was signing my mail, I had to press `C-c
C-m s o' [1] to add the appropriate MML markup -- it didn't happen
automagically.


[1]
Who ever came up with those key bindings??

Re: Entering passphrase twice when sending PGP signed message

[Matthias Andree]

Simon Josefsson <jas@extundo.com> writes:

> This happens if you use Gcc, and it is because the message is encoded
> once for sendmail/SMTP/NNTP and once for the Gcc copy, as you assume.
> But this can't be fixed easily, because the copy that is Gcc'ed is not
> the same as the one that is mailed or posted.

That's a bug then. The local copy must be identical to what's sent out,
save for the standardized differences (Newsgroups: potentially).

> An extreme example is the `gnus-gcc-externalize-attachments', which
> make Gcc differ distinctly from the SMTP/NTTP version of the mail.
> The more subtle examples are charset handling, news differ from mail,
> so making gcc equal one of them still wouldn't solve the problem in
> general.

As long as the whole "object" conforms to the intersection of RFC-2822
and RFC-1036, there's not much difference that matters for local storing
of what has been sent a second before.

> Another approach would be to attack the source of the problem,
> passphrases.  The gpg-agent seems like a good solution to that.

The problem appears to be that the saved article differs from the sent
article, which is a no-no.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> This happens if you use Gcc, and it is because the message is encoded
>> once for sendmail/SMTP/NNTP and once for the Gcc copy, as you assume.
>> But this can't be fixed easily, because the copy that is Gcc'ed is not
>> the same as the one that is mailed or posted.
>
> That's a bug then. The local copy must be identical to what's sent out,
> save for the standardized differences (Newsgroups: potentially).

What purpose would this serve?  If you want a copy of what is sent in
mail, there is Bcc.  I'm not sure if there is a similar feature for
getting a copy of what is posted in news, though.

The advantage of generate Gcc separately from mail and news is, of
course, that your local copy isn't restricted to the arbitrary, and
sometimes incompatible, limitations in mail and news, and to support
Gcc rewriting functionality, e.g. gnus-gcc-externalize-attachments.

>> An extreme example is the `gnus-gcc-externalize-attachments', which
>> make Gcc differ distinctly from the SMTP/NTTP version of the mail.
>> The more subtle examples are charset handling, news differ from mail,
>> so making gcc equal one of them still wouldn't solve the problem in
>> general.
>
> As long as the whole "object" conforms to the intersection of RFC-2822
> and RFC-1036, there's not much difference that matters for local storing
> of what has been sent a second before.

Yup, and I wouldn't argue against optimizing the Gcc process, so that
it simply copies the outgoing "object" verbatim, when that is
possible.  But deciding if that situation applies or not seems
non-trivial.

(The logic would have to, besides checking for the intersection
between (2)822 and 1036(bis), also check if any of the enabled Gcc
rewriting features would modify the "object".  Even so, it must have
knowledge about certain MML tags, such as security tags, which
generate different output each time, but can (probably, and not in all
situations) be considered equal, for Gcc:ing purposes.  Also remember
that MIME encoding can be different in news than from mail too.)

>> Another approach would be to attack the source of the problem,
>> passphrases.  The gpg-agent seems like a good solution to that.
>
> The problem appears to be that the saved article differs from the sent
> article, which is a no-no.

There are already features that require the saved article to differ
from what was sent, so it is not always a bad thing, assuming people
do use those features.

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I agree, but to clarify, I think the passphrase cache should have a
>> few modes: (I'm not sure the modes marked with '(?)' are useful.)
>>
>> * Disabled.
>> * Enabled for decrypt. (?)
>> * Enabled for sign. (?)
>> * Enabled for decrypt and sign.
>> * Enabled for decrypt and sign, but require confirmation for sign.
>> * Enabled for decrypt and sign, but require confirmation for decrypt. (?)
>> * Enabled for decrypt and sign, but require confirmation.
>>
>> I.e., I didn't mean PGG should ask for a passphrase and then issue
>> yes-or-no-p, instead I meant that if the passphrase is cached, PGG
>> should use yes-or-no-p before using the cache.
>
> I still believe that caching should be orthogonal to using
> yes-or-no-p.  That is, if confirmation is required for signing, I
> should be required to confirm.  Then, depending on whether passphrase
> has been cached or not, I may or may not also have to type in the
> passphrase.

If you run with a disabled passphrase cache, I don't think this would
result in a sensible user interface.  Specifically: you would have to
enter the passphrase AND type 'yes' every time.  I would be rather
annoyed by the useless yes-or-no-p query in this situation.  Entering
the passphrase is, to me at least, the same as approving the
operation.

> On the other hand, does it really happen to you that you could sign
> something by mistake?  When I was signing my mail, I had to press `C-c
> C-m s o' [1] to add the appropriate MML markup -- it didn't happen
> automagically.

It happens for me automatically, I have some hooks that look up an
attribute in my bbdb that say if I should add a MML encrypt tag, per
recipient.  But my customization is buggy (naturally), so sometimes it
add a MML tag erroneously, and I rarely notice until I try to send the
message.  But since there is a passphrase prompt (or would be a
yes-or-no-p) I can C-g and remove the MML tag.

> Who ever came up with those key bindings??

Can you find a better, unallocated, key binding, that doesn't conflict
with some mode that often can be enabled in message buffers?

Re: Entering passphrase twice when sending PGP signed message

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Hrvoje Niksic <hniksic@xemacs.org> writes:

[`C-c C-m s o']

>> Who ever came up with those key bindings??
>
> Can you find a better, unallocated, key binding, that doesn't
> conflict with some mode that often can be enabled in message
> buffers?

Do it like forwarding, i.e. make an option for the default signing
method.  Without a prefix `C-c C-m s' will use that, otherwise the
numeric prefix selects which method to use.

Re: Entering passphrase twice when sending PGP signed message

[Matthias Andree]

Simon Josefsson <jas@extundo.com> writes:

> What purpose would this serve?  If you want a copy of what is sent in
> mail, there is Bcc.  I'm not sure if there is a similar feature for
> getting a copy of what is posted in news, though.

Not officially. Gcc: and Fcc: are local extensions to Gnus. Group carbon
copies are handled through "Newsgroups:" officially.

> The advantage of generate Gcc separately from mail and news is, of
> course, that your local copy isn't restricted to the arbitrary, and
> sometimes incompatible, limitations in mail and news,

What are these incompatible limitations?

> and to support Gcc rewriting functionality,
> e.g. gnus-gcc-externalize-attachments.

AFAICS, any News posting can be sent as a mail, technically, because
RFC-1036 requires a subset of RFC-2822. IOW, if Gnus only uses
constructs legal in News, we don't need this distinction except to
choose between SMTP and NNTP -- which is the posting-method in the first
place.

I wonder if there's anything that mail allows for but news doesn't
that's needed in real life.

> (The logic would have to, besides checking for the intersection
> between (2)822 and 1036(bis), also check if any of the enabled Gcc
> rewriting features would modify the "object".

The logic would be to only generate RFC-1036 + RFC-2045..2049 (+ 2231),
even for mail. I. e. 7bit US-ASCII headers, with limited folding and
limited RFC-2822 syntax.

Any archival or "keep a local copy" function MUST NOT tamper with the
content in any case, particularly not when the content is being
signed. gnus-gcc-externalize-attachments MUST NOT apply to signed
material.

> Even so, it must have knowledge about certain MML tags, such as
> security tags, which generate different output each time, but can
> (probably, and not in all situations) be considered equal, for Gcc:ing
> purposes.  Also remember that MIME encoding can be different in news
> than from mail too.)

How does MIME encoding for news differ from MIME encoding for mail?

All these possible differences look academic to me ATM. The real-world
differences are: Path vs. References and Newsgroups vs. To. That's it.

> There are already features that require the saved article to differ
> from what was sent, so it is not always a bad thing, assuming people
> do use those features.

I really wonder what features these are. Confusion Inductor v1.0 perhaps.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Hrvoje Niksic <hniksic@xemacs.org> writes:
>
> [`C-c C-m s o']
>
>>> Who ever came up with those key bindings??
>>
>> Can you find a better, unallocated, key binding, that doesn't
>> conflict with some mode that often can be enabled in message
>> buffers?
>
> Do it like forwarding, i.e. make an option for the default signing
> method.  Without a prefix `C-c C-m s' will use that, otherwise the
> numeric prefix selects which method to use.

Ah, I like it.  I guess the default should be PGP/MIME, and the rest
perhaps C-u 0 C-c C-m ? for PGP and C-u 1 C-c C-m ? for S/MIME?

OTOH, this is backward incompatible with a released version.

OTTH, how do this interact with the menu?  IIRC, you can't have the
menu item contain a key binding if it uses prefixes.  Perhaps Emacs
could be fixed in that regard though, there are several useful
operations that are invoked via prefixes that deserve proper menu
items.

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

>> The advantage of generate Gcc separately from mail and news is, of
>> course, that your local copy isn't restricted to the arbitrary, and
>> sometimes incompatible, limitations in mail and news,
>
> What are these incompatible limitations?

E.g., different charsets for different destinations.  Sometimes a
specific charset in 8bit in newsgroups is desired (and Gnus get this
right in several hierarchies), while QP is sometimes preferred for
mail.

>> and to support Gcc rewriting functionality,
>> e.g. gnus-gcc-externalize-attachments.
>
> AFAICS, any News posting can be sent as a mail, technically, because
> RFC-1036 requires a subset of RFC-2822. IOW, if Gnus only uses
> constructs legal in News, we don't need this distinction except to
> choose between SMTP and NNTP -- which is the posting-method in the first
> place.
>
> I wonder if there's anything that mail allows for but news doesn't
> that's needed in real life.

I think one difference lies in how an article is _preferred_ to be
sent.  Just because you legally can send a news posting in mail,
doesn't make it the best way to send that message via mail.  Compare
above where the preferences between mail and news differ.

>> (The logic would have to, besides checking for the intersection
>> between (2)822 and 1036(bis), also check if any of the enabled Gcc
>> rewriting features would modify the "object".
>
> The logic would be to only generate RFC-1036 + RFC-2045..2049 (+ 2231),
> even for mail. I. e. 7bit US-ASCII headers, with limited folding and
> limited RFC-2822 syntax.

Still doesn't solve the case where mail and news wants different
charsets.

Non-ASCII in news is not standardized AFAIK, and using MIME as defined
for mail does not seem to be a conservative solution.  USEFOR has
discussed incompatible solutions, and at least some time ago people
argued for using 8bit UTF-8 in headers.

> Any archival or "keep a local copy" function MUST NOT tamper with the
> content in any case, particularly not when the content is being
> signed. gnus-gcc-externalize-attachments MUST NOT apply to signed
> material.

It is probably best made customizable IMHO; if a user has opted to
externalize attachments, I think they would expect that to happen for
all messages, even signed or encrypted.

>> Even so, it must have knowledge about certain MML tags, such as
>> security tags, which generate different output each time, but can
>> (probably, and not in all situations) be considered equal, for Gcc:ing
>> purposes.  Also remember that MIME encoding can be different in news
>> than from mail too.)
>
> How does MIME encoding for news differ from MIME encoding for mail?
>
> All these possible differences look academic to me ATM. The real-world
> differences are: Path vs. References and Newsgroups vs. To. That's it.

Yes, but what I think were we disagree is how to find out if the
possible differences apply to a specific message or not.

I agree with you that it would be _better_ if Gcc did not require
another run of the MIME generator, and simply stored whatever was
sent, but I don't know how to implement that safely, so I'm pointing
out possible problems.  If you have a patch in mind that handle the
potential problems, that would prove me wrong easily.

>> There are already features that require the saved article to differ
>> from what was sent, so it is not always a bad thing, assuming people
>> do use those features.
>
> I really wonder what features these are. Confusion Inductor v1.0 perhaps.

* gnus-gcc-externalize-attachments

* automatic message/partial, do you really want the GCC group to
  contain all X partial parts, instead of one message?

* different charsets, content-transfer-encoding preferences.

Perhaps there are more.

Re: Entering passphrase twice when sending PGP signed message

[Matthias Andree]

Simon Josefsson <jas@extundo.com> writes:

> E.g., different charsets for different destinations.  Sometimes a
> specific charset in 8bit in newsgroups is desired (and Gnus get this
> right in several hierarchies), while QP is sometimes preferred for
> mail.
>
> I think one difference lies in how an article is _preferred_ to be
> sent.  Just because you legally can send a news posting in mail,
> doesn't make it the best way to send that message via mail.  Compare
> above where the preferences between mail and news differ.
>
> It is probably best made customizable IMHO; if a user has opted to
> externalize attachments, I think they would expect that to happen for
> all messages, even signed or encrypted.
>
> Yes, but what I think were we disagree is how to find out if the
> possible differences apply to a specific message or not.
>
> I agree with you that it would be _better_ if Gcc did not require
> another run of the MIME generator, and simply stored whatever was
> sent, but I don't know how to implement that safely, so I'm pointing
> out possible problems.  If you have a patch in mind that handle the
> potential problems, that would prove me wrong easily.

I'm afraid I don't speak elisp. As to the (unquoted) UTF-8 in news
discussion: RFC-2047 will be around long enough we don't need to care.

The other points you raise miss one important point: the signature and
the whole point why an article is signed at all. You'll have one
particular article (with or without attachments, mail or news or both)
signed, and that SIGNATURE MUST BE THE SAME (including time stamp and
all that) across all transports and all formatting preferences. Anything
else defeats the purpose: if three different signatures for the same
document are around, the signature is worthless and will cause more
grief than benefit. I'd think that any of the "sign" modes must defeat
any variation in the article. Re-encoding and particularly re-signing is
a "MUST NOT" in this scenario, so the approach is:

1. make sure to GENERATE (message.el & Co.) a uniform mail that suits
   all transports (lowest common denominator, saves any
   case discrimination in MML+PGG or other postprocessors).
2. make sure to POSTPROCESS uniformly
3. diversity only to add mandatory headers for the respective transport
   (SMTP, NNTP)

It's simply Not The Right Thing to have different signatures when a
posting is posted & mailed, no matter how many options, buts and ifs you
attach.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: Entering passphrase twice when sending PGP signed message

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> Do it like forwarding, i.e. make an option for the default signing
>> method.  Without a prefix `C-c C-m s' will use that, otherwise the
>> numeric prefix selects which method to use.
>
> Ah, I like it.  I guess the default should be PGP/MIME, and the rest
> perhaps C-u 0 C-c C-m ? for PGP and C-u 1 C-c C-m ? for S/MIME?
>
> OTOH, this is backward incompatible with a released version.

Yeah, but you could argue that it's better to change it now before
Oort Gnus has been bundled with a released version of Emacs.

> OTTH, how do this interact with the menu?  IIRC, you can't have the
> menu item contain a key binding if it uses prefixes.

I don't think we necessarily need menu items for the prefixes -- a
sub-menu which let's you change the default with radio buttons would
be better, IMHO.

I think it's a great opportunity to simplify and clean up the
crypto-related menu items.  We could arrange it like this (which would
make the Attachments menu much less crowded):

    +---------------------------------+
    | Sign                (C-c RET s) |
    | Encrypt             (C-c RET c) |
    | Sign Part           (C-c RET S) |
    | Encrypt Part        (C-c RET C) |
    | Encrypt/Sign Off  (C-c RET C-n) |
    | Change Security Method     +-----------------------+
    +----------------------------|  [x] PGP/MIME         |
                                 |  [ ] Traditional PGP  |
                                 |  [ ] S/MIME           |
                                 +-----------------------+

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Jesper Harder <harder@myrealbox.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Jesper Harder <harder@myrealbox.com> writes:
>>
>>> Do it like forwarding, i.e. make an option for the default signing
>>> method.  Without a prefix `C-c C-m s' will use that, otherwise the
>>> numeric prefix selects which method to use.
>>
>> Ah, I like it.  I guess the default should be PGP/MIME, and the rest
>> perhaps C-u 0 C-c C-m ? for PGP and C-u 1 C-c C-m ? for S/MIME?
>>
>> OTOH, this is backward incompatible with a released version.
>
> Yeah, but you could argue that it's better to change it now before
> Oort Gnus has been bundled with a released version of Emacs.

Yes.  And it is not like hitting the old combination would exit emacs,
so people would notice and recover.

>> OTTH, how do this interact with the menu?  IIRC, you can't have the
>> menu item contain a key binding if it uses prefixes.
>
> I don't think we necessarily need menu items for the prefixes -- a
> sub-menu which let's you change the default with radio buttons would
> be better, IMHO.
>
> I think it's a great opportunity to simplify and clean up the
> crypto-related menu items.  We could arrange it like this (which would
> make the Attachments menu much less crowded):
>
>     +---------------------------------+
>     | Sign                (C-c RET s) |
>     | Encrypt             (C-c RET c) |
>     | Sign Part           (C-c RET S) |
>     | Encrypt Part        (C-c RET C) |
>     | Encrypt/Sign Off  (C-c RET C-n) |
>     | Change Security Method     +-----------------------+
>     +----------------------------|  [x] PGP/MIME         |
>                                  |  [ ] Traditional PGP  |
>                                  |  [ ] S/MIME           |
>                                  +-----------------------+

While it looks simpler and better, I'm not so sure.  A look at my own
signed/encrypted communication patterns gives roughly:

   50 % PGP
   40 % PGP/MIME
   10 % S/MIME

So I would have a hard time choosing PGP/MIME or PGP as the default,
and I would have to change it frequently.  And I do use the menubar,
since the keybindings are obscure, and entering the MML tag manually
is boring.  I suspect this is not a corner situation, traditional PGP
is still the norm if you want to talk with non-technical savvy people.

Although, I could use PGP/MIME as the default and manully change
'pgpmime' to 'pgp' in the MML tag.  Hm.

Speaking generally: The Gnus menubar are rather long and unfriendly.
One almost get the impression that they were designed by putting
everything that has a key binding into the menu.  Perhaps we could
have simplified and user friendly menus (like what you propose) in the
top-level menu by default, and an Advanced sub-menu that contains all
possible commands.  OTOH moving things around is also bad, and placing
lots of entries in a submenu can look weird.  O well, just an idea.

Re: Entering passphrase twice when sending PGP signed message

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@myrealbox.com> writes:

> I think it's a great opportunity to simplify and clean up the
> crypto-related menu items.  We could arrange it like this (which would
> make the Attachments menu much less crowded):
>
>     +---------------------------------+
>     | Sign                (C-c RET s) |
>     | Encrypt             (C-c RET c) |
>     | Sign Part           (C-c RET S) |
>     | Encrypt Part        (C-c RET C) |
>     | Encrypt/Sign Off  (C-c RET C-n) |
>     | Change Security Method     +-----------------------+
>     +----------------------------|  [x] PGP/MIME         |
>                                  |  [ ] Traditional PGP  |
>                                  |  [ ] S/MIME           |
>                                  +-----------------------+

Beautiful.  Did you check it in?

Anyway, what was the conclusion to the double-pass-phrasing when
sending?  If it's only a matter of caching the pass phrase during a
`C-c C-c', that function could just bind a variable
`message-pass-phrase' and use that when it's non-nil.  (The idea
being that when the function passes out of the scope, the variable
becomes unbound again, thereby being kinda difficult to snoop.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Anyway, what was the conclusion to the double-pass-phrasing when
> sending?  If it's only a matter of caching the pass phrase during a
> `C-c C-c', that function could just bind a variable
> `message-pass-phrase' and use that when it's non-nil.  (The idea
> being that when the function passes out of the scope, the variable
> becomes unbound again, thereby being kinda difficult to snoop.)

I believe the conclusion was that the OpenPGP implementation should be
invoked twice, however the passphrase should be cached.  There _is_
already a passphrase cache, so it is only a Small Matter Of Debugging.

Re: Entering passphrase twice when sending PGP signed message

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I believe the conclusion was that the OpenPGP implementation should be
> invoked twice, however the passphrase should be cached.  There _is_
> already a passphrase cache, so it is only a Small Matter Of Debugging.

Ah, right.  In the PGP, er GPG, er, PGG code?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I believe the conclusion was that the OpenPGP implementation should be
>> invoked twice, however the passphrase should be cached.  There _is_
>> already a passphrase cache, so it is only a Small Matter Of Debugging.
>
> Ah, right.  In the PGP, er GPG, er, PGG code?

Yes, pgg.el.  I think the problem is related to the key id guessing
somehow (perhaps the cache store each passphrase indexed by key id,
and if either at insertion or lookup the wrong key id is used, it will
look as if no passphrase was cached).

Re: Entering passphrase twice when sending PGP signed message

[Jesper Harder]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>>     +---------------------------------+
>>     | Sign                (C-c RET s) |
>>     | Encrypt             (C-c RET c) |
>>     | Sign Part           (C-c RET S) |
>>     | Encrypt Part        (C-c RET C) |
>>     | Encrypt/Sign Off  (C-c RET C-n) |
>>     | Change Security Method     +-----------------------+
>>     +----------------------------|  [x] PGP/MIME         |
>>                                  |  [ ] Traditional PGP  |
>>                                  |  [ ] S/MIME           |
>>                                  +-----------------------+
>
> Beautiful.  Did you check it in?

No.  I thought it would be better to wait for No Gnus to make user
visible changes like that.

Re: Entering passphrase twice when sending PGP signed message

[Lars Magne Ingebrigtsen]

Jesper Harder <harder@myrealbox.com> writes:

> No.  I thought it would be better to wait for No Gnus to make user
> visible changes like that.

Okidoke.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Attachments and security menu (was: Entering passphrase twice when sending PGP signed message)

[Reiner Steib]

[ Following up to an old thread:
  http://thread.gmane.org/m365jukh3s.fsf%40defun.localdomain ]

On Sat, Oct 18 2003, Jesper Harder wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Jesper Harder <harder@myrealbox.com> writes:
>>
>>>     +---------------------------------+
>>>     | Sign                (C-c RET s) |
>>>     | Encrypt             (C-c RET c) |
>>>     | Sign Part           (C-c RET S) |
>>>     | Encrypt Part        (C-c RET C) |
>>>     | Encrypt/Sign Off  (C-c RET C-n) |
>>>     | Change Security Method     +-----------------------+
>>>     +----------------------------|  [x] PGP/MIME         |
>>>                                  |  [ ] Traditional PGP  |
>>>                                  |  [ ] S/MIME           |
>>>                                  +-----------------------+
>>
>> Beautiful.  Did you check it in?
>
> No.  I thought it would be better to wait for No Gnus to make user
> visible changes like that.

I have installed a new menu based on Jesper's suggestion:

	* mml-sec.el (mml-secure-method): New internal variable.
	(mml-secure-sign, mml-secure-encrypt, mml-secure-message-sign)
	(mml-secure-message-sign-encrypt, mml-secure-message-encrypt): New
	functions using mml-secure-method.

	* mml.el (mml-mode-map): Add key bindings for those functions.
	(mml-menu): Simplify security menu entries.
	(mml-attach-file, mml-attach-buffer, mml-attach-external): Goto
	end of message if point is the headers of the message.

	* message.el (message-in-body-p): New function.

As inserting parts inside message headers makes no sense, I've changed
those functions to go to the end of the message before inserting.
Inserting attachments at the end seems preferable to the top of the
message, because some broken MUAs are not able to deal with inline
parts following attachments.

I was quite unsure about the key bindings and some implementation
details.  Maybe we should also provide an interactive function and key
bindings to change the current method (mml-secure-method).

Comments?  Suggestions?  I don't use encryption/signing often; please
tell me if this change breaks something or if it is inconvenient.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Attachments and security menu

[Reiner Steib]

[ Resent; Sorry if you receive this twice. ]

On Thu, Oct 13 2005, Reiner Steib wrote:

> [ Following up to an old thread:
>   http://thread.gmane.org/m365jukh3s.fsf%40defun.localdomain ]
[...]
> I have installed a new menu based on Jesper's suggestion:
>
> 	* mml-sec.el (mml-secure-method): New internal variable.
> 	(mml-secure-sign, mml-secure-encrypt, mml-secure-message-sign)
> 	(mml-secure-message-sign-encrypt, mml-secure-message-encrypt): New
> 	functions using mml-secure-method.
>
> 	* mml.el (mml-mode-map): Add key bindings for those functions.
> 	(mml-menu): Simplify security menu entries.
> 	(mml-attach-file, mml-attach-buffer, mml-attach-external): Goto
> 	end of message if point is the headers of the message.
>
> 	* message.el (message-in-body-p): New function.
[...]
> Comments?  Suggestions?  I don't use encryption/signing often; please
> tell me if this change breaks something or if it is inconvenient.

This stuff is in the trunk since October 2005.  So I think it's
sufficiently tested to go into v5-10 as well.  It makes the menus much
easier to use and avoids user errors.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/