Bug#1024427: reproducible segfault in bullseye mutt

[Kevin J. McCarthy]

Note this was fixed in Mutt 2.2.8.  See 
https://gitlab.com/muttmua/mutt/-/issues/428 for the Mutt bug report.


This important fix is at: 
https://gitlab.com/muttmua/mutt/-/commit/48b6ea32e21db8b580cd3ca8c346c3e2c22756f6.patch


There are two related commits, that may be of interest in backporting 
too, but aren't the cause of this segfault:

https://gitlab.com/muttmua/mutt/-/commit/f0eb3586480c301b66657c7326b6546ef086c7f4.patch
https://gitlab.com/muttmua/mutt/-/commit/b254f2fb44f994c48e2491adaf03d97d3c628283.patch

-Kevin


signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Mon, Nov 21, 2022 at 02:53:14PM +0100, Juan Pedro Vallejo wrote:

Yes, you were right.

Architecture: i386 (i686)


Thank you Juan.  So you are running the i386 mutt package on an i386 
architecture.  I believe this means something is wrong the package 
building environment.


I've just looked again at the Mutt configure/makefile related to 
mutt_dotlock, and it turns out Mutt always installs as group 'mail' when 
setting sgid:


configure.ac:
=
if test x$mutt_cv_setgid = xyes; then
DOTLOCK_GROUP='mail'
DOTLOCK_PERMISSION=2755
else
DOTLOCK_GROUP=''
DOTLOCK_PERMISSION=755
fi
AC_SUBST(DOTLOCK_GROUP)
AC_SUBST(DOTLOCK_PERMISSION)

Makefile.am:

if test -f $(DESTDIR)$(bindir)/mutt_dotlock && test x$(DOTLOCK_GROUP) 
!= x ; then \
chgrp $(DOTLOCK_GROUP) $(DESTDIR)$(bindir)/mutt_dotlock && \
chmod $(DOTLOCK_PERMISSION) $(DESTDIR)$(bindir)/mutt_dotlock || 
\
{ echo "Can't fix mutt_dotlock's permissions!  This is required to lock 
mailboxes in the mail spool directory." >&2 ; exit 1 ; } \
fi


The content of the various mutt deb files:
==
% for deb in *; do echo $deb; dpkg -c $deb | grep bin/mutt_dotlock; echo; done
mutt_2.2.9-1_amd64.deb
-rwxr-sr-x root/mail 14584 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_arm64.deb
-rwxr-sr-x root/mail 67680 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armel.deb
-rwxr-sr-x root/root 67108 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_armhf.deb
-rwxr-sr-x root/root 67120 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_i386.deb
-rwxr-sr-x root/root 13804 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mips64el.deb
-rwxr-sr-x root/mail 68648 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_mipsel.deb
-rwxr-sr-x root/root 67732 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_ppc64el.deb
-rwxr-sr-x root/mail 67760 2022-11-13 09:01 ./usr/bin/mutt_dotlock

mutt_2.2.9-1_s390x.deb
-rwxr-sr-x root/mail 14432 2022-11-13 09:01 ./usr/bin/mutt_dotlock


I'm not sure what is going wrong, but armel, armhf, i386, and mipsel are 
failing to chgrp to mail during the package building.


Antonio I'll need your help to figure out what is going on in this case. 
Since this renders the program unusable for working with spoolfile mail, 
I think this ought to be bumped to 'serious'.


-Kevin



signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Sun, Nov 20, 2022 at 01:50:41PM +0100, Juan Pedro Vallejo wrote:

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock


Thanks for the information.  What architecture are you running on?  The 
amd64 package installs properly with sgid mail.


However, I did check the various packages for 2.2.9, and it looks like 
the i386 package does not.  Are you running i386 architecture, or did 
you install the i386 package on an amd64 architecture?


I don't know if this is a bug in the i386 packaging environment, or if 
the mail directories on i386 are different.  I'm Cc'ing Antonio to see 
if he has any input.


-Kevin


signature.asc
Description: PGP signature

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

[Kevin J. McCarthy]

I've just released mutt 2.2.9, which I believe should fix this problem.

-Kevin


signature.asc
Description: PGP signature

Bug#1023599: mutt: FTBFS due to lack of gpgme-config since gpgme1.0 1.18.0-2

[Kevin J. McCarthy]

On Mon, 7 Nov 2022 13:04:04 +0100 Vincent Lefevre  wrote:

The gpgme-config utility was removed in gpgme1.0 1.18.0-2
(because it needs gpg-error-config, which has been removed).

As a consequence the use of --enable-gpgme to build Mutt yields
an error:


Just as a note, with Vincent's help, I've commited two patches to the 
stable branch, updating to the most recent GPGME autoconf files and 
adjusting AM_PATH_GPG_ERROR before AM_PATH_GPGME:


https://gitlab.com/muttmua/mutt/-/commit/012981e8434903e8b5ae5f099b026b9a64426129.patch
https://gitlab.com/muttmua/mutt/-/commit/527537027b0c9134192663c9d3ec01d6cea6c5c2.patch

I will try to get a Mutt release out later this week with these two 
commits, but if you need the fix sooner, please grab the above patches.


-Kevin


signature.asc
Description: PGP signature

Bug#1014524: mutt: Mutt depends on moreutils package, but, it is not listed on dependencies, nor suggestions

[Kevin J. McCarthy]

On Thu, 7 Jul 2022 08:17:26 -0300 Marcelo Laia  wrote:

Mutt depends on moreutils package, but, it is not listed on dependencies, nor
suggestions.

I see that pee is necessary to open html messages.

With out moreutils package, when I try to open a html messages, it shows:

sh: 1: pee not found


This is most likely a system or user configuration issue.  Mutt uses 
mailcap to decide how to deal with attachments.  See the section in the 
manual  for more details about 
how that works.


AFAIK, nothing internal to Mutt (or its default shipped configuration) 
is trying to use "pee".  I would check the system mailcap /etc/mailcap 
for the first text/html entry, and also your ~/.mailcap file (if 
present) to see if that gives any hints about what is going on in your 
case.


-Kevin

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Kevin J. McCarthy]

On Sat, 30 Apr 2022 13:39:07 -0700 "Kevin J. McCarthy"  wrote:

On Thu, Apr 28, 2022 at 01:36:10PM -0700, Kevin J. McCarthy wrote:
>I don't know if you've compiled Mutt from git before, but if you are 
>able and willing to try, I would appreciate hearing it that helped 
>with your problem.


I've just released version 2.2.4 with a fix that I believe will also
address your issue.

When you have a chance to test against 2.2.4, would you mind updating this
ticket to confirm/deny that is the case?


Bob would you mind confirming that 2.2.4 fixes this issue for you?

Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

