Bug#671847: [Mutt] #3879: mutt: encoded-words are not decoded in mailto:
You should do the RFC 2822 parse first, then the decode -- 2047 is
specifically written so it parses as one token.
Thomas Roessler (@roessler)
On Tue, Sep 27, 2016 at 6:17 PM, Mutt wrote:
> #3879: mutt: encoded-words are not decoded in mailto:
> +--
> Reporter: antonio@… | Owner: mutt-dev
> Type: defect | Status: closed
> Priority: major | Milestone:
> Component: charset|Version: 1.7.0
> Resolution: fixed | Keywords:
> +--
> Changes (by Kevin McCarthy ):
>
> * status: new => closed
> * resolution: => fixed
>
>
> Comment:
>
> In [changeset:"55819a7e61695bffea31646464183fcb2d54899d"
> 6802:55819a7e6169]:
> {{{
> #!CommitTicketReference repository=""
> revision="55819a7e61695bffea31646464183fcb2d54899d"
> RFC2047-decode mailto header values. (closes #3879)
>
> RFC 6068 specifies that the header values (with the exception of body)
> may contain RFC 2047-encoded values.
> }}}
>
> --
> Ticket URL: <https://dev.mutt.org/trac/ticket/3879#comment:2>
> Mutt <http://www.mutt.org/>
> The Mutt mail user agent
>
>
Bug#151645: mozilla-browser: HTTP/1.1 Pipelining gets confused.
I don't remember having seen the problem with any more recent Mozilla; since I'm not currently using Debian, though, I couldn't tell. I'd suggest you consider this bug closed unless somebody else reports it again. -- Thomas Roessler <[EMAIL PROTECTED]> On 2006-12-26 13:53:48 +0100, Andreas Metzler wrote: > From: Andreas Metzler <[EMAIL PROTECTED]> > To: Thomas Roessler <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Date: Tue, 26 Dec 2006 13:53:48 +0100 > Subject: Re: mozilla-browser: HTTP/1.1 Pipelining gets confused. > Reply-To: [EMAIL PROTECTED] > X-Spam-Level: > > On 2002-07-02 Thomas Roessler <[EMAIL PROTECTED]> wrote: > > Package: mozilla-browser > > Version: 2:1.0.0-0.woody.1 > > Severity: normal > > > It seems like HTTP pipelining occasionally gets confused, and out of > > synch with the server's answers. Mozilla then offers me to save the > > web page in question as an application/x-httpd-php3 file (the > > content type is apparently determined from the file name); that file > > contains the actual HTTP header, and part of the server's response > > (like "1 200", cut off from "HTTP/1.1 200"). > > > To reproduce activate persistent connections and pipelining, and > > stress-test it a bit. (For instance on a site which opens many > > sub-windows.) If needed to debug this further, I have a packet trace > > of a session where this happened available. As far as I can see it, > > the dialogue between Mozilla and the server was flawless on the > > wire. > [...] > > Can you still reproduce this with iceape (or even mozilla 1.7.x)? > cu andreas > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400831: [EMAIL PROTECTED]: Bug#400831: logic error in
fixed
On 2006-12-02 17:05:47 -0500, Kyle Wheeler wrote:
> From: Kyle Wheeler <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Date: Sat, 2 Dec 2006 17:05:47 -0500
> Subject: [EMAIL PROTECTED]: Bug#400831: logic error in
> mutt-1.5.13/account.c]
> X-Spam-Level:
> Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
>
> I came across this posting to the Debian mutt list.
>
> ~Kyle
> --
> I love America more than any other country in this world, and, exactly
> for this reason, I insist on the right to criticize her perpetually.
> -- James Baldwin, Notes of a Native Son
> From: Jochen Voss <[EMAIL PROTECTED]>
> To: Debian Bug Tracking System <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 23:00:29 +
> Subject: Bug#400831: logic error in mutt-1.5.13/account.c
> Reply-To: Jochen Voss <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> X-Spam-Level:
> DomainKey-Status: no signature
>
> Package: mutt
> Version: 1.5.13-1
> Severity: normal
>
> Hi,
>
> recently I came across the following bit of code in the source file
> mutt-1.5.13/account.c (near the end of the file):
>
> void mutt_account_unsetpass (ACCOUNT* account)
> {
> account->flags &= !M_ACCT_PASS;
> }
>
> Since the flags field is used as a collection of separate bit, this is
> a bug in the program. Since M_ACCT_PASS equals 8, !M_ACCT_PASS equals
> 0 and the 'mutt_account_unsetpass' function erroneously clears all
> flags instead of only M_ACCT_PASS.
>
> This bug can be fixed by using bitwise negation instead of logical
> negation:
>
> account->flags &= ~M_ACCT_PASS;
>
> I hope this helps,
> Jochen
>
> -- System Information:
> Debian Release: 4.0
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.18.3
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
>
> Versions of packages mutt depends on:
> ii exim4 4.63-10metapackage to ease exim MTA
> (v4)
> ii exim4-daemon-light [mail- 4.63-10lightweight exim MTA (v4) daemon
> ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries
> ii libdb4.4 4.4.20-8 Berkeley v4.4 Database Libraries
> [
> ii libgnutls13 1.4.4-3the GNU TLS library - runtime
> libr
> ii libidn11 0.6.5-1GNU libidn library,
> implementation
> ii libncursesw5 5.5-5 Shared libraries for terminal
> hand
> ii libsasl2 2.1.22.dfsg1-4 Authentication abstraction
> library
>
> Versions of packages mutt recommends:
> ii locales 2.3.6.ds1-8 GNU C Library: National Language
> (
> ii mime-support 3.37-1 MIME files 'mime.types' &
> 'mailcap
>
> -- no debconf information
--
Thomas Roessler <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352357: mutt/2190: mutt segfaults when replying from the view-attachments menu
The following reply was made to PR mutt/2190; it has been noted by GNATS. From: Thomas Roessler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: mutt/2190: mutt segfaults when replying from the view-attachments menu Date: Fri, 3 Mar 2006 14:11:03 +0100 It would take some changes to the "reply to attachment" code, and possibly some API changes internally. It's certainly feasible, but certainly not during a coffee break at a conference. -- Thomas Roessler <[EMAIL PROTECTED]> On 2006-03-03 13:45:02 +0100, Paul Walker wrote: > From: Paul Walker <[EMAIL PROTECTED]> > To: Mutt Developers <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Date: Fri, 03 Mar 2006 13:45:02 +0100 > Subject: Re: mutt/2190: mutt segfaults when replying from the > view-attachments menu > Reply-To: [EMAIL PROTECTED] > X-Spam-Level: > > The following reply was made to PR mutt/2190; it has been noted by GNATS. > > From: Paul Walker <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: > Subject: Re: mutt/2190: mutt segfaults when replying from the > view-attachments menu > Date: Fri, 3 Mar 2006 12:41:15 + > > On Fri, Mar 03, 2006 at 11:15:03AM +0100, Thomas Roessler wrote: > > > There's a choice here: Either we can disallow ~h in reply-hooks, or we > > can disable reply-hook when replying to a message from the attachment > > menu. I'm inclined to do the former, and will commit that to CVS. > > Out of interest, is there a reason why what the submitter was trying to do > isn't possible to make work? > > -- > Paul > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351258: mutt/2189: mutt segfaults if external query return spaces
The following reply was made to PR mutt/2189; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2189: mutt segfaults if external query return spaces
Date: Fri, 3 Mar 2006 10:56:42 +0100
On 2006-03-03 02:41:41 +0100, [EMAIL PROTECTED] wrote:
> mutt segfault when selecting mail if query_command is set to:
I'm committing this to CVS:
diff -u -r3.10 query.c
--- query.c17 Sep 2005 20:46:11 - 3.10
+++ query.c3 Mar 2006 09:55:05 -
@@ -64,7 +64,8 @@
{
static ADDRESS *tmp;
- tmp = rfc822_cpy_adr (r->addr);
+ if (!(tmp = rfc822_cpy_adr (r->addr)))
+return NULL;
if(!tmp->next && !tmp->personal)
tmp->personal = safe_strdup (r->name);
--
Thomas Roessler <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352357: mutt/2190: mutt segfaults when replying from the view-attachments menu
The following reply was made to PR mutt/2190; it has been noted by GNATS. From: Thomas Roessler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: mutt/2190: mutt segfaults when replying from the view-attachments menu Date: Fri, 3 Mar 2006 11:12:45 +0100 On 2006-03-03 02:45:39 +0100, [EMAIL PROTECTED] wrote: > 100% repeatable segfault in mutt from unstable: at the index level > press v and then r > I can reproduce it with just this .muttrc: > reply-hook "~h '^nevermatches---" set pgp_autosign > set edit_headers > set autoedit There's a choice here: Either we can disallow ~h in reply-hooks, or we can disable reply-hook when replying to a message from the attachment menu. I'm inclined to do the former, and will commit that to CVS. Regards, -- Thomas Roessler <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340116: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
The following reply was made to PR mutt/2139; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
Date: Tue, 22 Nov 2005 13:32:00 +0100
On 2005-11-21 21:41:36 +0100, [EMAIL PROTECTED] wrote:
> Also, and with respect Daniel's original report, note that even
> if mutt properly opens the message, it outputs somehow confusing
> messages. First:
> Could not decrypt PGP message
>
> And then, when displaying:
>
> PGP message successfully decrypted.
*sigh*
This patch complicates the spaghetti code in pgp.c a tiny bit more,
but fixes this particular problem:
diff -u -r3.60 pgp.c
--- pgp.c 21 Oct 2005 04:35:37 - 3.60
+++ pgp.c 22 Nov 2005 12:30:15 -
@@ -243,6 +243,7 @@
int pgp_application_pgp_handler (BODY *m, STATE *s)
{
+ int could_not_decrypt = 0;
int needpass = -1, pgp_keyblock = 0;
int clearsign = 0, rv, rc;
int c = 1; /* silence GCC warning */
@@ -398,15 +399,16 @@
}
if (!clearsign && (!pgpout || c == EOF))
{
+could_not_decrypt = 1;
+pgp_void_passphrase ();
+ }
+
+ if (could_not_decrypt && !(s->flags & M_DISPLAY))
+ {
mutt_error _("Could not decrypt PGP message");
mutt_sleep (1);
- pgp_void_passphrase ();
-
-if (!(s->flags & M_DISPLAY))
-{
- rc = -1;
- goto out;
-}
+rc = -1;
+goto out;
}
}
@@ -450,7 +452,10 @@
if (needpass)
{
state_attach_puts (_("[-- END PGP MESSAGE --]\n"), s);
- mutt_message _("PGP message successfully decrypted.");
+if (could_not_decrypt)
+ mutt_error _("Could not decrypt PGP message");
+else
+ mutt_message _("PGP message successfully decrypted.");
}
else if (pgp_keyblock)
state_attach_puts (_("[-- END PGP PUBLIC KEY BLOCK --]\n"), s);
--
Thomas Roessler <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340116: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
The following reply was made to PR mutt/2139; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
Date: Tue, 22 Nov 2005 13:21:22 +0100
On 2005-11-22 13:13:12 +0100, Thomas Roessler wrote:
> The problem seems to be that mutt's MIME handler doesn't apply
> text-mode rules to CRLFs in application/pgp messages, even though it
> should. (Another reason why application/pgp is a bad thing in the
> first place.)
And there I went into my own trap (which is, indeed, still another
reason why application/pgp and other non-MIME-related PGP
integrations are bad).
Here's the correct patch:
diff -u -r3.23 handler.c
--- handler.c 21 Oct 2005 04:35:37 - 3.23
+++ handler.c 22 Nov 2005 12:20:46 -
@@ -1754,16 +1754,16 @@
switch (b->encoding)
{
case ENCQUOTEDPRINTABLE:
- mutt_decode_quoted (s, b->length, istext, cd);
+ mutt_decode_quoted (s, b->length, istext || ((WithCrypto &
APPLICATION_PGP) && mutt_is_application_pgp (b)), cd);
break;
case ENCBASE64:
- mutt_decode_base64 (s, b->length, istext, cd);
+ mutt_decode_base64 (s, b->length, istext || ((WithCrypto &
APPLICATION_PGP) && mutt_is_application_pgp (b)), cd);
break;
case ENCUUENCODED:
- mutt_decode_uuencoded (s, b->length, istext, cd);
+ mutt_decode_uuencoded (s, b->length, istext || ((WithCrypto &
APPLICATION_PGP) && mutt_is_application_pgp (b)), cd);
break;
default:
- mutt_decode_xbit (s, b->length, istext, cd);
+ mutt_decode_xbit (s, b->length, istext || ((WithCrypto &
APPLICATION_PGP) && mutt_is_application_pgp (b)), cd);
break;
}
--
Thomas Roessler <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340116: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
The following reply was made to PR mutt/2139; it has been noted by GNATS.
From: Thomas Roessler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2139: messages with base64-encoded CRLF pgp bits can't be read
Date: Tue, 22 Nov 2005 13:13:12 +0100
On 2005-11-21 21:41:36 +0100, [EMAIL PROTECTED] wrote:
> However, I myself was still experiencing the problem for some
> messages. After a bit of investigation, I found out that Mutt was
> failing for base64-encoded messages. For example, this one,
> created by Mutt itself:
> http://people.debian.org/~adeodato/tmp/2005-11-21/base64.mbox
> On further investigation, I saw that it only failed if the result
> of base64-decoding the text contained CRLF. If one takes the
> above message, and recodes the base64 chunk to not contain CRLF,
> it can be opened without problems:
The problem seems to be that mutt's MIME handler doesn't apply
text-mode rules to CRLFs in application/pgp messages, even though it
should. (Another reason why application/pgp is a bad thing in the
first place.)
The following patch should fix this:
--- handler.c 21 Oct 2005 04:35:37 - 3.23
+++ handler.c 22 Nov 2005 12:09:55 -
@@ -1740,7 +1740,7 @@
void mutt_decode_attachment (BODY *b, STATE *s)
{
- int istext = mutt_is_text_part (b);
+ int istext = mutt_is_text_part (b) || ((WithCrypto & APPLICATION_PGP) &&
mutt_is_application_pgp (b));
iconv_t cd = (iconv_t)(-1);
if (istext && s->flags & M_CHARCONV)
One might be tempted to fix this by changing mutt_is_text_part in
the first place (where application/pgp is currently explicitly
flagged as a non-text part). The reason for not doing this is that
mutt_is_text_part is elsewhere used to control all kinds of
character set related logic that does not apply (or only poorly
applies) to application/pgp. (Yet another reason why
application/pgp is a bad thing in the first place. Did I mention
that already?)
Regards,
--
Thomas Roessler <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Thomas Roessler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], Mutt Developers <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Mon, 10 Oct 2005 12:27:54 +0200 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005-10-09 11:03:25 -0400, Derek Martin wrote: > Well, this is very far from my area of expertise; but we all know > someone for whom this kind of issue is near and dear... Does > Werner have anything to say about this? I could do some > research, but I think it would be better to get input from > someone with more experience. FWIW, how does GPG handle this > problem? You can run gpg setuid root so the memory that is used for sensitive information is locked. That helps against having the sensitive information in your swap partition. > I admit, at first glance methods of solving this seem... yucky. > For example, locking memory (so that it does not swap to disk) > requires root privileges on most platforms... making mutt SUID > root seems like a very bad idea. But perhaps mutt could have its > own passphrase agent. In that case, why not re-use gpg's? > In the end, you have a point; methods of attacking the passphrase > in memory require the ability to either assume the user's > privileges, or assume root privileges. If an attacker can do > that, most likely all bets are off anyway. For example, if a > rogue sysadmin were so inclined, he could install a trojaned mutt > which collects private key passphrases. > Still, I'd like to hear what others with more experience than I > have to say about this issue. I think it would be somewhat > reassuring for users who don't control the system(s) on which > they use mutt, and don't have access to gpgagent, if some attempt > at solving this was made. If you don't control a system and don't trust the people who control it, then, please, don't process sensitive information on it. This also applies, by the way, to running gpg-agent or gpg on such systems. Regards, --=20 Thomas Roessler =B7 Personal soap box at <http://log.does-not-exist.org/>. --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3-cvs (GNU/Linux) iIAEARECAEAFAkNKQio5FIAAFQAbcGthLWFkZHJlc3NAZ251cGcub3Jncm9l c3NsZXJAZG9lcy1ub3QtZXhpc3Qub3JnAAoJEMrVFmL0y4amtHMAn3VpuIUCwPsV HQqMTsEa9Q0oqI9jAJ93HccUs1d9DrtO8rQxY/MzCXqwfQ== =88YE -END PGP SIGNATURE- --PuGuTyElPB9bOcsM-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On 2005-10-09 11:03:25 -0400, Derek Martin wrote: > Well, this is very far from my area of expertise; but we all know > someone for whom this kind of issue is near and dear... Does > Werner have anything to say about this? I could do some > research, but I think it would be better to get input from > someone with more experience. FWIW, how does GPG handle this > problem? You can run gpg setuid root so the memory that is used for sensitive information is locked. That helps against having the sensitive information in your swap partition. > I admit, at first glance methods of solving this seem... yucky. > For example, locking memory (so that it does not swap to disk) > requires root privileges on most platforms... making mutt SUID > root seems like a very bad idea. But perhaps mutt could have its > own passphrase agent. In that case, why not re-use gpg's? > In the end, you have a point; methods of attacking the passphrase > in memory require the ability to either assume the user's > privileges, or assume root privileges. If an attacker can do > that, most likely all bets are off anyway. For example, if a > rogue sysadmin were so inclined, he could install a trojaned mutt > which collects private key passphrases. > Still, I'd like to hear what others with more experience than I > have to say about this issue. I think it would be somewhat > reassuring for users who don't control the system(s) on which > they use mutt, and don't have access to gpgagent, if some attempt > at solving this was made. If you don't control a system and don't trust the people who control it, then, please, don't process sensitive information on it. This also applies, by the way, to running gpg-agent or gpg on such systems. Regards, -- Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>. pgpow6Swdr9Dm.pgp Description: PGP signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Thomas Roessler <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Mutt Developers <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Fri, 7 Oct 2005 14:42:51 +0200 On 2005-10-07 04:35:02 +0200, Derek Martin wrote: > Er, well, come on... just because Mutt *can* use an auxiliary > program to handle encryption passphrases securely doesn't mean > mutt itself should completely ignore the issue. As shipped, > mutt is vulnerable. > Admittedly this is not a severe issue, but it is a legitimate > security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Hint: Encrypting the pass phrase with a symmetric key that is kept in memory is *not* a solution to an attack that is based on reading the pass phrase from memory, since the attack is now shifted to the equivalently complex reading of the symmetric key from memory. --=20 Thomas Roessler =B7 Personal soap box at <http://log.does-not-exist.org/>. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On 2005-10-07 04:35:02 +0200, Derek Martin wrote: > Er, well, come on... just because Mutt *can* use an auxiliary > program to handle encryption passphrases securely doesn't mean > mutt itself should completely ignore the issue. As shipped, > mutt is vulnerable. > Admittedly this is not a severe issue, but it is a legitimate > security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Hint: Encrypting the pass phrase with a symmetric key that is kept in memory is *not* a solution to an attack that is based on reading the pass phrase from memory, since the attack is now shifted to the equivalently complex reading of the symmetric key from memory. -- Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.
Bug#275188: decrypt-saving still deleting messages?
Thank you for underlining my point. On 2005-01-17 12:46:45 +0100, Werner Koch wrote: > From: Werner Koch <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], TAKAHASHI Tamotsu <[EMAIL PROTECTED]> > Date: Mon, 17 Jan 2005 12:46:45 +0100 > Subject: Re: decrypt-saving still deleting messages? > Mail-Followup-To: [EMAIL PROTECTED], [EMAIL PROTECTED], > TAKAHASHI Tamotsu <[EMAIL PROTECTED]> > Organisation: g10 Code GmbH > OpenPGP: id=5B0358A2; url=finger:[EMAIL PROTECTED] > X-Spam-Level: > > On Sun, 16 Jan 2005 13:03:47 +0100, Thomas Roessler said: > > > The problem here is that PGP exit values are nontrivial. To give > > just one example, gpg will return exit status 1 when it encounters a > > bad signature; I'm not sure right now whether this includes a > > Don't rely on that. 1 is usually used for expectable data errors and > 2 for all other errors. Only the status-fd gives useful results. > > > > Salam-Shalom, > >Werner > > -- Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.
Bug#275188: decrypt-saving still deleting messages?
On 2005-01-16 04:29:23 +0100, Adeodato Simó wrote: >After some investigation, I've found that, while that fix was >necessary, it is not enough, since pgp_decrypt_part(), in its >current form, does never return NULL. Let's say, it doesn't announce all errors by returning NULL -- some are, indeed, flagged. >This is because, unlike in the rest of pgp.c, the return of >mutt_wait_filter() is not checked. The problem here is that PGP exit values are nontrivial. To give just one example, gpg will return exit status 1 when it encounters a bad signature; I'm not sure right now whether this includes a signature that couldn't be verified because the public key is not known. With your patch, this would be interpreted as a failure to decrypt (in the case of a signed+encrypted attachment), which it isn't. There is a pgp_check_exit variable that may help to take care of some of these effects, but that isn't rocket science, either. >I attach a patch that seems to fix the issue, comments >welcome. I've checked that pgp_decrypt_part returning NULL is >handled gracefully in the other invocation of it. Your patch certainly detects errors, but it will also bail out on non-errors. I'm not sure what's the right way out of this ugliness. Regards, -- Thomas Roessler · Personal soap box at <http://log.does-not-exist.org/>.
