From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53960 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Entering passphrase twice when sending PGP signed message Date: Sun, 14 Sep 2003 23:38:18 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063575530 14424 80.91.224.253 (14 Sep 2003 21:38:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2003 21:38:50 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M2500@lists.math.uh.edu Sun Sep 14 23:38:48 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19yeZz-0001Ls-00 for ; Sun, 14 Sep 2003 23:38:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19yeZm-0004jI-00; Sun, 14 Sep 2003 16:38:34 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19yeZe-0004jA-00 for ding@lists.math.uh.edu; Sun, 14 Sep 2003 16:38:26 -0500 Original-Received: (qmail 30741 invoked by alias); 14 Sep 2003 21:38:26 -0000 Original-Received: (qmail 30736 invoked from network); 14 Sep 2003 21:38:25 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by sclp3.sclp.com with SMTP; 14 Sep 2003 21:38:25 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h8ELcIdk001498 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sun, 14 Sep 2003 23:38:19 +0200 Original-To: Matthias Andree Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:030914:ma@dt.e-technik.uni-dortmund.de:4cae56302f1ac251 X-Hashcash: 0:030914:ma@dt.e-technik.uni-dortmund.de:4cae56302f1ac251 X-Payment: hashcash 1.2 0:030914:ding@gnus.org:1a24dda9fbeb5f53 X-Hashcash: 0:030914:ding@gnus.org:1a24dda9fbeb5f53 In-Reply-To: (Matthias Andree's message of "Sun, 14 Sep 2003 23:02:51 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53960 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53960 Matthias Andree writes: > Simon Josefsson 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.