[Kevin J. McCarthy]

I've pushed the fix into the stable branch: 
, 
and will release 2.2.5 in the next few days.


My apologies for the botched patch file included in my previous email. 
I realized I did this when backing out format=flowed formatting and 
accidentally trimmed a trailing space in the patch itself.


-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

[Kevin J. McCarthy]

On Fri, May 13, 2022 at 11:24:44PM +, brian m. carlson wrote:

I built the Debian package with the patch applied below.  It didn't
quite apply cleanly with patch -p1, but I copied and pasted the change.
It does appear to work, and I'm using the patched version to send this.

Thanks so much for the fast turnaround time.


That's fantastic news!  Thank *you* for testing the patch.  Not sure why 
it didn't apply cleanly, but I'm glad you were able to make the changes 
yourself.


I'll give a little more time for Gábor to reply, but unless there is a 
problem, will commit this to stable this weekend, and will try to get a 
release out in the next week.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

[Kevin J. McCarthy]

On Fri, 13 May 2022 15:02:38 -0700 "Kevin J. McCarthy"  wrote:
> Thanks for the bug report.  Yes, it most definitely is.  I'll take a
> look to see what I can find.  Perhaps I've missed setting up some
> callback information that gsasl needs.
>
> Would you be able to test a patch if/when I create one?  If so, please
> make sure you are subscribed to this ticket and I'll work on something
> this weekend.

Brian and Gábor, I did indeed miss a callback value needed by GSSAPI:
hostname.  The Mutt IMAP/GSSAPI auth code is using the server hostname
for this field, contradicting the gsasl documentation which says to
supply the "local host name".  I'm trying the server hostname below.

If possible could you try either the git branch
'kevin/gsasl-gssapi-fixes' on GitLab
<https://gitlab.com/muttmua/mutt/-/commits/kevin/gsasl-gssapi-fixes> or
alternatively try recompiling the source Debian package with the below
patch applied?

Thank you!

- - - - - - 8< - - - - -

 From 9db29e904d1843a61b3a858d16d400af704fdadf Mon Sep 17 00:00:00 2001
From: Kevin McCarthy 
Date: Fri, 13 May 2022 15:37:58 -0700
Subject: [PATCH] Set gsasl hostname callback value.

This is needed for GSSAPI, and apparently DIGEST-MD5 too.

The documentation is a little vague, saying it "should be the local
host name of the machine", however the imap/auth_gss.c code seems to
be using the server-name.
---
  mutt_sasl_gnu.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/mutt_sasl_gnu.c b/mutt_sasl_gnu.c
index 7ebe4293..37d39657 100644
--- a/mutt_sasl_gnu.c
+++ b/mutt_sasl_gnu.c
@@ -219,6 +219,11 @@ static int mutt_gsasl_callback (Gsasl *ctx, Gsasl_session 
*sctx,
rc = GSASL_OK;
break;
  
+case GSASL_HOSTNAME:
+  gsasl_property_set (sctx, GSASL_HOSTNAME, conn->account.host);
+  rc = GSASL_OK;
+  break;
+
  default:
break;
}
-- 
GitLab



signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

[Kevin J. McCarthy]

On Fri, 13 May 2022 17:54:14 +0200  wrote:

I've run into this issue too, and it is clearly gsasl which is broken:

[2022-05-13 17:40:38] smtp_authenticate: Trying method GSSAPI LOGIN PLAIN
[2022-05-13 17:40:38] mutt_gsasl_get_mech() returned no usable mech
[2022-05-13 17:40:38] No authenticators available


Gabor, there is a problem with gsasl, which I'll try to work on this 
weekend.  If you can help test patches, please make sure you are 
subscribed to this ticket.


However, you'll also need to fix your $smtp_authenticators value - it 
should be colon separated, for example: "GSSAPI:LOGIN:PLAIN".


-Kevin


signature.asc
Description: PGP signature

Bug#1010915: mutt: GSSAPI SMTP authentication no longer works

[Kevin J. McCarthy]

On Fri, 13 May 2022 01:58:53 + "brian m. carlson" 
 wrote:

I use Kerberos on my personal network at home, and therefore I use
GSSAPI authentication for IMAP and SMTP.  While GSSAPI with IMAP works
fine, recently, GSSAPI with SMTP stopped working.  I suspect this is
related to the move to gsasl.


Thanks for the bug report.  Yes, it most definitely is.  I'll take a 
look to see what I can find.  Perhaps I've missed setting up some 
callback information that gsasl needs.


Would you be able to test a patch if/when I create one?  If so, please 
make sure you are subscribed to this ticket and I'll work on something 
this weekend.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: set smtp_authenticators=login works!

[Kevin J. McCarthy]

On Thu, May 12, 2022 at 04:57:55PM +0200, Václav Ovsík wrote:

I have added

set smtp_authenticators=login

and things works now!


Great!  Thank you for checking that LOGIN works properly.  I wanted to 
make sure there weren't other problems I needed to address inside Mutt.



So the problem is with the SMTP server side?


Technically it is, but I have made a commit in Mutt to work around the 
bug.  It will be in 2.2.5, or earlier if Antonio decides to add the 
patch to the Debian package.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Kevin J. McCarthy]

On Fri, 6 May 2022 13:04:50 -0700 "Kevin J. McCarthy"  wrote:
However, in the mean time I've pushed a commit up to branch 
'kevin/gsasl-smtp-plain-workarounds' on gitlab:


I've merged this branch into stable, and it will be a part of 2.2.5 
sometime in the next few weeks.


Antonio if this starts to cause problems for others and 2.2.5 isn't out 
yet, feel free to grab the patch and apply to 2.2.4-2:


https://gitlab.com/muttmua/mutt/-/commit/9d5db7cb7e53be20bb3b87dd5877e7145660b931.patch

-Kevin


signature.asc
Description: PGP signature

Bug#599309: mutt: Reply->Postpone->Recall loses message associations

[Kevin J. McCarthy]

On Thu, 30 Dec 2010 13:56:51 + Antonio Radici  wrote:

tag 599309 +confirmed upstream
thanks

Hi Toni,
thanks for your report, I will forward this issue upstream.


The threading issue was fixed upstream in commits

1) 3c44f482
   


2) 31bc8262
   


The second commit was released with Mutt 1.8.0.

This should set reply flag in parent *provided* you are still in the 
same mailbox when you recall the message.


If you believe this addresses the issue adequately, please feel free to 
close it.  Thank you.


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Kevin J. McCarthy]

On Fri, 6 May 2022 11:18:39 -0700 "Kevin J. McCarthy"  wrote:
According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


I'm still interested to hear if 'set smtp_authenticators=login' works 
for you, just to make sure there isn't another issue I need to be aware 
of.


