Re: Entering passphrase twice when sending PGP signed message

[Simon Josefsson <jas@extundo.com>]

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.