It seems that Solaris has an incorrect implementation of mbrtowc: when
there is an encoding error and mbrtowc returns (size_t)(-1) no value
should be stored in *pwc (the first argument), as I understand it, but
here mbrtowc is storing 8 when presented with the bytes "\xc8\x4d".
However, relying on mbrtowc not to store anything in *pwc when there
is an error is a bit silly; it makes sense to look at the return
value. So, the following patch should be applied if Pawel can confirm
that it fixes the problem. I've tested it and it worked for me with
glibc's mbrtowc.
Vincent Lefevre [Thu, 24 Jul 2003 18:40:50 +0000 (18:40 +0000)]
Some functions/macros like isspace take an int and require the
argument to have the value of an unsigned char (or EOF). Under
Solaris, gcc complains when the argument is a char (as this is a
possible bug, on platforms where char is signed, like Solaris). The
attached patch fixes such problems (well, perhaps I've changed more
than necessary, but this doesn't hurt).
David Shaw [Tue, 22 Jul 2003 12:56:38 +0000 (12:56 +0000)]
When encrypting a message to a user that has more than one subkey,
at least one of which is revoked or expired, mutt treats the entire
key as unusable rather than just the subkey(s) in question.
I noticed that my mutt hung when I tried SASL DIGEST-MD5
authentication (I'm not sure when this started). I believe this
patch should solve that problem in a reliable way.
This patch also attempts to reuse connections even when
authentication fails, instead of just throwing away a perfectly good
socket.
This patch redoes yesterday's unbuffered input patch. Now it uses a
pseudo-option, which means less mess to carry down the call stack.
It also made it much easier to have the SSL certificate menu be
unbuffered, which it is now. So push commands won't annoy you when
entering passwords or accepting certificates.
The attached patch should keep all opened IMAP connections alive, no
matter what mailbox you are currently in. With the patch that got
committed yesterday, this should close bug 1523.
(There was a typo in that patch. This one supersedes it.)
On Sunday, 13 July 2003 at 18:09, Brendan Cully wrote:
> The attached patch should help when the connection to your postponed
> folder times out and you can't reconnect without restarting mutt. I'd
> like anyone who has that problem to try it and let me know how it
> works.
I dug a little deeper. The attached patch seems to work better. It
complains the first time you try to recall a message, but works the
second.
The attached patch prevents mutt from reading the push buffer when
asking for passwords. This is a proper fix for bug 1312. I think
it's uncontroversial.
Thomas Roessler [Fri, 4 Jul 2003 16:57:56 +0000 (16:57 +0000)]
Add a ':' flag to % expandos. This will make sure that any
dots are converted into underscores. (_ is already used for
lowercasing the result of an expando.)
view-attachments does not extract the message within a x-pkcs7-mime
if it's only signed, but not encrypted. Such a message results, for
example, from a decrypt-save if the message was previously encrypted
and signed.
David Shaw [Tue, 13 May 2003 12:43:45 +0000 (12:43 +0000)]
Currently, mutt uses the OpenPGP key algorithm to determine the
capabilities of the key. For example, in mutt, a key of type 1 (RSA)
can both encrypt & sign. This is not correct as per OpenPGP, however,
where the capabilities of the key are determined by both the algorithm
and key capability flags that are set on the key. This can lead to
user confusion when their RSA encrypt-only or sign-only key is listed
for both signing and encryption in mutt.
GnuPG lists these flags in key listings, so it is easy to take
advantage of them. Here is a patch to use the flags, as well as
provide the flags in pgpring. Note that the pgp+pgpring users won't
see any change since the flags there are based on the key algorithm as
they are now, but the GnuPG users will see an improvement.
The "sign (a)s" code strips the pgp application bit causing drawing
issues in redraw_crypt_lines(). Other bits (well bit = encrypt) are
ignored as a result. I've only tested with pgp, but the same
problem exists in the smime code too. This inline patch (against
cvs head revision) fixes the problem.
Thomas Roessler [Mon, 14 Apr 2003 09:09:53 +0000 (09:09 +0000)]
Fix the PGP / S/MIME selection mess in send.c. This patch adds two
new configuration variables, $crypt_autopgp and $crypt_autsmime.
Both are set to "yes" by default. By turning them off, you can
disable the automatic selection of one or both mechanisms. (Useful
when your mutt is PGP- and S/MIME enabled, but you only use, say
S/MIME.)
Thomas Roessler [Tue, 8 Apr 2003 21:41:39 +0000 (21:41 +0000)]
Make sure has_colors() is only invoked when OPTNOCURSES is unset.
This fixes a segmentation fault on RH 8.0 which was observed by Matt
Larson <mlarson@verisign.com>.
Thomas Roessler [Wed, 2 Apr 2003 08:47:28 +0000 (08:47 +0000)]
sample.muttrc-tlr would try to include my color configurations,
which weren't distrubted. Fix that. (Bug noted while helping
someone else to configure mutt during a conference.)
Gary Johnson [Wed, 2 Apr 2003 08:40:50 +0000 (08:40 +0000)]
Here is the patch to fix the bug I reported earlier in this thread,
that sometimes when changing folders, mutt would generate an error
message and stop the further processing of folder-hooks.
David Shaw [Wed, 2 Apr 2003 08:28:24 +0000 (08:28 +0000)]
Here is the pgp_check_exit patch updated for 1.5.4. This patch adds
the pgp_check_exit option (enabled by default) that causes mutt to
check the exit code of the PGP subprocess. A non-zero exit code means
that the subprocess failed and mutt will not continue to send the
message.
This is needed as in certain cases, PGP or GnuPG can fail to
completely process a document (say, if the gpg.conf file is mangled,
which is how I discovered the problem). Without an exit code check,
mutt will continue anyway and send the half processed file.