However, in the mean time I've pushed a commit up to branch 
'kevin/gsasl-smtp-plain-workarounds' on gitlab: 
<https://gitlab.com/muttmua/mutt/-/commit/85379c5a01168154f74a7d9841d1eab152b1b6b0.patch>


Would you be willing to try that patch - either via compiling from git, 
or modifying the deb package and adding the patch to it?


thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010658: mutt: SMTP SASL authentication broken (base64 encoding?)

[Kevin J. McCarthy]

On Fri, 06 May 2022 12:03:27 +0200 Vaclav Ovsik  wrote:

after Mutt upgrade from version 2.1.4-1 to version 2.2.3-2 SASL
authentication stopped working.

Debug from Mutt version 2.2.3:
[...]



 [2022-05-06 10:33:39] smtp_auth_gsasl: using mech PLAIN
 [2022-05-06 10:33:39] Authenticating (PLAIN)...
 [2022-05-06 10:33:39] 5> AUTH PLAIN^M
 [2022-05-06 10:33:39] 5< 334 Send base64(login\0login\0password)
 [2022-05-06 10:33:39] gsasl_step64() failed (8): Base 64 coding error in SASL 
library


According to my understanding of RFC4954, the "server challenge" 334 
response must either be blank (i.e., "334 "), or if there is data it 
must be base64 encoded.


The Cyrus SASL library also assumes all data from the server will be 
base64 encoded, but it is smarter and knows it can send an initial 
response with AUTH PLAIN.


What happens if you set smtp_authenticators=login?  Does the server also 
send plain text in the 334 response?


-Kevin



signature.asc
Description: PGP signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

[Kevin J. McCarthy]

On Tue, May 03, 2022 at 12:00:44PM -0400, ant wrote:

 i don't explicitly set that variable anywhere in any of my mutt
profiles that i know of.  unsetting that does allow mutt to send
mail again using the 2.2.3-2 version so that did take care of the
problem.  thank you!  :)


I'm glad that fixed the problem.  But I think it would be worth 
investigating a bit more where the assignment came from.  From my most 
recent email (which I think arrived after you sent this one), it looks 
like the assignment, wherever it is, is using non-ascii quote-marks.


Mutt is actually *including* the unicode curly-quotes as part of the 
method value.  I think cyrus sasl must have been lax, but the gnu sasl 
code is picky about the value being legal.


So it can't actually find a method '”cram-md5”' in the list 'PLAIN LOGIN 
CRAM-MD5' provided by the server.


I think this bug can be closed, but I'd still like to hear if you found 
where it was coming from.  :-)


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

[Kevin J. McCarthy]

On Mon, 2 May 2022 20:35:13 -0700 "Kevin J. McCarthy"  wrote:
I'll try to see if I can duplicate the problem, but I don't have access 
to a smtp server supporting cram-md5.  Is the server you are using 
accessible for me to try (and of course fail) authenticating with?


I've just noticed one funny thing in your debug log:

[2022-05-02 19:11:00] smtp_authenticate: Trying method ”cram-md5”

The method name should not include any kind of quoting, and those seem 
to be non-ascii quote marks.


I wonder if you've accidentally copy/pasted non-ascii quotes in your 
muttrc 'set smtp_authenticators' line.  Try deleting the quote marks and 
manually re-type ascii double-quote (or single-quotes) around the value:

  set smtp_authenticators="cram-md5"

-Kevin


signature.asc
Description: PGP signature

Bug#1010500: mutt: Testing upgrade to 2.2.3-2 breaks sending mail

[Kevin J. McCarthy]

On Mon, 02 May 2022 19:20:29 -0400 ant  wrote:

Package: mutt
Version: 2.2.3-1


Just checking this is for 2.2.3-2.  That update switched to the gsasl 
library, which unfortunately needs some bugs worked out with its mutt 
implementation.  :-(


From the debug log, it looks like you have $smtp_authenticators set. 
What happens if you unset that variable, does authentication work in 
that case?  What if you explicitly set $smtp_authenticators to "login" 
or "plain"?


I'll try to see if I can duplicate the problem, but I don't have access 
to a smtp server supporting cram-md5.  Is the server you are using 
accessible for me to try (and of course fail) authenticating with?


-Kevin


signature.asc
Description: PGP signature

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Kevin J. McCarthy]

On Thu, Apr 28, 2022 at 01:36:10PM -0700, Kevin J. McCarthy wrote:
I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped 
with your problem.


I've just released version 2.2.4 with a fix that I believe will also
address your issue.

When you have a chance to test against 2.2.4, would you mind updating this
ticket to confirm/deny that is the case?

Thank you,

-Kevin

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Kevin J. McCarthy]

On Wed, 27 Apr 2022 15:10:09 -0700 "Kevin J. McCarthy"  wrote:
One change in 2.2.x was normalizing Maildir paths when opening them 
(as IMAP does) - removing a trailing delimiter.  This might cause the 
behavior you are describing.


Until I hear otherwise, I've been assuming the problem is because of 
this change.  Nothing of substance changed in the buffy routines that I 
can see.


I've pushed a couple possible commits up to branch 
'kevin/buffy-check-fixes' in the Mutt git repository: 
<https://gitlab.com/muttmua/mutt/-/commits/kevin/buffy-check-fixes>. 
The second commit is a bit more aggressive/dangerous, but may be more 
thorough at fixing other related issues.


I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped with 
your problem.


Thank you,

-Kevin

Bug#632570: fails to join RFC 2231 continuations

[Kevin J. McCarthy]

On Mon, 13 Dec 2021 19:34:21 -0800 "Kevin J. McCarthy"  wrote:

I believe this was fixed in Mutt 1.6.0, and this ticket can be closed.


Again, this bug should be close-able.  Thank you!

-Kevin


signature.asc
Description: PGP signature

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Kevin J. McCarthy]

On Sun, 17 Apr 2022 14:20:54 -0600 Bob Proulx  wrote:

Starting with 2.2.3-1 the 'c' change-folder action now prompts with
the *previous folder always* and never prompts with any other folders.
It no longer selects a mailboxes folder with new mail.  It prompts
with the previous folder even if no new mail has arrived there.
Effectively creating a situation where one toggles between two folders
endlessly.


Bob, what type of mailbox are you using (Maildir, mbox, IMAP...)

What do your `mailboxes` lines in your muttrc look like?  Do they have a 
trailing slash?  If so, does the problem go away if you remove the 
trailing slash?


One change in 2.2.x was normalizing Maildir paths when opening them (as
IMAP does) - removing a trailing delimiter.  This might cause the
behavior you are describing.

-Kevin

Bug#999672: mutt: license conflict with libsasl2

[Kevin J. McCarthy]

On Wed, Dec 15, 2021 at 01:30:29PM -0800, Kevin J. McCarthy wrote:
I'm starting to look into adding libgsasl support.  Since I haven't 
touched the SASL code in Mutt that much, I need to proceed with 
caution. It may not make it into the 2.2.0 release, but if not I will 
try to have it in the 2.3.0 release late next year.


I've just added a commit to the master branch supporting '--with-gsasl' 
configuration and support for IMAP, SMTP, and POP3 authentication.


I have confidence there *will* be issues that need to be ironed out, but 
my plan is to release it with version 2.2.0, sometime early next year.


-Kevin


signature.asc
Description: PGP signature

Bug#999672: mutt: license conflict with libsasl2

[Kevin J. McCarthy]

On Sun, 14 Nov 2021 18:51:51 +0100 Bastian Germann  wrote:
mutt depends on libsasl2-2, which is licensed under CMU's BSD-4-clause license and covered by the RSA-MD and OpenSSL 
licenses. All of them have an advertisement clause in place, which is known to be incompatible with GPL.

There are several possible solutions to this problem:

1) Build without SASL support.

2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL 
for a long time.


I'm starting to look into adding libgsasl support.  Since I haven't 
touched the SASL code in Mutt that much, I need to proceed with caution. 
It may not make it into the 2.2.0 release, but if not I will try to have 
it in the 2.3.0 release late next year.


Of course, if there is a way to get a license exception, that would be 
useful too, as there may be regressions with a different SASL library. 
If this is something I need to do, I would appreciate any pointers about 
the process.


Thank you,

-Kevin


signature.asc
Description: PGP signature

Bug#982555: mutt: Messages sent by Gmail SMTP are recorded in sent box with wrong charset/encoding

[Kevin J. McCarthy]

On Thu, 11 Feb 2021 16:40:53 -0300 Marcelo Luiz de Laia  
wrote:

Package: mutt
Version: 2.0.5-1
Severity: minor

Dear Maintainer,

After upgrade to mutt:amd64 2.0.5-1, messages sent by gmail was recorded in
sent box with wrong charset, like this:

Finalizei a inser��o das ATA no Processo.
S�o seis ATA e um documento resumo.
Encaminhei ao Louren�o e Angelo para leitura e assinatura.
Fique � vontade para revisar.
Abra�os!

These messages have the headers:

Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

This is the same headers present in previous messages sent with mutt 2.0.2-1.


I've reviewed the changes between 2.0.2 and 2.0.5 and there was nothing 
fixed related to character set handling or saving of messages.


Do you have $record set, or have you left it empty?  What is your value 
of $send_charset?  Are you still having this problem?


-Kevin


signature.asc
Description: PGP signature

Bug#965948: mutt: Incorrect handling of whitespace in aliases file

[Kevin J. McCarthy]

On Tue, 21 Jul 2020 11:38:18 +0100 Matthew Foulkes  
wrote:

Package: mutt
Version: 1.14.5-1
Severity: minor
X-Debbugs-Cc: m.foul...@blueyonder.co.uk

Dear Maintainer,

Before version 1.14.15-1, mutt used to ignore extra whitespace between 
the end of the long name and the beginning of the email address in the 
aliases file. Given an aliases file organised into columns


alias   alice  Alice Aardvark
alias   bobBob Bee   

typing "mutt alice" would have generated an email with

To: Alice Aardvark 

Since the update to 1.14.15-1, all whitespace following the long name is 
preserved exactly and you get


To: Alice Aardvark


I think this was a consequence of +EXACT_ADDRESS being configured. 
Since the Debian package now has that turned off, I think this bug 
should be resolved.


-Kevin


signature.asc
Description: PGP signature

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Thu, 08 Jul 2021 19:26:06 +0200 "Hans-J. Ullrich"  
wrote:

Package: mutt
Version: 2.0.5-4.1
Severity: important

Dear Maintainer,

it looks like, that mutt is not able to delete mails due to access rights. 
I checked the settings of the files and directories, but these seem to be ok for me. 
This is the output: 

ls -la / | grep var 
drwxr-xr-x  14 root root4096 18. Mai 11:33 var 

ls -la /var | grep mail 
drwxrwsr-x   2 root mail   4096  8. Jul 16:02 mail 

ls -la /var/mail/myusername 
-rw-rw 1 myusername mail 55330396  8. Jul 16:02 /var/mail/myusername 


(The term "myusername" is an alias for my real username)

When I remember correctly, this bug appeared in the past from time to time and 
was fixed. Now it appears again.

It would be nice, if you could take a look at it.

Thank you and best regards


Sorry I also can't duplicate this problem.  This ticket, in addition to 
#969279 seem to hint something is very odd about your system or your 
configuration.


Perhaps more details would help illuminate the problem.  Can you 
duplicate it with a minimal muttrc file?  Does it happen just with your 
spoolfile, or with other mbox files in your home directory?  Is there a 
problem with the mutt_dotlock program installation?  What error messages 
are you getting?


-Kevin



signature.asc
Description: PGP signature

Bug#969279: mutt - could not create tempory files

[Kevin J. McCarthy]

On Tue, 31 Aug 2021 11:09:30 +0200 "Hans-J. Ullrich"  
wrote:

Package: mutt
Version: 2.0.5-4.1
Followup-For: Bug #969279

Dear Maintainer,

I can confirm this issue now for almost half a year, maybe longer. 
However, this issue appears only on amd64, on i386 it seems to work well.


Sorry, I can't duplicate this problem.  You'll need to provide more 
details, and steps to reliably reproduce.


What is $tmpdir set to?  Does this only happen when you tag-delete *all* 
messages and quit, or are there other circumstances?  Does this happen 
just for your $spoolfile, or does it also happen for mailboxes in your 
home directory?  What about maildir vs mbox files?


-Kevin


signature.asc
Description: PGP signature

Bug#671847: [Mutt] #3879: mutt: encoded-words are not decoded in mailto:

[Kevin J. McCarthy]

On Sat, 01 Oct 2016 21:01:11 - 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:  reopened => closed
 * resolution:   => fixed


Antonio, I believe this ticket can be closed now, since it was fixed in 
1.7.


-Kevin


signature.asc
Description: PGP signature

Bug#986368: mutt: Add support for client certificate without AUTH in smtp

[Kevin J. McCarthy]

On Sun, 4 Apr 2021 15:32:59 +0200 Adam Majer  wrote:

Current implementation of mutt always seems to ask for SMTP username
even if one is not set in the config (smtp_url) and AUTH is not
an allowed option of submit server. This then results in an email
send failure

  SMTP server does not support authentication

The patch that fixes this issue is at and also attached.

https://gitlab.com/muttmua/mutt/-/commit/191b0513b43d5e603f99292faa5f8ebcc1be3823.patch

I've tested this patch in the tagged version and the problem is solved.
Please consider adding it to mutt for next upload.


With 2.1.3 uploaded now, I think we can close this ticket now.

-Kevin


signature.asc
Description: PGP signature

Bug#838992: mutt: using mutt, will not default to home mail directory: "c", "?" with "set folder" remains in /var/mail

[Kevin J. McCarthy]

On Tue, 27 Sep 2016 09:56:38 -0400 jackson  wrote:

Package: mutt
Version: 1.7.0-6
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
 Upgrading from older version
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 No change, as of yet, in config file ameliorates this behavior
   * What was the outcome of this action?
No change 
   * What outcome did you expect instead?

 "set folder" has changed

*** End of the template - remove these template lines ***


-- Package-specific info:
NeoMutt 20160916 (1.7.0)



The emails in this ticket all actually show NeoMutt in the "package 
specific info" section.


I can't reproduce the bug, so perhaps it was a temporary NeoMutt bug?

Would someone confirm they can produce this with the latest *Mutt* 
release.  If not, perhaps we can close this ticket.


-Kevin


signature.asc
Description: PGP signature

Bug#995881: mutt: displays text/html raw instead of using mailcap

[Kevin J. McCarthy]

On Thu, 07 Oct 2021 18:04:53 +0200 Anton Ertl 
 wrote:

Package: mutt
Version: 2.0.5-4.1
Severity: normal

Dear Maintainer,

I viewed a text/html email, shown as plain text.  Selecting v to view
attachments, and then selecting the text/html part and typing Enter
also showed the plain text.

I expected that lynx would be invoked when I type Enter when viewing
attachments, like in Debian 9.  /etc/mailcap contains several lines
for dealing with text/html, and adding such a line to ~/.mailcap did
not make a difference.

This seems to be a new incarnation of bug 823971.  Fortunately the
same workaround of using "m" instead of Enter in the attachment
viewing mode works.


Sorry, using "m" isn't a "workaround".  The default bindings in upstream 
Mutt have *always* been  =>  and "m" => 
.


At one point, Debian's version carried an external patch changing the 
default keybinding, but Debian is now using a minimally changed version 
of Mutt.


Antonio can pipe in about his intentions with respect to the Debian 
package, but personally I have no plans on changing the default in 
upstream.


Of course, you are free to rebind to your tastes yourself!  :-)

-Kevin


signature.asc
Description: PGP signature

Bug#961247: mutt -s'a b c' x < somefile sends post also to "b" and "c"

[Kevin J. McCarthy]

On Thu, 21 May 2020 23:08:03 + Bjarni Ingi Gislason  
wrote:

Package: mutt
Version: 1.14.0-1+b1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

mutt -s'Test the mailer' bg <  


The '-s' argument requires a space between it and the subject to be 
used.


Mutt uses the standard function getopt() for argument parsing.  With it, 
you can combine more than one option letter behind a single hyphen.  So, 
e.g. 'mutt -vv' is the same as 'mutt -v -v'.


I believe the documentation shows the usage correctly.  If there is some 
place showing the usage incorrectly, please let me know.


Otherwise I believe this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature

Bug#958903: mutt: Broken file name in attachment if file name has cyrillic symbols (file name charset is UTF-8)

[Kevin J. McCarthy]

On Sun, 26 Apr 2020 16:34:57 +0300 Andrey Stankevich 
 wrote:

Package: mutt
Version: 1.10.1-2.1
Severity: normal

Dear Maintainer,

I attached file to outgoing mail in mutt.
File name has cyrillic symbols.
Number of cyrillic symbols in file name is bigger than approximately forty 
symbols.

In this case attached file has broken name in attachment in mutt (the file name 
is truncated to approximately forty symbols).
So recipient's MUA receive broken file name in attachment.
For example google mail named that attachment file as "noname".

It is expected nontruncated file name in attachment or warning message in case 
of file name truncating or warning message in status line should be in this 
case.


This was fixed in Mutt 1.12.0.  I believe this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature

Bug#899992: mutt: allow spaces in "Open mailbox" prompt

[Kevin J. McCarthy]

Would it be possible to support mailboxes with spaces (and/or some
syntactic sugar to not have to type "notmuch://?query=" all the time)?


There are a couple solutions within your control.  You can rebind the 
editor menu  function to another key (or to noop): it 
defaults to space.  Alternatively, you can invoke , which 
defaults to control-v, before each space character.


-Kevin


signature.asc
Description: PGP signature

Bug#632570: fails to join RFC 2231 continuations

[Kevin J. McCarthy]

On Mon, 04 Jul 2011 00:59:46 +0900 Akihiro Terasaki  wrote:

mutt fails to join continuations.

Content-Disposition: attachment;
filename*0=foo;
filename*1=.;
filename*2=txt

mutt prints `footxt.', rather than the expected `foo.txt'.


I believe this was fixed in Mutt 1.6.0, and this ticket can be closed.

-Kevin


signature.asc
Description: PGP signature

Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

[Kevin J. McCarthy]

On Mon, 13 Dec 2021 19:00:47 -0800 "Kevin J. McCarthy"  wrote:
2.0.4 just came out, so I likely won't release 2.0.5 for at least a few 
weeks.


However, Antonio if you get around to packaging 2.0.4 before the 
release, feel free to grab the patch file.


Sigh... it's been a long day.  That should be 2.1.5 and 2.1.4.

-Kevin


signature.asc
Description: PGP signature

Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

[Kevin J. McCarthy]

On Mon, 13 Dec 2021 15:21:19 -0800 "Kevin J. McCarthy"  wrote:
I'll add a commit to the stable branch for 2.0.5, reverting the behavior 
to have either the smtp username or a client cert set before attempting 
authentication when AUTH is advertised.


I've added 
<https://gitlab.com/muttmua/mutt/-/commit/91474fdff648bb9e0b30c371a29c856e2c0d1448.patch> 
to the stable branch.


2.0.4 just came out, so I likely won't release 2.0.5 for at least a few 
weeks.


However, Antonio if you get around to packaging 2.0.4 before the 
release, feel free to grab the patch file.


-Kevin


signature.asc
Description: PGP signature

Bug#1001013: mutt: 2.1.x regression - SMTP AUTH mandated if available

[Kevin J. McCarthy]

On Thu, 2 Dec 2021 18:51:39 +0100 Andreas Metzler  wrote:

After todays mutt upgrade (from 2.0) mutt suddenly *requires* successful
SMTP AUTH when sending mail, at least when the SMTP server advertises
AUTH support. (My server=localhost offers AUTH, but does not require it).
There does not seem to be a way to configure mutt to send without
successful SMTP AUTH.
With
smtp_url="smtp://localhost"
and unset smtp_pass now mutt prompts for user/password. Changing
smtp_authenticators to an value not offered by the server yields
SASL authentication failed
and setting smtp_authenticators="invalid" yields
No authenticators available


Sorry this was a mistake in fixing client-certificate authentication.  I 
incorrectly assumed if the server was advertising AUTH at that point it 
was required.


I'll add a commit to the stable branch for 2.0.5, reverting the behavior 
to have either the smtp username or a client cert set before attempting 
authentication when AUTH is advertised.


-Kevin


signature.asc
Description: PGP signature

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Kevin J. McCarthy]

On Tue, Nov 23, 2021 at 08:45:47PM +0100, Hannes von Haugwitz wrote:

Is there any progress with this bug?


Mutt 2.1.3 included the corrected sort commit referenced in my last 
email.  So, for unstable/testing it would be nice to get 2.1.3 uploaded.


For stable/oldstable I guess it rests in the hands of Debian process, 
but ideally the three links from my last email would be backported to 
those.


-Kevin

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Kevin J. McCarthy]

On Tue, Sep 07, 2021 at 08:20:49PM -0700, Kevin J. McCarthy wrote:
I think the probability of users encountering that in practice is low. 
But if you're going through the effort of back-porting the fix, please 
wait and I'll commit a corrected fix tomorrow.


This is still on a branch, waiting for some feedback/testing, but for 
now you can see the corrected sort at:

https://gitlab.com/muttmua/mutt/-/commit/fa2fef4618ed45d9f4011ea76fd8bc3844d59c88

This is applies on top of the commit from 2.1.2:
https://gitlab.com/muttmua/mutt/-/commit/647efbd151ee452eaca5f42e4f636a5ed7a32331

which depends on this commit if backported earlier than 1.13.4:
https://gitlab.com/muttmua/mutt/-/commit/6051760c2cf492ada1e06d910c0c2c05607c08bc

-Kevin

Bug#992927: mutt: Mutt 2.1.2 is available, fixing a potential data-loss IMAP bug

[Kevin J. McCarthy]

Antonio,

I was going through recent Mutt commits, and I realized my fix for this 
is not quite correct.


The IMAP UID field is a 32-bit unsigned integer.  I unfortunately 
modeled the new compare_uid() function after all the other ones use by 
Mutt for sorting, which just uses subtraction.  However, that won't work 
properly if the values differ more than a signed int can hold.


I think the probability of users encountering that in practice is low. 
But if you're going through the effort of back-porting the fix, please 
wait and I'll commit a corrected fix tomorrow.


-Kevin

Bug#980326: mutt: diff for NMU version 2.0.2-1.1

[Kevin J. McCarthy]

On Wed, Jan 20, 2021 at 10:36:59PM +0100, Antonio Radici wrote:

yes that will definitely help so we will get additional commits that are not 
yet in 2.0.4.

If you can't make it by the weekend I should be able to find some time 
on Mon/Tue to do the upload!


I've just released 2.0.5.  For this bug, it only contains the actual 
memory leak fix 
.


I was sorely tempted to include the other fix 
, 
but in the end decided to be disciplined with a stable release.


There are actually a couple more fixes I plan on making to group 
parsing, but again in master, where they will have a bit more time to 
bake and uncover potential problems.


Thanks for making an upload.  It will be good to have the bug fixes in 
2.0.3+ in the next Debian release!


-Kevin





signature.asc
Description: PGP signature

Bug#980326: mutt: diff for NMU version 2.0.2-1.1

[Kevin J. McCarthy]

On Tue, Jan 19, 2021 at 08:47:01PM +0100, Antonio Radici wrote:

Thanks for the patch, I will upgrade to the latest upstream version by Sunday
this week


Antonio, if it helps, I can try to get a 2.0.5 release out before the 
weekend.


-Kevin


signature.asc
Description: PGP signature

Bug#966100: notmuch-mutt: symlinking now fails for indexed mailboxes with a space in the name

[Kevin J. McCarthy]

On Tue, Aug 11, 2020 at 11:24:16AM -0300, David Bremner wrote:

If you can, please test the upstream patch

  
https://nmbug.notmuchmail.org/nmweb/show/20200727193833.4654-1-tomi.ollila%40iki.fi

You'll need to build notmuch from source after applying the patch. "make
debian-snapshot" will produce installable packages.


I patched my notmuch-mutt script directly, and it seems to fix the 
problem for me.  Thank you very much Tomi and David!


-Kevin

Bug#870635: mutt package is not using the official mutt tarball

[Kevin J. McCarthy]

On Mon, Nov 20, 2017 at 06:59:16PM +, Jonathan Dowland wrote:
> On Mon, Nov 20, 2017 at 10:35:52AM -0800, Kevin J. McCarthy wrote:
> > Yes, I can understand the desire to sweep the whole mess under the rug.
> 
> That's not what I am proposing at all. I'm suggesting we put our users
> first, and on balance, I think switching neomutt users to mutt would not
> be the best outcome.

And how dare I be hostile, since your opinion seems to be without any
knowledge of what has happened, or of the work that has taken place in
Mutt the last few years under my development.

Incidentally, my comment was intended to be in reference to:

> (The wisdom of having moved the package *to* neomutt at this point is
> irrelevant, because it has happened whether we like it or not.)

> That would only address testing/unstable and future Debian releases, and
> not current stable, although I'm not sure yet what we can do about that
> within the confines of our normal rules and processes.

Yes, I'm aware of the situation of stable.  Antonio has clearly kept me
informed that stable is not possible to remedy.

> It would also be unethical to upload software that we had no intention
> of ever actually supporting properly.

Oh, now Debian is concerned about what is ethical?  If no one cares
about the mutt package, then let it die.  Or let another developer pick
up the package.  But allow that possibility now, not in 3 years after
another release cycle using a transition package.

> Finally it would switch all existing users from one software to another
> unexpectedly: just because we did that once doesn't mean we should do it
> again.

I believe this is an example of false equivalence.  Is unexpectedly
switching *mutt* package users to NeoMutt the same as switching them
back to Mutt?

This is also part of the "sweep the whole mess under the rug" argument
you are perpetuating: "Oh well, we did it.  Can't do anything about it,
can't go back... gosh there's just nothing to do but turn mutt into a
transition package."

> > Since Debian has basically taken away all my work
> 
> No we haven't. Please try harder to engage with us in a constructive and
> less hostile manner, and stop assuming bad faith. We are only having
> this conversation at all for your sake.

Spare me.  We are having this conversation because Debian is violating
my copyright, and I filed an RC bug.  Debian behaved unethically,
reprehensibly, and with extreme disrespect towards me and the Mutt
project.

And, yes, Debian _has_ taken away all my work since 1.6.x, when they
started applying massive patches from the NeoMutt project to my
releases.  I already laid out my viewpoint in this thread:
https://marc.info/?l=mutt-users=149880626013418=2

This occurred *after* I particularly tried to engage with the Debian
maintainers, triage, and start fixing bugs out of their ticket system.
If you really care, have a talk with them - I emailed them about this
just after that release.  A lot of good that did.

> You've come as close as you've managed at pitching to us we actually
> package mutt here.

> Given that, I'm surprised you've been so hostile. Do you expect to bully
> us into doing what you want? Please do bear in mind that another
> important consideration for packaging something is a healthy
> relationship with upstream.

Please stop speaking as if you are one of the mutt package maintainers.
I don't need to make a pitch to you, and I don't give a toot about a
"healthy relationship" at this point.

The mutt package maintainers made their choice, and ruined the
relationship all on their own.  They had many opportunities to fix it
over the past few releases, but instead doubled and tripled-down,
culminating in the complete tarball swapout.

That needs to be fixed.  I would prefer it not be in a way that removes
Mutt from Debian, but at this point I'm not going to make pitches or
temper my well-justified hostility.

-Kevin


signature.asc
Description: PGP signature

Bug#870635: mutt package is not using the official mutt tarball

[Kevin J. McCarthy]

On Fri, Nov 17, 2017 at 04:46:21PM +, Jonathan Dowland wrote:
> I think there are a facts you should seriously consider before
> continuing with this approach.
> 
> Firstly, the existing package is neomutt, but called mutt. So the
> existing package users are neomutt users, and the existing reported
> bugs are bugs in neomutt.  (The wisdom of having moved the package
> *to* neomutt at this point is irrelevant, because it has happened
> whether we like it or not.)

Yes, I can understand the desire to sweep the whole mess under the rug.

I have an alternative proposal.  How about if Mutt 1.9.1, with just the
basic changes required by Debian, is uploaded as the next mutt package.
Then the team can orphan the package.

Since Debian has basically taken away all my work, and given NeoMutt the
privilege of using the mutt package to establish itself in Debian and
all its derivatives, how about you let mutt package users actually *use*
my work for once before you move on.  Establish neomutt as a separate
package, and let the users who really care install that for themselves.

> If you are suggesting that the package name "mutt" is going to be real
> "mutt" in future, then what happens to existing users?

Horrors!  They might accidentally use an actual Mutt release!  They
might discover that 1.9.1 is actually pretty good, and that a fair chunk
of the improvements they thought came from NeoMutt might have come from
Mutt instead!

> What are their expectations?

I believe mutt package users should expect to use Mutt.  Please take a
look at http://www.mutt.org/news.html and
http://www.mutt.org/doc/UPDATING.  We've been releasing regularly for a
while now.

> Would users who are using neomutt features not find the change to be a
> regression from their point of view?

They can switch to the neomutt package then.

-Kevin

Bug#840850: mutt: Mutt can't find S/MIME key to sign messages

[Kevin J. McCarthy]

Debian changed the default to use GPGME for GPG and S/MIME encryption.

Please try putting "unset crypt_use_gpgme" in your .muttrc and restart
mutt.  (You must restart mutt for this option to have any effect).

-Kevin

Bug#434235: mutt -H ignores Content-Type:

[Kevin J. McCarthy]

FYI.  This is fixed upstream in https://dev.mutt.org/hg/mutt/rev/a4d885bb36ab

Bug#743744: mutt: S/MIME: mismatching documentation and supported algorithms for encryption (smime_encrypt_with)

[Kevin J. McCarthy]

FYI.  This was fixed upstream in https://dev.mutt.org/hg/mutt/rev/1235dd48ef3f

Bug#800780: mutt: folder-hook: current mailbox shortcut '^' is unset

[Kevin J. McCarthy]

The warning for this is new in 1.5.24, but the behavior has been the
same for 9 years.  A leading '^' in a folder-hook or mbox-hook expands
to "current mailbox", not "beginning of line".

See https://dev.mutt.org/doc/manual.html#mailbox-hook
and https://dev.mutt.org/trac/ticket/3788

If you need beginning on line, the best way is to use parenthesis:
  folder-hook (^buildd$) source .muttrc.buildd

Bug#741147: mutt: Mutt generated smime signatures fail verification in icedove/thunderbird

[Kevin J. McCarthy]

This was fixed upstream in https://dev.mutt.org/hg/mutt/rev/428a92464d5b

Note that fix requires $smime_sign_digest_alg to have a "-md %d" added
to it, so the header matches the actual digest used.

The digest algorithm can be set with $smime_sign_digest_alg.
See contrib/smime.rc.

Bug#677687: Mutt crashes while managing attachments

[Kevin J. McCarthy]

Just an FYI that this was fixed upstream in
https://dev.mutt.org/hg/mutt/rev/f99561e22a99.

-Kevin

Bug#814949: notification-daemon: /etc/xdg/autostart file only starts for "GNOME-Flashback"

[Kevin J. McCarthy]

On Thu, Feb 18, 2016 at 08:24:23PM +0200, Alberts Muktupāvels wrote:
> If you want you can add autostart file for notification-daemon in your home
> dir:
> ~/.config/autostart

> There is nothing specific to GNOME in notification-daemon so you can use it
> generic solution if you want.

Thank you, those two tips are very helpful.

-Kevin

Bug#814949: notification-daemon: /etc/xdg/autostart file only starts for "GNOME-Flashback"

[Kevin J. McCarthy]

On Thu, Feb 18, 2016 at 12:07:58PM +0200, Alberts Muktupāvels wrote:
> Openbox is window manager, why should it start something?

Openbox runs the XDG autostart programs because it is helpful.  This way
when I install, say, parcimonie or hplip-gui or notification-daemon, all
those packages need to do is create an /etc/xdg/autostart file, and they
are launched for my X session.

> On Wed, Feb 17, 2016 at 12:26 AM, Kevin McCarthy  wrote:
> > It seems like the notifications would be useful for all desktop
> > environments.  Would it be unreasonable to remove the "OnlyShowIn"
> > line from the autostart file, or would this cause problems in some
> > desktops?
> 
> GNOME does not use notification-daemon so starting it in all desktop
> environments is not solution. Also I plan to stop using notification-daemon
> for GNOME-Flashback, so autostart file will be removed.

I see.  I wasn't aware that notification-daemon was a Gnome project
package.  Perhaps it should have been named gnome-notification-daemon to
make this clearer?  Will the package be removed now that GNOME-Flashback
isn't using it either?

In any case, I will install another implementation, such as dunst.

Please feel free to close this bug out.

> If your desktop environment uses notification-daemon then it must install
> autostart file for it.

Just to correct this misunderstanding, my "desktop environment" isn't
using notification-daemon.  Debian packages that I have installed,
e.g. profanity, depend on libnotify4, which in turn recommends
notification-daemon.  However, I mistakenly installed the actual
"notification-daemon" package, thinking it was a generic solution.

-Kevin

Bug#658324: mutt: smime_keys.pl fails on filenames with spaces

[Kevin J. McCarthy]

Just a note that this is fixed upstream.  There were a series of patches
cleaning up up smime_keys.  I think the relevant one for this bug was
http://dev.mutt.org/hg/mutt/rev/577987ca2d02
but it probably won't apply outside of the series of commits.

-Kevin

Bug#797923: mutt: Updated Danish translation

[Kevin J. McCarthy]

Morton,

I've just added your translations upstream.  Please feel free to join
the Mutt Translators mailing list, mutt...@mutt.org, (see also
http://www.mutt.org/mail-lists.html).

You can post your updated translations to that list anytime and we will
commit them directly upstream.  I just happened to see the bug here by
chance, but don't peruse the Debian bug tracker that often.

-Kevin

Bug#128945: Sending mail encrypted with additional keys

[Kevin J. McCarthy]

Just a note that the multiple crypt hook patch was slightly modified and
committed upstream at http://dev.mutt.org/hg/mutt/rev/b4c57d3fd7e8

Also, a $crypt_confirmhook option was added to turn off the confirmation
prompt at http://dev.mutt.org/hg/mutt/rev/067a3ac42c3b

-Kevin

Bug#775199: smime_keys: insecure use of /tmp

[Kevin J. McCarthy]

Thank you for the suggestion to use File::Temp.

This should be fixed upstream in
http://dev.mutt.org/hg/mutt/rev/babc30377614

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763522: mutt: SEGV when choosing pgp keyID from list (mutt/mutt-patched)

[Kevin J. McCarthy]

I'm not a good judge of what is an RC bug, but this patch would be
*really* nice to have in Jessie+1.  It's a very low risk patch and stops
an easy to hit segfault.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751476: mutt: 1.5.22 major performance regression with color regexp matching

[Kevin J. McCarthy]

This may be fixed by http://dev.mutt.org/hg/mutt/rev/755a18da99bc just
committed upstream.  ~b has a pretty big performance regression fixed by
that changeset.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#742627: mutt-patched: full text search (l + ~b text) is extremely slow

[Kevin J. McCarthy]

This may be fixed by http://dev.mutt.org/hg/mutt/rev/755a18da99bc
just committed upstream.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780730: mutt: Does not work correctly with newer gpg-agent

[Kevin J. McCarthy]

Also note that http://dev.mutt.org/hg/mutt/rev/df55f14f4585 committed
upstream removes the agent check.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#439308: should be able to delete certain attachments in crypted mail

[Kevin J. McCarthy]

http://dev.mutt.org/hg/mutt/rev/bd21cff208c4 was just committed
upstream, and allows attachments to be deleted from unencrypted emails.

It displays a warning message if the email is signed or part-signed, but
doesn't prevent the deletion anymore.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728377: Cannot supply additional addresses with -H

[Kevin J. McCarthy]

Note that http://dev.mutt.org/hg/mutt/rev/4909bd9c9149 committed
upstream fixes this.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755538: mutt: Add gpgme support to vk.pgp_verbose_mime.patch

[Kevin J. McCarthy]

Also just a note that http://dev.mutt.org/hg/mutt/rev/789501922727 was
committed upstream.  It didn't include the options and the description,
but does work for both classic and gpgme.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753437: FTBFS with clang instead of gcc

[Kevin J. McCarthy]

The log file is actually at
http://clang.debian.net/logs/2014-06-16/mutt_1.5.23-1_unstable_clang.log

It looks like this is caused by the compressed-folders.patch added
by Debian, and can be fixed by simply adding declarations for
restore_path() and remove_file() to the top of compress.c.  (Or they can
just be moved further up in the file.)

Since they aren't declared in compress.h, it would probably also be good
to mark them both as static.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774666: Mutt segfaults when no encryption key exists

[Kevin J. McCarthy]

This looks like a duplicate of #763522 and #772782, and like those two
is probably fixed by http://dev.mutt.org/hg/mutt/rev/5a86319adad0

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763522: mutt segfault when selecting pgp key goes away with noopt

[Kevin J. McCarthy]

This was probably fixed by http://dev.mutt.org/hg/mutt/rev/5a86319adad0.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#772782: mutt: segfault in pgp_getkeybystr at pgpkey.c:997

[Kevin J. McCarthy]

This looks like a duplicate of #763522, and is probably also fixed by
http://dev.mutt.org/hg/mutt/rev/5a86319adad0

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759013: mutt: Incorrect fix in fix-configure-test-operator.patch

[Kevin J. McCarthy]

Just a note that this patch has been committed upstream at 80186ee6eb57.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757119: mutt: Documentation claims %a is possible in the pgp_encrypt_only_command but it's not

[Kevin J. McCarthy]

This is committed upstream at daf61444d454.

-Kevin


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673924: [Pkg-openssl-devel] Bug#673924: openssl: 0.9.8o-4squeeze13 update broke exim4 TLS connection to FastMail

[Kevin J. McCarthy]

Kurt Roeckx wrote:
 Exim is using gnutls, not openssl ...

Hmmm... I don't see any updates to gnutls for a couple months.  That
probably means FastMail did something then.  Thank you for your help!
Please close this bug out.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673924: openssl: 0.9.8o-4squeeze13 update broke exim4 TLS connection to FastMail

[Kevin J. McCarthy]

Package: openssl
Version: 0.9.8o-4squeeze13
Severity: normal


My exim4 server is configured to relay messages to FastMail as a
smarthost (using mail.messagingengine.com::587).

The day the openssl security update 0.9.8o-4squeeze13 was installed,
exim4 started failing to relay, logging:
  TLS error on connection to mail.messagingengine.com [66.111.4.52]
  (gnutls_handshake): The Diffie-Hellman prime sent by the server is not
  acceptable (not long enough).

It seems like some sort of default minimum acceptable key size must have
changed, or else FastMail changed something at the same time.  I can't
find any setting in exim4 to change this.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssl depends on:
ii  libc6  2.11.3-3  Embedded GNU C Library: Shared lib
ii  libssl0.9.80.9.8o-4squeeze13 SSL shared libraries
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates20090814+nmu3squeeze1 Common CA certificates

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org