Bug#1067115: gross: diff for NMU version 1.0.2-4.1

[Antonio Radici]

On Sat, Mar 23, 2024 at 11:45:58PM +0200, Adrian Bunk wrote:
> Control: tags 1067115 + patch
> Control: tags 1067115 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for gross (versioned as 1.0.2-4.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> 

Thanks for working on this, no reason to cancel it.

Sorry I couldn't get to this faster enough

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 09:59:53PM +0200, Sebastian Andrzej Siewior wrote:
> Hi Antonio!
> 
> On 2023-09-10 15:57:58 [+0200], Antonio Radici wrote:
> > On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> > > Hi Antonio,
> > > 
> > > FWIW, I have done the bookworm-security upload already to
> > > security-master, and still working on the bullseye-security one (with
> > > plan to release the DSA tonight ideally).
> > 
> > Ack, thanks for the update, I assume this was a particularly serious issue 
> > that
> > had to be handled immediately!
> 
> I pinged Salvatore on IRC about this and he was working on
> stable/old-stable fix of the version at the time. So I suggest to help
> out and prepare latest upstream from upstream for unstable (which was in
> opinion only fixes).
> Unfortunately I saw your reply to the bug after performing the update.
> I'm sorry if I overstepped here. In the meantime I prepared a pull on
> salsa for the changes I made.
> As a matter of fact, I noticed that I somehow missed the latest
> changelog from the package which I noticed while I tried to open the
> pull request. After looking at it again, it looks like I just missed the
> changelog entry.
> 
> Once again, I'm sorry for any trouble I may have caused.

Hi Sebastian,
not a problem at all! It's just that I was unaware! You were much faster than
me and that's definitely very good. Thanks a lot for your contribution to
Debian, I really appreciate it :)

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:47:30PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote:
> > On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > > Thanks for raising this, I'm uploading the new packages with the fixes 
> > > today.
> > 
> > apparently someone else did a NMU with the new version and incorrectly 
> > closed
> > the bug.
> 
> You mean the NMU by Sebastian?

Yes

> 
> > I reopened the bug because stable needs to be addressed (which I will do 
> > today
> > as I just wrote) and then it's probably worth investigating how to integrate
> > those NMU into the git repo
> 
> Actually you do not need to reopen. A bug can be closed with mutliple
> versions, that is 2.2.12-0.1 closes it, but as well so does then the
> 2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one.
> 
> I think that was not the case several years ago, but nowdays BTS can
> handle that, and will reflect it nicely as well in the version graph.
> 
> Or were you meaning something different?

Ah ok good, then I will add the extra versions if they are not there already

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> FWIW, I have done the bookworm-security upload already to
> security-master, and still working on the bullseye-security one (with
> plan to release the DSA tonight ideally).

Ack, thanks for the update, I assume this was a particularly serious issue that
had to be handled immediately!

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> Thanks for raising this, I'm uploading the new packages with the fixes today.

apparently someone else did a NMU with the new version and incorrectly closed
the bug.

I reopened the bug because stable needs to be addressed (which I will do today
as I just wrote) and then it's probably worth investigating how to integrate
those NMU into the git repo

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sat, Sep 09, 2023 at 10:23:32PM +0200, Salvatore Bonaccorso wrote:
> Source: mutt
> Version: 2.2.9-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerabilities were published for mutt.
> 
> CVE-2023-4874[0]:
> | Null pointer dereference when viewing a specially crafted email in
> | Mutt >1.5.2 <2.2.12
> 
> 
> CVE-2023-4875[1]:
> | Null pointer dereference when composing from a specially crafted
> | draft message in Mutt >1.5.2 <2.2.12
> 
> Make sure to include all three commits referenced from [2], the last
> one is technically not part of the two CVEs, but another crash found
> by upstream.
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2023-4874
> https://www.cve.org/CVERecord?id=CVE-2023-4874
> [1] https://security-tracker.debian.org/tracker/CVE-2023-4875
> https://www.cve.org/CVERecord?id=CVE-2023-4875
> [2] 
> http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/56.html
> 
> Please adjust the affected versions in the BTS as needed.

Thanks for raising this, I'm uploading the new packages with the fixes today.

Bug#1038270: Help offer to co-maintain neomutt as part of Mutt maintainers team

[Antonio Radici]

On Sun, Aug 13, 2023 at 10:31:45AM -0300, Carlos Henrique Lima Melara wrote:
> Hi, Pino.
> 
> I'm sending this email to you (cc #1038270 and samueloph) because I
> would like to help maintaining neomutt. I use it everyday and I've
> interacted with the upstream a couple times - he's a very nice person.
> 
> I saw you did commit to neomutt repo and you're in the mutt maintainers
> salsa group, that's why I'm reaching out to you. I also do have a
> sponsor (samueloph) that volunteered to help me with the uploads of
> neomutt in case you are not able to do it.
> 
> So, do you think you can give us (@samueloph and I - @charles) access to
> do the salsa mutt maintainers group? (you are one of the owners of the
> groups)

Hi Charles,
at the moment I'm not looking for co-maintainers of neomutt, otherwise I would
have followed the standard wnpp process (i.e.: filing a RFH).

Obviously this does not prevent you from going through the bugs and trying to
solve / patch whatever is fixable, I've always accepted patches and merge
proposals on salsa, especially if they solved some bugs rather than introducing
some features. Generally we try to upstread everything whenever possible,
flatcap@ has been very helpful in incorporating our patches.

I'm happy to chat on IRC if there are any additional questions!

Bug#1024427: reproducible segfault in bullseye mutt

[Antonio Radici]

On Sun, Dec 11, 2022 at 10:17:19PM +0100, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Sun, Dec 11, 2022 at 09:59:18PM +0100, Antonio Radici wrote:
> > On Thu, Dec 01, 2022 at 10:05:14PM +0100, Salvatore Bonaccorso wrote:
> > > Hi Antonio,
> > > 
> > > On Wed, Nov 30, 2022 at 09:38:39AM -0800, Kevin J. McCarthy wrote:
> > > > 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
> > > 
> > > There is an upcoming point release for bullseye on 17th of december,
> > > can you pick those fixes for a stable update?
> > > 
> > > Thanks for your work on mutt!
> > 
> > Yes, I will have an updated package tomorrow evening (Mon Dec 12th)
> 
> note that the time did pass this weekend for having fixes included in
> the next bullseye-point release. I went ahead earlier with #1025716
> which got accepted the stable release managers.
> 
> Hope this NMU was fine with you to get the fixes in time into the next
> bullseye point release.

Sure that's no problem, I realized that just after my email was sent :)

Bug#1024427: reproducible segfault in bullseye mutt

[Antonio Radici]

On Thu, Dec 01, 2022 at 10:05:14PM +0100, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Wed, Nov 30, 2022 at 09:38:39AM -0800, Kevin J. McCarthy wrote:
> > 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
> 
> There is an upcoming point release for bullseye on 17th of december,
> can you pick those fixes for a stable update?
> 
> Thanks for your work on mutt!

Yes, I will have an updated package tomorrow evening (Mon Dec 12th)

Bug#1020414: The patch have been merged upstream

[Antonio Radici]

On Wed, Oct 05, 2022 at 08:16:30PM +0200, Vincent-Xavier JUMEL wrote:
> https://github.com/neomutt/neomutt/pull/3524 closes
> https://github.com/neomutt/neomutt/issues/3514
> so neomutt could be updated with the latest master to reenable back sasl
> support via GNU SASL

Thanks for the update, I'll prepare a package soon

Bug#1011336: neomutt: New upstream version available

[Antonio Radici]

On Fri, May 20, 2022 at 11:46:09AM +0200, Michael Prokop wrote:
> Package: neomutt
> Version: 20211029+dfsg1-1
> Severity: wishlist
> 
> Hi,
> 
> NeoMutt versions 2022-04-08, 2022-04-15 + 2022-04-29 got released
> since the latest upload on 2021-12-11, would be nice to have a
> recent version in Debian. :)

Thanks for submitting this bug, I will update it tomorrow.

Bug#1008779: 1.37-1 has been uploaded to DELAYED/7

[Antonio Radici]

On Fri, Apr 22, 2022 at 09:18:23AM +0200, Jordi Mallach wrote:
> Hi,
> 
> This is to state that after 21 days, I've uploaded postgrey to
> DELAYED/7, as documented in the salvaging procedure.

Hi Jordi,
thanks for that. I was wondering if you are interested in taking it over?
Otherwise I will likely orphan the package because I'm not using postgrey
anymore.

Thanks for your upload!

Bug#771451: Processed: mutt: formatting problem in address list if line contains utf-8 character with accent (query mode)

[Antonio Radici]

Control: tag -1 -moreinfo
Control: tag -1 +unreproducible

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Antonio Radici]

On Wed, Dec 01, 2021 at 02:36:18PM +0100, Bastian Germann wrote:
> On Sun, 28 Nov 2021 07:45:57 +0100 Antonio Radici  wrote:
> > I had zero time to work on cfengine3 and I'm going to orphan it, I see that
> > there was an ITA but no upload, now Bastian has taken over the ITA, is there
> > any plan here?
> 
> The ITA owner is still Fabio. I just corrected the title that was missing 
> some words.
> When there is already an ITA you should not orphan the package as it is 
> Fabio's responsibility now.
> 
> Fabio, if you do not have the time to fulfill your ITA, please reset the 
> status to orphaned instead of RFA.
> 

Thanks for the clarification, actually I didn't notice that.

OK so let's see if this ITA goes forward otherwise the next step is to orphan 
the package

Bug#979020: Please replace mime-support with media-types and mailcap in Recommends.

[Antonio Radici]

Control: tags 979020 +pending

On Sun, Aug 29, 2021 at 02:30:33PM +0900, Charles Plessy wrote:
> Le Sat, Jan 02, 2021 at 10:13:09AM +0900, Charles Plessy a écrit :
> > 
> > Recently I have split the `mime-support` package into two: `media-types`
> > supplies /etc/mime.types and `mailcap` supplies the mailcap system.
> > `mime-support` remains as a transitional package for the moment.
> > 
> > I believe that `mutt` and `neomutt` recommend `mime-support` for both
> > functionalities.
> > 
> > At your convenience, can you replace mime-support with media-types and
> > mailcap in mutt and neomutt's Recommends ?
> 
> Hello,
> 
> now that Bullseye is released, it would be great if mutt and neomutt
> could recommend media-types and mailcap directly, so that I can remove
> mime-support.

This is done in the git repository now (thanks to your patch) and it will be
live once 2.1.3-2 is released.

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Antonio Radici]

Hello folks,
what's the status on this bug?

I had zero time to work on cfengine3 and I'm going to orphan it, I see that
there was an ITA but no upload, now Bastian has taken over the ITA, is there
any plan here?

Thanks!

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

[Antonio Radici]

On Tue, Nov 23, 2021 at 12:36:07PM -0800, Kevin J. McCarthy wrote:
> 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

Updating to mutt 2.1.3 as we speak, I will prepare the fix for the
stable/oldstable as well, that will go through the standard process; thanks for
referencing those commits.

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

[Antonio Radici]

On Wed, Aug 25, 2021 at 10:20:17AM +0200, Vincent Lefevre wrote:
> Package: mutt
> Version: 2.0.5-4.1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Mutt 2.1.2 is available. From the announce: "This is an important
> bug-fix release, fixing a potential data-loss IMAP bug. IMAP users
> are strongly advised to upgrade."
> 
> For stable and oldstable: "Packagers, please consider backporting
> commit 647efbd1 if at all possible."
> 
> See
> http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20210823/40.html
> for additional information.
> 
> Note also that there is a minor "mutt -v" output issue with the
> current Mutt and, in particular, GNU Autoconf 2.71, which is now
> in unstable. I fixed this issue in Mutt's repository yesterday
> and I'm going to report a second bug for that.

I'm going to have this fixed in the next few days (by Sep 1st)

Bug#986732: unblock: mutt/2.0.5-4

[Antonio Radici]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mutt

[ Reason ]
2.0.5-4 includes a patch to fix a slowness in opening messages due to coloring
which can amount to up to tens of seconds (see bugs.debian.org/985152).

[ Impact ]
Same as above.

[ Tests ]
No tests affected.

[ Risks ]
The change itself is trivial (see patch), and it has been already included in
the most recent version of mutt released.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

unblock mutt/2.0.5-4
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2021-02-16 21:34:09.0 +0100
+++ mutt-2.0.5/debian/changelog 2021-03-20 17:26:12.0 +0100
@@ -1,3 +1,11 @@
+mutt (2.0.5-4) unstable; urgency=medium
+
+  * debian/patches:
++ upstream/985152-body-color-slowness.patch: fixes slowness (up to tens of
+  seconds) if body coloring is present (Closes: 985152).
+
+ -- Antonio Radici   Sat, 20 Mar 2021 17:26:12 +0100
+
 mutt (2.0.5-3) unstable; urgency=medium
 
   * debian/patches:
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2021-02-16 21:32:50.0 +0100
+++ mutt-2.0.5/debian/patches/series2021-03-20 17:24:06.0 +0100
@@ -12,3 +12,4 @@
 misc/smime.rc.patch
 upstream/528233-readonly-open.patch
 upstream/980924-updated-german-translation.patch
+upstream/985152-body-color-slowness.patch
diff -Nru mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch
--- mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
1970-01-01 01:00:00.0 +0100
+++ mutt-2.0.5/debian/patches/upstream/985152-body-color-slowness.patch 
2021-03-20 17:25:35.0 +0100
@@ -0,0 +1,163 @@
+From 53ffdb93b8a96efb7456f9430cf46a66ca7b9860 Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Wed, 10 Mar 2021 15:09:49 -0800
+Subject: [PATCH] Improve body color matching speed by caching future matches.
+
+On a *very* long body (or header_partial) lines with multiple color
+lines that match, performance can be degraded.  For instance if there
+were moderately expensive regexp matches against "A" "B" and "C".  A
+line with:
+
+  A A A A A B A A C A A A B A A A C
+
+The B and C regexps were scanned again after every "A" match, despite
+that the result would be discarded again for the next A match.
+
+Change the color matching to cache the location of each color line
+match.  Discard the cache once the match offset passes that point.
+---
+ mutt_curses.h |  5 
+ pager.c   | 64 ---
+ 2 files changed, 55 insertions(+), 14 deletions(-)
+
+--- a/mutt_curses.h
 b/mutt_curses.h
+@@ -154,9 +154,14 @@
+   int pair;
+   struct color_line *next;
+ 
++  regoff_t cached_rm_so;
++  regoff_t cached_rm_eo;
++
+   unsigned int stop_matching : 1; /* used by the pager for body patterns,
+  to prevent the color from being retried
+  once it fails. */
++  unsigned int cached : 1; /* indicates cached_rm_so and cached_rm_eo
++* hold the last match location */
+ } COLOR_LINE;
+ 
+ #define MUTT_PROGRESS_SIZE  (1<<0)  /* traffic-based progress */
+--- a/pager.c
 b/pager.c
+@@ -773,7 +773,7 @@
+ {
+   COLOR_LINE *color_line, *color_list;
+   regmatch_t pmatch[1];
+-  int found, offset, null_rx, i;
++  int i;
+ 
+   if (n == 0 || ISHEADER (lineInfo[n-1].type) ||
+   (check_protected_header_marker (raw) == 0))
+@@ -879,6 +879,8 @@
+   (lineInfo[n].type == MT_COLOR_HDEFAULT && option 
(OPTHEADERCOLORPARTIAL)))
+   {
+ size_t nl;
++int has_nl = 0, found, offset, null_rx, has_reg_match;
++regoff_t rm_so, rm_eo;
+ 
+ /* don't consider line endings part of the buffer
+  * for regex matching */
+@@ -896,8 +898,10 @@
+ while (color_line)
+ {
+   color_line->stop_matching = 0;
++  color_line->cached = 0;
+   color_line = color_line->next;
+ }
++
+ do
+ {
+   if (!buf[offset])
+@@ -908,11 +912,31 @@
+   color_line = color_list;
+   while (color_line)
+   {
+-  if (!color_line->stop_matching &&
+-regexec (&color_line->rx, buf + offset, 1, pmatch,
+-   (offset ? REG_NOTBOL : 0)) == 0)
++has_reg_match = 0;
++  if (!color_line->stop_matching)
++{
++  if (color_line->cached)
++  {
++has_reg_match = 1;
++rm_so = color_line->cached_rm_so;
++rm_eo = color_line->cached_rm_eo;
++ 

Bug#980924: Acknowledgement (mutt: Please include updated German translation)

[Antonio Radici]

On Sat, Feb 13, 2021 at 09:47:34AM +0100, Helge Kreutzmann wrote:
> Hello Antonio,
> as announced the German mutt translation was heavily improved over the
> course of the last weeks[1]. Since the freeze is now approaching and due
> to "real life" for key people involved in the review, we did not
> manage to complete the review, however, the version is *much* improved
> already.
> 
> I provided this intermediate update to the upstream maintainers (cf. 
> mutt-po lists) and I would kindly ask to include it into your next
> upload targetting Bullseye.
> 
> On behalf of the German speaking mutt users I thank you for
> considering!
> 
> Please unzip the file and place it as "de.po" in the appropriate
> place. If you want, I can prepare the upload "ready to go" including
> requesting unblock to debian-release (I did an upload aeons ago
> already); however, as I'm only a DM, I cannot perform the upload
> itself.)
> 

Thanks fror the extra ping, I'll do it now

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

[Antonio Radici]

On Wed, Jan 20, 2021 at 10:31:54AM -0800, Kevin J. McCarthy wrote:
> 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.

Hi Kevin,
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!

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

[Antonio Radici]

On Tue, Jan 19, 2021 at 09:07:37AM +0100, Salvatore Bonaccorso wrote:
> Control: tags 980326 + patch
> Control: tags 980326 + pending
> 
> Hi Antonio,
> 
> I've prepared an NMU for mutt (versioned as 2.0.2-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer (or shorter).
> 
> Actually IMHO it would be more sensible to rebase to the current
> upstream version and cherry-pick the additional commits already queued
> for stable.
> 

Thanks for the patch, I will upgrade to the latest upstream version by Sunday
this week, I have no problem with the NMU!

Does it make sense? When you talk about "additional commits already queued for
stable" what are you referring to?

Bug#976308: RFA: cfengine3 -- tool for configuring and maintaining network machines

[Antonio Radici]

Package: wnpp
Severity: normal

I request an adopter for the cfengine3 package.

I haven't been using the package in a while and I don't believe I can be
effective maintaining it due to that.

The package description is:
 Cfengine is a suite of programs for integrated autonomic management
 of either individual or networked computers.
 .
 Cfengine 3 is both a more powerful and much simplified version of cfengine,
 which has been designed to inter operate with cfengine 2 rather than be
 backwards compatible with it.
 .
 With cfengine 3 you can install, configure and maintain computers using
 powerful hands-free tools.

Bug#975616: buster-pu: package neomutt/neomutt_20180716+dfsg.1-1+deb10u2

[Antonio Radici]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: j...@inutil.org, car...@debian.org

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
Same as bugs.debian.org/975514, except that one is for mutt, this one for
neomutt. The patch is the same and it addresses the same CVE (CVE-2020-28896).

Security team is aware, they suggested to go through the route of buster-updates
rather than DSA for this particular issue.

debdiff is attached, I've also done an upload already.

[ Impact ]
Prevent login information to be sent over an encrypted connection when certain
conditions happen.

[ Tests ]
(What automated or manual tests cover the affected code?)

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, alternatives available.)

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
See the "Reason" section.

[ Other info ]
(Anything else the release team should know.)

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru neomutt-20180716+dfsg.1/debian/changelog 
neomutt-20180716+dfsg.1/debian/changelog
--- neomutt-20180716+dfsg.1/debian/changelog2020-06-20 07:42:44.0 
+0200
+++ neomutt-20180716+dfsg.1/debian/changelog2020-11-24 07:55:28.0 
+0100
@@ -1,3 +1,11 @@
+neomutt (20180716+dfsg.1-1+deb10u2) buster; urgency=medium
+
+  * debian/patches:
++ security/CVE-2020-28896.patch: handle the relevant CVE to stop sending
+  login information over an encrypted connections in certain conditions.
+
+ -- Antonio Radici   Tue, 24 Nov 2020 07:55:28 +0100
+
 neomutt (20180716+dfsg.1-1+deb10u1) buster-security; urgency=high
 
   * debian/patches:
diff -Nru neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch 
neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
--- neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
1970-01-01 01:00:00.0 +0100
+++ neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
2020-11-24 07:55:28.0 +0100
@@ -0,0 +1,39 @@
+From 04b06aaa3e0cc0022b9b01dbca2863756ebbf59a Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Mon, 16 Nov 2020 10:20:21 -0800
+Subject: [PATCH] Ensure IMAP connection is closed after a connection error.
+
+During connection, if the server provided an illegal initial response,
+Mutt "bailed", but did not actually close the connection.  The calling
+code unfortunately relied on the connection status to decide to
+continue with authentication, instead of checking the "bail" return
+value.
+
+This could result in authentication credentials being sent over an
+unencrypted connection, without $ssl_force_tls being consulted.
+
+Fix this by strictly closing the connection on any invalid response
+during connection.  The fix is intentionally small, to ease
+backporting.  A better fix would include removing the 'err_close_conn'
+label, and perhaps adding return value checking in the caller (though
+this change obviates the need for that).
+
+This addresses CVE-2020-28896.  Thanks to Gabriel Salles-Loustau for
+reporting the problem, and providing test cases to reproduce.
+---
+ imap/imap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/imap/imap.c
 b/imap/imap.c
+@@ -1110,9 +1110,9 @@
+ 
+ #ifdef USE_SSL
+ err_close_conn:
+-  imap_close_connection(idata);
+ #endif
+ bail:
++  imap_close_connection(idata);
+   FREE(&idata->capstr);
+   return -1;
+ }
diff -Nru neomutt-20180716+dfsg.1/debian/patches/series 
neomutt-20180716+dfsg.1/debian/patches/series
--- neomutt-20180716+dfsg.1/debian/patches/series   2020-06-20 
07:42:44.0 +0200
+++ neomutt-20180716+dfsg.1/debian/patches/series   2020-11-24 
07:55:28.0 +0100
@@ -4,3 +4,4 @@
 misc/smime.rc.patch
 security/CVE-2020-14093.patch
 security/handle-starttls.patch
+security/CVE-2020-28896.patch

Bug#975514: buster-pu: package mutt/1.10.1-2.1+deb10u4

[Antonio Radici]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
This is a fix for CVE-2020-28896, discussed with two members of the security
team (Moritz Muehlenhoff and Salvatore Bonaccorso) whether to do a DSA, in the
end it was decided, given that this requires a malicious server, to add it to
the next point release, which is happening soon.

[ Impact ]
Same as the CVE, a malicious server could force the client to send the
credential over an unencrypted connection.

[ Tests ]
(What automated or manual tests cover the affected code?)

[ Risks ]
See impact.

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
A two line patch provided by the maintainer and checked by myself, already in
unstable.

[ Other info ]
Security team is aware, I've already done the upload to shorten your review
time.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mutt-1.10.1/debian/changelog mutt-1.10.1/debian/changelog
--- mutt-1.10.1/debian/changelog2020-07-02 16:45:23.0 +0200
+++ mutt-1.10.1/debian/changelog2020-11-23 09:26:09.0 +0100
@@ -1,3 +1,10 @@
+mutt (1.10.1-2.1+deb10u4) buster; urgency=medium
+
+  * debian/patches:
++ fix for CVE-2020-28896 located in security/CVE-2020-28896.patch.
+
+ -- Antonio Radici   Mon, 23 Nov 2020 09:26:09 +0100
+
 mutt (1.10.1-2.1+deb10u3) buster; urgency=medium
 
   * debian/patches:
diff -Nru mutt-1.10.1/debian/patches/security/CVE-2020-28896.patch 
mutt-1.10.1/debian/patches/security/CVE-2020-28896.patch
--- mutt-1.10.1/debian/patches/security/CVE-2020-28896.patch1970-01-01 
01:00:00.0 +0100
+++ mutt-1.10.1/debian/patches/security/CVE-2020-28896.patch2020-11-23 
09:26:09.0 +0100
@@ -0,0 +1,39 @@
+From 04b06aaa3e0cc0022b9b01dbca2863756ebbf59a Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Mon, 16 Nov 2020 10:20:21 -0800
+Subject: [PATCH] Ensure IMAP connection is closed after a connection error.
+
+During connection, if the server provided an illegal initial response,
+Mutt "bailed", but did not actually close the connection.  The calling
+code unfortunately relied on the connection status to decide to
+continue with authentication, instead of checking the "bail" return
+value.
+
+This could result in authentication credentials being sent over an
+unencrypted connection, without $ssl_force_tls being consulted.
+
+Fix this by strictly closing the connection on any invalid response
+during connection.  The fix is intentionally small, to ease
+backporting.  A better fix would include removing the 'err_close_conn'
+label, and perhaps adding return value checking in the caller (though
+this change obviates the need for that).
+
+This addresses CVE-2020-28896.  Thanks to Gabriel Salles-Loustau for
+reporting the problem, and providing test cases to reproduce.
+---
+ imap/imap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/imap/imap.c
 b/imap/imap.c
+@@ -524,9 +524,9 @@
+ 
+ #if defined(USE_SSL)
+  err_close_conn:
+-  imap_close_connection (idata);
+ #endif
+  bail:
++  imap_close_connection (idata);
+   FREE (&idata->capstr);
+   return -1;
+ }
diff -Nru mutt-1.10.1/debian/patches/series mutt-1.10.1/debian/patches/series
--- mutt-1.10.1/debian/patches/series   2020-07-02 16:44:08.0 +0200
+++ mutt-1.10.1/debian/patches/series   2020-11-23 09:24:54.0 +0100
@@ -16,4 +16,5 @@
 security/CVE-2020-14093.patch
 security/CVE-2020-14154.patch
 security/CVE-not-yet-released.patch
+security/CVE-2020-28896.patch
 upstream/imap-preauth-and-ssh-tunnel.patch

Bug#974601: neomutt: new upstream version (latest release is 20200925)

[Antonio Radici]

On Thu, Nov 12, 2020 at 12:07:01PM -0800, Benjamin Mako Hill wrote:
> Package: neomutt
> Version: 20200626+dfsg.1-1
> Severity: wishlist
> 
> Greetings!
> 
> Thank you for maintaining neomutt! There was a new release of neomutt in late
> September that I suppose should be uploaded into Debian. It's available here
> and fixes a number of bugs:
> 
> https://github.com/neomutt/neomutt/releases/tag/20200925
> 
> Some of the debian patches don't apply cleanly because the maintainers have
> moved some of the documentation out from mutt_config.c over to docs/config.c
> but the code itself seems to have been copied. I've made a working version of
> the package (downloadable with dget) which is online here:
> 
> https://mako.cc/outgoing/neomutt-20200925-1~mako/neomutt_20200925-1~mako.dsc
> https://mako.cc/outgoing/neomutt-20200925-1~mako/
> 
> I haven't done (or even looked into) the DFSG issues so I suppose those still
> need to happen. I figured I'd share my work since it might be useful to you or
> others. If it's not, feel free to ignore!
> 
> Regards,
> Mako

Thanks for your bug, I will look into packaging this version this weekend.

Bug#972893: cfengine3 FTCBFS: fails finding libxml2

[Antonio Radici]

Control: tag -1 +pending

Thanks for the patch, I've pushed it to git, it will be in the next upload.

Bug#963341: cfengine3: New cfengine 3.15.2 package is broken and non-functional

[Antonio Radici]

On Fri, Sep 11, 2020 at 09:54:19AM +0200, Gian Piero Carrubba wrote:
> Package: cfengine3
> Followup-For: Bug #963341
> 
> Hi,
> 
> just a friendly ping that
> https://salsa.debian.org/cfengine-team/cfengine3/-/merge_requests/2
> fixes this (admittely also includes not strictly needed changes, tho).
> 
> Ciao,
> Gian Piero.

Thanks for the ping, these are merged now.
I will prepare a release.

Bug#698267: fixed in mutt 1.14.5-1

[Antonio Radici]

On Wed, Jul 01, 2020 at 05:50:39PM +0900, Benjamin Poirier wrote:
> This triggered a regression, I would say.
> 
> When composing a new message, the realname configuration item is not
> taken into account to create the "From" address. For example, in my
> case, it appears as "From: benjamin.poir...@gmail.com". This is a
> regression from package version 1.14.4-2 where it would appear as "From:
> Benjamin Poirier ".

Yes, I will fix it with an update between today and tomorrow.

Bug#964146: buster-pu: package mutt/1.10.1-2.1+deb10u3

[Antonio Radici]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hello folks,
in mutt/1.10.1-2.1+deb10u2 a security CVE was fixed yet it introduced a
regression (bugs.debian.org/963970); I discussed with the security team whether
to push another DSA to fix the regression, but given the scope it was decided
that the best place for that is the next point release.

I've attached the debdiff to this mail and done the upload for buster.

Let me know if there is anything else that I should do.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), 
LANGUAGE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru mutt-1.10.1/debian/changelog mutt-1.10.1/debian/changelog
--- mutt-1.10.1/debian/changelog2020-06-19 06:55:35.0 +0200
+++ mutt-1.10.1/debian/changelog2020-07-02 16:45:23.0 +0200
@@ -1,3 +1,11 @@
+mutt (1.10.1-2.1+deb10u3) buster; urgency=medium
+
+  * debian/patches:
++ added imap-preauth-and-ssh-tunnel.patch from upstream, which does not
+  check IMAP preauth in SSH tunnels (Closes: 963970)
+
+ -- Antonio Radici   Thu, 02 Jul 2020 16:45:23 +0200
+
 mutt (1.10.1-2.1+deb10u2) buster-security; urgency=high
 
   * debian/patches:
diff -Nru mutt-1.10.1/debian/patches/series mutt-1.10.1/debian/patches/series
--- mutt-1.10.1/debian/patches/series   2020-06-19 06:55:20.0 +0200
+++ mutt-1.10.1/debian/patches/series   2020-07-02 16:44:08.0 +0200
@@ -16,3 +16,4 @@
 security/CVE-2020-14093.patch
 security/CVE-2020-14154.patch
 security/CVE-not-yet-released.patch
+upstream/imap-preauth-and-ssh-tunnel.patch
diff -Nru mutt-1.10.1/debian/patches/upstream/imap-preauth-and-ssh-tunnel.patch 
mutt-1.10.1/debian/patches/upstream/imap-preauth-and-ssh-tunnel.patch
--- mutt-1.10.1/debian/patches/upstream/imap-preauth-and-ssh-tunnel.patch   
1970-01-01 01:00:00.0 +0100
+++ mutt-1.10.1/debian/patches/upstream/imap-preauth-and-ssh-tunnel.patch   
2020-07-02 16:45:23.0 +0200
@@ -0,0 +1,25 @@
+From dc909119b3433a84290f0095c0f43a23b98b3748 Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Sat, 20 Jun 2020 06:35:35 -0700
+Subject: [PATCH] Don't check IMAP PREAUTH encryption if $tunnel is in use.
+
+$tunnel is used to create an external encrypted connection.  The
+default of $ssl_starttls is yes, meaning those kinds of connections
+will be broken by the CVE-2020-14093 fix.
+---
+ imap/imap.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/imap/imap.c
 b/imap/imap.c
+@@ -495,8 +495,8 @@
+   {
+ #if defined(USE_SSL)
+ /* An unencrypted PREAUTH response is most likely a MITM attack.
+- * Require a confirmation. */
+-if (!idata->conn->ssf)
++ * Require a confirmation unless using $tunnel. */
++if (!idata->conn->ssf && !Tunnel)
+ {
+   if (option(OPTSSLFORCETLS) ||
+   (query_quadoption (OPT_SSLSTARTTLS,

Bug#963970: mutt: DSA-4707-1 regression: setting tunnel option results in error "Encrypted connection unavailable"

[Antonio Radici]

On Mon, Jun 29, 2020 at 02:29:16PM +0200, Jarek Kamiński wrote:
> Package: mutt
> Version: 1.10.1-2.1+deb10u2
> Severity: normal
> 
> Hi,
> 
> I've mutt configured to exec Dovecot imap server directly with the
> following setting in /etc/Muttrc:
> #v+
> account-hook imap://[...] 'set tunnel="/usr/lib/dovecot/imap 2> 
> $TMP/mutt-dovecot.log"'
> #v-
> 
> It was working just fine until I've upgraded to 1.10.1-2.1+deb10u2, when
> it stopped working and shows an error "Encrypted connection unavailable"
> instead. Downgrading to 1.10.1-2.1 helps.
> 
> I've tried also on another host with the unstable version (1.14.4-2 and
> set tunnel="ssh [...] /usr/lib/dovecot/imap"), it works fine as well.
> 

Hi,
we are aware of this issue and we plan to get it fixed in the next stable point
release (within 2-3 weeks).

Bug#802613: mutt: Does not revert space-stuffing when saving format=flowed messages

[Antonio Radici]

Control: found -1 1.14.4-2
Control: tag -1 +confirmed +upstream
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/259

Still reproducible. Forwarded upstream.

Bug#192145: mutt: tag-prefix works only on the first command of a macro

[Antonio Radici]

Control: severity -1 wishlist

In reality this is working as intended, tag-prefix only applies ot the first
command, as per documentation.

I'll classify it as wishlist, but I might close it as wontfix if we don't get
traction upstream.

Bug#521405: decode-copy/save clobbers all headers when $weed=yes

[Antonio Radici]

Control: found -1 1.14.4-2
Control: tag -1 +upstream +confirmed
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/258

Forwarded upstream again.

Bug#509581: $sendmail option unconditionally and wrongly uses --

[Antonio Radici]

Control: tag -1 -pending
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/257
Control: tag -1 +upstream

Let's try again some years later, I've forwarded it upstream, ideally they will
include the patch rather than me.

Bug#160678: Please add $wrap variable

[Antonio Radici]

Control: tag -1 +upstream +confirmed
Control: found -1 1.14.4-2
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/256

Went to upstream, if he fixes it it will be the oldest Debian bug ever fixed :D

Bug#192145: mutt: tag-prefix works only on the first command of a macro

[Antonio Radici]

Control: tag -1 +confirmed +upstream
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/255
Control: found -1 1.14.4-2

Still there, forwarded upstream.

Bug#861572: [Pkg-mutt-maintainers] Bug#861572: mutt: Shows begin pgp signed message for inline message

[Antonio Radici]

Control: found -1 1.14.4-2
Control: tag -1 +upstream +confirmed
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/254

On Sun, Jun 21, 2020 at 01:44:11PM +0200, Kurt Roeckx wrote:
> Please try with an inlined signed message, not a mime signed
> message. I can still reproduce this with 1.14.4-2.

You are right, sorry. I forwarded the issue upstream.

Bug#433829: mutt: Reply/group reply functions choose wrong email when replying to myself with a reply to

[Antonio Radici]

Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/253
Control: tag -1 +confirmed +upstream
Control: found -1 1.14.4-2

Old bug but still exists, forwarded upstream.

Bug#800621: Runs tunnel program with stderr closed

[Antonio Radici]

Control: found -1 1.14.4-2
Control: tag -1 +upstream
Control: forwarded -1 https://gitlab.com/muttmua/mutt/-/issues/252

On Thu, Oct 01, 2015 at 11:34:34AM -0700, Josh Triplett wrote:
> Package: mutt
> Version: 1.5.24-1
> Severity: normal
> 
> Given a tunnel set with 'set tunnel=...', mutt appears to run that
> tunnel program with stderr closed.  This causes some programs, such as
> Dovecot's imap server, to abort with an error when they try to write to
> stderr.  mutt should run the tunnel with stderr pointing somewhere
> valid; ideally, mutt could capture and display errors if the tunnel
> fails, but even if mutt wants to discard errors, it should do so by
> pointing stderr to /dev/null rather than closing it.
> 

Still a problem even today...
Forwarded upstream

Bug#820053: mutt: %s in mailcap's "test=" field not expanded

[Antonio Radici]

Control: tag -1 +moreinfo

On Mon, Apr 04, 2016 at 06:07:49PM -0700, Bill Brelsford wrote:
> Package: mutt
> Version: 1.5.24-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> After displaying a text/plain attachment (via autoview) with a
> mailcap file containing
> 
>   text/plain; myprog %s; test=echo f=%s t=%t >/tmp/foo; copiousoutput
> 
> file /tmp/foo contains "f= t=text/plain" rather than the expected
> "f=/tmp/muttJuO9nd t=text/plain".  (And the filename is not passed
> to myprog.)

I'm trying to understand, in view of your last post if (1) is this still a bug?
(2) is this reproducible vs the latest version of mutt in sid (1.14.4-2)?

Bug#944750: neomutt: Build with autocrypt support

[Antonio Radici]

Control: tag -1 +pending

Added in git, will be uploaded with the next version.

Bug#946900: latest neomutt no longer uses account-hook for initial login [regression]

[Antonio Radici]

Control: tag -1 +moreinfo

Can you provide an example configuration that allow us to reproduce this bug
against the version that is currently on sid?

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

[Antonio Radici]

On Tue, Jun 23, 2020 at 03:03:06PM +, Joseph Nahmias wrote:
> Package: mutt
> Version: 1.10.1-2.1+deb10u2
> Followup-For: Bug #963107
> 
> Hello,
> 
> I can confirm that this bug bit me as well, and that the listed mitigation
> fixed the problem. Will the upstream fix be backported to Debian 
> stable/buster?
> 

Yeah that's something I'm thinking, I'm not sure though because the package is
still functional :(

Bug#963341: cfengine3: New cfengine 3.15.2 package is broken and non-functional

[Antonio Radici]

On Sun, Jun 21, 2020 at 02:23:52PM -0600, Michael Berg wrote:
> 
> First, thank you for packaging cfengine 3.15.2.
> 
> Unfortunately, the new cfengine 3.15.2 package in sid/unstable is
> broken and non-functional.

Thanks for the report, I'll look into it tomorrow.

Bug#532766: please make mutt not modify message on saving or copying (content-length, lines)

[Antonio Radici]

Control: tag -1 +moreinfo

On Thu, Jun 11, 2009 at 02:45:07PM +0200, Helmut Grohne wrote:
> Package: mutt
> Version: 1.5.19-4
> Severity: wishlist
> Tags: patch
> 
> When copying or moving/saving messages mutt adds Lines and
> Content-Length headers. This is necessary for certain mbox formats,
> because otherwise a line beginning with "From " in the message body is
> difficult to disambiguate from the next message. However these headers
> are not usefull for storages likes Maildir or imap. Even worse when
> moving a message without these headers between Maildir folders the
> contents change and therefore checksum-based synchronization tools have
> to retransmit the whole message without this being necessary. It would
> therefore be a good to not add these headers in the latter case.
> 
> Fortunately Emanuele Giaquinta has a short patch for this. All it does
> is disable adding these headers for Maildir and imap destinations. It
> can be found at http://tmp.tomaw.net/mutt-copy.diff.

It seems to me that the patch is no longer available, can you provide a new 
patch?

Thanks!

Bug#771451: mutt: formatting problem in address list if line contains utf-8 character with accent (query mode)

[Antonio Radici]

Control: tag -1 +moreinfo

Can you give me a way to reproduce this? Which query-command are you using?
maybe provide an example or reproducible muttrc?

Bug#932698: Please switch to libidn2

[Antonio Radici]

Control: tag -1 +pending

On Mon, Jul 22, 2019 at 01:15:51AM +0200, Laurent Bigonville wrote:
> Source: mutt
> Version: 1.10.1-2.1
> Severity: wishlist
> Tags: patch
> User: help-lib...@gnu.org
> Usertags: libidn2
> 
> Hi,
> 
> Currently mutt uses libidn but also supports libidn2.
> 
> libidn2 is already installed by default on a fresh debian system, would
> it be possible to switch to libidn2 instead of libidn?
> 
> Kind regards,
> 

Done in git, will appear in the next upload.

Bug#671910: view-attach fails to display MS word attachment

[Antonio Radici]

Control: tag -1 +moreinfo

On Mon, May 07, 2012 at 10:15:21PM -0500, Steve M. Robbins wrote:
> Package: mutt
> Version: 1.5.21-5+b1
> Severity: important
> 
> When viewing a message with attachments, 'v' to view attachment
> list allows me to select the attachment and '' typically
> views it.  This works, e.g. with html.  
> 
> It also used to work with MS Word attachments, but now it just
> emits the error:
> 
> sh: 1: /home/steve/.openoffice/1.0.1/soffice: not found

Is this still an issue for you in the most recent version of mutt?

Bug#895714: mutt: breaks attachments by converting to bogus encodings

[Antonio Radici]

Control: tag -1 +moreinfo

On Sun, Apr 15, 2018 at 04:40:22AM +0200, Adam Borowski wrote:
> Package: mutt
> Version: 1.7.2-1
> Severity: normal
> 
> Hi!
> I just tried to attach a patch to a mail.  The patch looks fine:
> 
> [/tmp]$ file ohw.debdiff 
> ohw.debdiff: unified diff output, UTF-8 Unicode text
> 
> And indeed, inside there's a name with 'ä' in it.  All ok, properly encoded,
> using a sane locale, LC_CTYPE is ok, etc.  However, mutt does:
> 
> - I 1 /tmp/mutt-tartarus-1000-26079-3022800448 
> [text/plain, 8bit, utf-8, 0.3K]
>   A 2 /tmp/ohw.debdiff
> [text/plain, 8bit, iso-8859-1, 5.1K]
> 

Can you attach a mbox file that contains the mail, assuming it is reproducible 
with 1.14.4-2?

Thanks!

Bug#930785: mutt: "file exists" error when saving attachment to CIFS share

[Antonio Radici]

Control: tag -1 +moreinfo

On Thu, Jun 20, 2019 at 04:24:29PM +0200, Lionel Elie Mamane wrote:
> Package: mutt
> Version: 1.7.2-1+deb9u1
> Severity: important
> 
> When saving an attachment from into a directory on a CIFS share
> (Windows 2012R2 server), mutt creates an empty file and then fails
> with the error message "file exists (errno=17)". Saving is successful
> if one tries again to same filename and then chooses "overwrite".

Hello,
can you check if this is still reproducible with the latest version of mutt on
sid (1.14.4-2)?

Thanks!

Bug#836343: mutt: macro interpretation is really fragile

[Antonio Radici]

Control: tag -1 +moreinfo

On Fri, Sep 02, 2016 at 09:49:22AM +0200, Samuel Hym wrote:
> Hi Antonio,
> 
> Yes, this was happening with mutt/1.6.?. I’ve run into those problems
> before mutt/1.7, with mutt packages from unstable. I didn’t try with
> older mutts, I wrote those macros only in August.
> 
> Best regards
>

Hi,
since many things changed in teh most recent version (including the fact that
we are not using neomutt anymore), are you still experiencing this issue in
1.14.4-2? 

Bug#851661: mutt: Jump to an unrelated mail when browsing a virtual mailbox

[Antonio Radici]

Control: tag -1 +moreinfo

On Tue, Jan 17, 2017 at 12:26:17PM +0100, Nicolas Évrard wrote:
> Package: mutt
> Version: 1.7.1-5
> Severity: normal
> 
> Dear Maintainer,
> 
> I have the following virtual mailbox defined:
> 
> virtual-mailboxes Inbox "notmuch://?query=tag:inbox"
> 
> This is the primary mailbox I use in order to sort emails.
> 
> When reading emails I usually navigate to the next unread message with the
>  keybinding. Unfortunately this does not work anymore because instead of
> going to the next unread email mutt will display an unrelated and older email.

Is this still an issue for you with 1.14.4-2?
I don't have notmuch so I can't test if it's reproducible.

Thanks!

Bug#793447: mutt: attached images not fed to graphical browsers

[Antonio Radici]

Control: severity -1 wishlist

On Fri, Jul 24, 2015 at 07:54:08AM +0200, Nomen Nescio wrote:
> Package: mutt
> Version: 1.5.23-3
> Severity: normal
> 
> Dear Maintainer,
> 
> MIME-compliant messages containing images that are referenced by an
> HTML attachment do not render with the images because mutt does not
> unpack them.
> 
> While it's understandable that mutt users do not generally care if
> html can be rendered graphically, there are those rare cases where
> it's useful.  In particular, producing printable/distributable
> non-forensic copies of e-mail for legal purposes, where the stationary
> used by an author is important.
> 
> This article gives some insight - indicating that if image files are
> mime-unpacked, mutt's usual choice for naming attachments won't always
> work:
> 
>   
> https://stackoverflow.com/questions/4018709/how-to-create-an-email-with-embedded-images-that-is-compatible-with-the-most-mai
> 
> the names should be formed as:
> 
>   cid:
> 
> a filename might look like this:
> 
>   image001.png@0D0B1FF0.79904F06
> 
> Note that images render correctly only if the html references an URL
> as opposed to a local file.

More wishlist than bug, still keeping it open.

Bug#823655: mutt-patched: IMAP folders displayed in the wrong location with sidebar

[Antonio Radici]

Control: reassign -1 mutt
Control: tag -1 +moreinfo

On Fri, May 06, 2016 at 10:28:51PM -0700, Carbonated Beverage wrote:
> Package: mutt-patched
> Version: 1.6.0-1
> Severity: important
> 
>* What led up to the situation?
> 
>  Using the attached example .muttrc (sanitized) reproduces the problem.
>  Opening the example.org mailbox will display the list of subscribed
>  folders below the last mailbox in the sidebar, instead of example.org.
> 
>  The IMAP server used on the remote end is:
>  ii  dovecot-imapd 1:2.2.13-12~deb8u1  amd64
> 
>  Marked important due to:
> 
>  Given there are several folders with the same name in my various 
> accounts,
>  this can lead to a confusion related to which account mails came in for,
>  or lead to mail for urgent accounts being missed.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  Tried tweaking the various sidebar options, ran into other already
>  reported bugs (823454, 823142).  Tweaking the order of the accounts in
>  the "mailboxes" line appears to make the folders appear in different
>  locations, sometimes in the correct location for a few accounts, but not
>  others.
> 
>* What was the outcome of this action?
> 
>  No difference.
> 
>* What outcome did you expect instead?
> 
>  Didn't expect a difference, as those options are unrelated, just tried
>  them to be thorough.

I suspect this is not an issue anymore with 1.14.4-2, can you confirm?

Bug#796080: mutt marks emails read when saving to a different mailbox

[Antonio Radici]

Control: tag -1 +moreinfo

Is this reproducible in mutt (sid version -> 1.14.4-2) rather than mutt-patched
for you?

mutt-patched does not exist anymore.

Bug#878197: Mutt destroys colors I set as default

[Antonio Radici]

Control: tag -1 +moreinfo

On Tue, Oct 10, 2017 at 04:37:54PM -0700, David Lawyer wrote:
> Package: mutt
> Version: 1.7.1-5
> 
> Here's the /etc/rc.local script I use to set colors.
> Note that I send ESC[8] to set as default.  Other programs such as vim
> restore the default colors after exiting but mutt doesn't nor does it use
> these colors.
> 
> # rc.local
> #
> # This script is executed at the end of each multiuser runlevel.
> # Make sure that the script will "exit 0" on success or any other
> # value on error.
> #
> # In order to enable or disable this script just change the execution
> # bits.   By default this script does nothing.
> 
> # Setting terminal colors  done here since it's done last.  If done sooner
> # they interfere with boot display
> 
> #  is esc and not the 2 chars ^[.  ESC[8] makes bg and fg indicies weak
> # defaults = seterm -store.  The reset command resets the color pallete.
> # RGB=rrggbb (6 hex digits) =red,green,blue. P7rrggbb makes color 7
> # (background 47) this defined RGB palette color.  Then ESC[47;30m applies
> # it.  
> 
> echo "Set colors and cursor on virtual terminals from /etc/rc.local"
> 
> #Colors:
> #Set palatte color first with P seq.
> echo "]P777ee99  [8]"> /dev/tty1 #my lt. green
> echo "]P755aabb " [8]> /dev/tty2 #my lt. cyan
> echo "[8]" > /dev/tty3 #7-grey #standard light white (grey)
> echo "]P7dd9988 " [8]> /dev/tty4 #my pink
>

I believe this was fixed at least a couple of years ago (I remember having
problems with ncurses when exiting mutt).

Can you let me know if that's not the case? 

Bug#568832: (no subject)

[Antonio Radici]

Cc
Bcc: 
Subject: Re: Bug#568832: [Mutt] #3486: "Attach:" pseudo-header cannot handle
 filenames with newline
Reply-To: 
In-Reply-To: <048.d8dd059aa74d60d347247acf21522...@mutt.org>

Control: severity -1 wishlist

To me this seems like a wishlist bug, rather than a proper bug, as there is a
way to attach files with a newline in the name anyway.

Bug#589430: mutt uses ncurses even in non-interactive mode

[Antonio Radici]

Control: tag -1 +moreinfo

On Sat, Jul 17, 2010 at 08:04:54PM +0200, Piotr Lewandowski wrote:
> Package: mutt
> Version: 1.5.20-9
> Severity: normal
> 
> Hello,
> 
> mutt uses ncurses even if there is no such need, i.e.:
> 
>  - with '-p' option,
>  - with '-Z' option if there is no new mail,
>  - in compose mode when editor is started right away.
> 
> After mutt exits user is left with cleaned screen and default color
> palette on some terminals[1], which is pretty annoying.
> 
> [1] http://bugs.debian.org/589429

Hi Piotr,
this used to be an issue in the past, where mutt did not handle terminals
correctly (and I also had issues as well), and reset their colors due to the
way ncurses was called.

Personally I haven't seen this issue in a long time, are you still seeing it?

Thanks!

Bug#698267: mutt: [PATCH] To/CC/Bc fields are stripped during editing (RFC 2822)

[Antonio Radici]

Control: tag -1 +pending

This is in git now, it will come with 1.14.4-4.

Bug#633993: Makes new connection to the SMTP server for every mail, even when sending several in one action

[Antonio Radici]

Control: severity -1 wishlist

On Fri, Jul 15, 2011 at 11:40:34AM -0700, Josh Triplett wrote:
> Package: mutt
> Version: 1.5.21-5
> Severity: normal
> 
> I selected an entire thread, and used ;b to bounce it to someone.  mutt
> made a new connection to the SMTP server for each mail it bounced,
> incurring the full latency of a connection to my SMTP server each time.
> mutt should have made a single connection to the SMTP server to send all
> the mails.
> 

Setting it to wishlist rather than bug (it seems to be the existing behavior
for a long time).

I will look into it anyway, it just makes it easier for me to classify it.

Bug#618607: mutt: loses IMAP message flags when the server terminates idle connection

[Antonio Radici]

Control: tag -1 +moreinfo

Many things in the imap source code in mutt where changed in the meantime, can
you check if it is still reproducible and provide us with a muttdebug log if
possible (please remove your password in that case).

Thanks!

Bug#860122: [Pkg-mutt-maintainers] Bug#860122: Bug#860122: mutt: SIGSEGV when saving a file to sshfs dir

[Antonio Radici]

tag -1 +moreinfo
thanks

On Mon, Jun 26, 2017 at 06:38:04PM +0200, Kim Alvefur wrote:
> On Mon, Jun 26, 2017 at 06:19:30AM +0000, Antonio Radici wrote:
> > Could you please install the debug symbols and send the stacktrace again?
> 
> Attached.
> 
> > More info on how to do so are here:
> > https://wiki.debian.org/AutomaticDebugPackages
> 
> Thanks, I was not aware of the separate source for debug symbols when I
> initially filed the report.

Hi Kim,
is this still an issue in sid? (1.14.4-1)

Bug#859652: mutt: Crashes when trying to display (or fetch) a specific S/MIME-signed message

[Antonio Radici]

tag -1 +moreinfo
thanks

On Sun, Jun 25, 2017 at 12:48:17PM +0200, Axel Beckert wrote:
> Control: found -1 1.8.3+neomutt20170609-1
> 
> Hi Antonio,
> 
> Axel Beckert wrote:
> > Antonio Radici wrote:
> > > On Wed, Apr 05, 2017 at 04:42:51PM +0200, Axel Beckert wrote:
> > > > for the first time since upgrading to Stretch a few months ago, mutt
> > > > crashed when I pressed enter on mail -- both when viewing locally as
> > > > well as via IMAP). Starting up mutt again and trying to display that
> > > > mail again crashes again, i.e. it seems to be reproducible.
> > [...]
> > > could you send the mail in private assuming that this is still 
> > > reproducible in
> > > 1.8.3+neomutt20170609-1? thanks!
> > 
> > Will do soon. (At least in 1.8.0-1, the issue is still present.)
> 
> 1.8.3+neomutt20170609-1 crashes as well. Will send you an mbox
> containing that mail in private.
> 

Hi Axel,
getting back to you some years later, I was wondering if this bug is still 
present.
Is it reproducible in sid?

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

[Antonio Radici]

tag -1 +pending
thanks

On Sat, Jun 20, 2020 at 08:19:32AM +0200, Antonio Radici wrote:
> On Fri, Jun 19, 2020 at 04:04:37PM -0700, Josh Triplett wrote:
> > On Thu, Jun 18, 2020 at 10:41:37PM -0700, Josh Triplett wrote:
> > > Package: mutt
> > > Version: 1.14.3-1
> > > Severity: important
> > > 
> > > "important" because it makes a previously working configuration
> > > unusable.
> > > 
> > > The fix for CVE-2020-14093 makes it so that when using a
> > > preauthenticated connection (using `set tunnel` to SSH to the IMAP
> > > server), mutt just prints "Encrypted connection unavailable" and refuses
> > > the connection. An strace shows that mutt successfully runs SSH and gets
> > > the preauthenticated IMAP connection.
> > > 
> > > I do not have any ssl-related options set. Best guess: the default
> > > ssl_starttls=yes makes mutt think it should starttls over preauth, which
> > > it now avoids due to the CVE.
> > 
> > I can confirm that setting ssl_starttls=no allows preauthenticated IMAP
> > connections using `set tunnel` to work again.
> > 
> 
> Created issue https://gitlab.com/muttmua/mutt/-/issues/250

Fix already in git, it will come up with 1.14.4-2

Bug#839556: mutt: The default 'y' keybind no longer works in a POP mailbox.

[Antonio Radici]

tag 839556 +moreinfo
thanks

Hi,
is bug reproducible with the latest version of mutt on debian (1.14.4-1)?

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

[Antonio Radici]

On Fri, Jun 19, 2020 at 04:04:37PM -0700, Josh Triplett wrote:
> On Thu, Jun 18, 2020 at 10:41:37PM -0700, Josh Triplett wrote:
> > Package: mutt
> > Version: 1.14.3-1
> > Severity: important
> > 
> > "important" because it makes a previously working configuration
> > unusable.
> > 
> > The fix for CVE-2020-14093 makes it so that when using a
> > preauthenticated connection (using `set tunnel` to SSH to the IMAP
> > server), mutt just prints "Encrypted connection unavailable" and refuses
> > the connection. An strace shows that mutt successfully runs SSH and gets
> > the preauthenticated IMAP connection.
> > 
> > I do not have any ssl-related options set. Best guess: the default
> > ssl_starttls=yes makes mutt think it should starttls over preauth, which
> > it now avoids due to the CVE.
> 
> I can confirm that setting ssl_starttls=no allows preauthenticated IMAP
> connections using `set tunnel` to work again.
> 

Thanks for the report, I'll file a bug upstream.

Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection

[Antonio Radici]

On Fri, Jun 19, 2020 at 04:04:37PM -0700, Josh Triplett wrote:
> On Thu, Jun 18, 2020 at 10:41:37PM -0700, Josh Triplett wrote:
> > Package: mutt
> > Version: 1.14.3-1
> > Severity: important
> > 
> > "important" because it makes a previously working configuration
> > unusable.
> > 
> > The fix for CVE-2020-14093 makes it so that when using a
> > preauthenticated connection (using `set tunnel` to SSH to the IMAP
> > server), mutt just prints "Encrypted connection unavailable" and refuses
> > the connection. An strace shows that mutt successfully runs SSH and gets
> > the preauthenticated IMAP connection.
> > 
> > I do not have any ssl-related options set. Best guess: the default
> > ssl_starttls=yes makes mutt think it should starttls over preauth, which
> > it now avoids due to the CVE.
> 
> I can confirm that setting ssl_starttls=no allows preauthenticated IMAP
> connections using `set tunnel` to work again.
> 

Created issue https://gitlab.com/muttmua/mutt/-/issues/250

Bug#962897: mutt: CVE-2020-14093

[Antonio Radici]

On Mon, Jun 15, 2020 at 06:38:44PM +0200, Salvatore Bonaccorso wrote:
> Source: mutt
> Version: 1.14.0-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for mutt.
> 
> CVE-2020-14093[0]:
> | Mutt before 1.14.3 allows an IMAP fcc/postpone man-in-the-middle
> | attack via a PREAUTH response.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2020-14093
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14093
> [1] 
> https://github.com/muttmua/mutt/commit/3e88866dc60b5fa6aaba6fd7c1710c12c1c3cd01
> 
> Please adjust the affected versions in the BTS as needed.

The updated package will be uploaded between today and tomorrow

Bug#962381: gqrx-sdr: gqrx segmentation fault at start time in testing

[Antonio Radici]

Package: gqrx-sdr
Version: 2.12.1-1+b3
Severity: grave
Justification: renders package unusable

gqrx does not start in testing, this renders the package unusable.

The problem is reproducible by spinning up a testing chroot (as of today) and
trying to start gqrx

This is the stacktrace:

***
Thread 1 "gqrx" received signal SIGSEGV, Segmentation fault.
0x555f5a52 in 
boost::system::error_category::equivalent(boost::system::error_code const&, 
int) const ()
(gdb) thread apply all bt

Thread 3 (Thread 0x7fffecc54700 (LWP 1745241)):
#0  0x7599cb7f in __GI___poll (fds=0x7fffe00029e0, nfds=3, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x736847fe in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7368491f in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x768637c1 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x7680c6db in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7664d6f1 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7fffefe724e6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7664e872 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x77cd4f27 in start_thread (arg=) at 
pthread_create.c:479
#9  0x759a731f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7fffef132700 (LWP 1745240)):
#0  0x7599cb7f in __GI___poll (fds=0x7fffef131828, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x730cfd02 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x730d198a in xcb_wait_for_event () from 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fffeffabca0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7664e872 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x77cd4f27 in start_thread (arg=) at 
pthread_create.c:479
#6  0x759a731f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x703e8c80 (LWP 1745239)):
#0  0x555f5a52 in 
boost::system::error_category::equivalent(boost::system::error_code const&, 
int) const ()
#1  0x76331e8f in boost::asio::detail::posix_mutex::posix_mutex() () 
from /usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.8.1
#2  0x763329c7 in boost::asio::io_context::io_context() () from 
/usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.8.1
#3  0x7635ac5c in ?? () from 
/usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.8.1
#4  0x7635ad39 in gr::blocks::udp_sink::make(unsigned long, 
std::__cxx11::basic_string, std::allocator > 
const&, int, int, bool) () from 
/usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.8.1
#5  0x55641ecc in udp_sink_f::udp_sink_f() ()
#6  0x556425ef in make_udp_sink_f() ()
#7  0x556122aa in receiver::receiver(std::__cxx11::basic_string, std::allocator >, 
std::__cxx11::basic_string, std::allocator 
>, unsigned int) ()
#8  0x55605cd0 in MainWindow::MainWindow(QString, bool, QWidget*) ()
#9  0x555e9f57 in main ()
***

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), 
LANGUAGE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gqrx-sdr depends on:
ii  libboost-program-options1.71.0  1.71.0-6+b2
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libgnuradio-analog3.8.1 3.8.1.0-1+b3
ii  libgnuradio-blocks3.8.1 3.8.1.0-1+b3
ii  libgnuradio-digital3.8.13.8.1.0-1+b3
ii  libgnuradio-fft3.8.13.8.1.0-1+b3
ii  libgnuradio-filter3.8.1 3.8.1.0-1+b3
ii  libgnuradio-osmosdr0.2.00.2.0-2+b3
ii  libgnuradio-pmt3.8.13.8.1.0-1+b3
ii  libgnuradio-runtime3.8.13.8.1.0-1+b3
ii  liblog4cpp5v5   1.1.3-1
ii  libpulse0   13.0-5
ii  libqt5core5a5.12.5+dfsg-10+b1
ii  libqt5gui5  5.12.5+dfsg-10+b1
ii  libqt5network5  5.12.5+dfsg-10+b1
ii  libqt5svg5  5.12.5-2
ii  libqt5widgets5  5.12.5+dfsg-10+b1
ii  libstdc++6  10.1.0-3
ii  pulseaudio  13.0-5

gqrx-sdr recommends no packages.

gqrx-sdr suggests no packages.

-- no debconf information

Bug#944191: mutt: Mutt Fails GNU TLS Handshake

[Antonio Radici]

On Tue, Nov 12, 2019 at 12:18:14PM -0600, David Engel wrote:
> On Sat, Nov 09, 2019 at 05:52:59PM +0000, Antonio Radici wrote:
> > On Tue, Nov 05, 2019 at 10:23:25AM -0600, David Engel wrote:
> > > Package: mutt
> > > Version: 1.12.2-1
> > > Severity: normal
> > > 
> > > Beginning with version 1.12.2-1, Mutt fails GNU TLS handshake with the
> > > following error when connecting to an MS Exchange server:
> > > 
> > > gnutls_handshake: A packet with illegal or unsupported version was 
> > > received.
> > > 
> > > The problem does not exist with Mutt version 1.10.1-2.1.
> > > 
> > 
> > Is this pop3 or imap or smtp?
> 
> Imap.
> 
> > Could you include the muttdebug file which is obtained by using the debug 
> > option
> > with mutt? be aware that your personal information (including password) 
> > might be
> > there, so please remove that before attaching it to the bug.
> 
> .muttdebug0 from running with -d2 is attached.  It doesn't appear to
> be of much help.

Do you know which version of TLS your imap server is using?
be aware that version < 1.2 are not supported and you will have to enable them
on .muttrc explicitely if you need them (see man muttrc, look for 
'ssl_use_tlsv1'
and 'ssl_use_tlsv1_1'

Bug#944191: mutt: Mutt Fails GNU TLS Handshake

[Antonio Radici]

On Tue, Nov 05, 2019 at 10:23:25AM -0600, David Engel wrote:
> Package: mutt
> Version: 1.12.2-1
> Severity: normal
> 
> Beginning with version 1.12.2-1, Mutt fails GNU TLS handshake with the
> following error when connecting to an MS Exchange server:
> 
> gnutls_handshake: A packet with illegal or unsupported version was received.
> 
> The problem does not exist with Mutt version 1.10.1-2.1.
> 

Is this pop3 or imap or smtp?

Could you include the muttdebug file which is obtained by using the debug option
with mutt? be aware that your personal information (including password) might be
there, so please remove that before attaching it to the bug.

Bug#928353: Fwd: release-notes: document mutt vs neomutt in buster

[Antonio Radici]

This is what I propose to write down in the release notes, feel free to adjust
as you see fit


Starting from Buster, the mutt package will be shipped again from the original
sources from https://www.mutt.org, this means that some of the features that
were previously available due to patches applied to the mutt project, which we
shipped as 'mutt' for the Stretch release, are no longer availables and that
your configuration might be broken.

If you want to restore the previous behavior you can install the 'neomutt'
package which will ship the '/usr/bin/neomutt' binary; that is built off the
sources from https://www.neomutt.org.

Bug#928353: Fwd: release-notes: document mutt vs neomutt in buster

[Antonio Radici]

Thanks for pinging me, I missed this, let me comment on the bug.

On Sun, May 05, 2019 at 02:51:35PM +0200, Paul Gevers wrote:
> Hi,
> 
> I'm not sure if this release-notes bug that I addressed to you actually
> reached you.
> 
> Paul
> 
> 
>  Forwarded Message 
> Subject: Bug#928353: release-notes: document mutt vs neomutt in buster
> Date: Thu, 2 May 2019 18:53:55 +0200
> From: Paul Gevers 
> To: Debian Bug Tracking System 
> 
> Package: release-notes
> X-Debbugs-CC: m...@packages.debian.org, j...@debian.org
> 
> Dear (neo|)mutt maintainers,
> 
> I recently learned about the mutt versus neomutt situation in buster via
> the blog [1] of jmtd (in X-D-CC). I believe mutt and neomutt warrant a
> note in the release notes, don't you agree?
> 
> As the maintainers of this software, you are in the best position to
> write this. Are you willing and able to provide a piece of text? MR
> against the release notes archive [2] are welcome, but otherwise just
> sent to this bug is fine.
> 
> Paul
> 
> [1] https://jmtd.net/log/mutt_year_zero/
> [2] https://salsa.debian.org/ddp-team/release-notes/
> 
> 
> 

Bug#915804: Should this package be removed?

[Antonio Radici]

On Wed, Jan 09, 2019 at 12:03:03AM +0100, Moritz Mühlenhoff wrote:
> On Wed, Dec 19, 2018 at 11:56:47PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-12-06 22:52:32 [+0100], Moritz Muehlenhoff wrote:
> > > Source: cfengine2
> > > Severity: serious
> > > 
> > > This is replaced by src:cfengine2 and stretch has both cfengine2 and 
> > > cfengine3,
> > > so users can migrate within a stable release to 3.
> > > 
> > > The current version is also RC-buggy for a long time and blocks the 
> > > removal
> > > of OpenSSL 1.0.
> > 
> > cfengine2 is like a decade old. I found nothing in their blog. Only the
> > convert tool:
> >   https://cfengine.com/company/blog-detail/cfengine-2-conversion-tool/
> 
> No objections to my bug for a month, so I went ahead and filed a removal
> bug.

I fully agree on the removal.

Bug#918101: cfengine3: Please package new LTS release (3.12) before Buster freezes

[Antonio Radici]

On Thu, Jan 03, 2019 at 11:16:46AM +0100, Moritz Schlarb wrote:
> Source: cfengine3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please consider packaging the latest LTS release (3.12.1) before the Buster
> freezes begin.
> 
> IMHO this makes sense if you look at the upstream support timeline at
> https://cfengine.com/product/supported-versions/ - support for 3.10 will stop
> just after Buster is actually released, whereas 3.12 will overlap more with 
> the
> Buster support timeline.
> 
> Christoph and I are happy to help with the package maintanance.

Thanks a lot for letting me know, I will do it in the next few days, hopefully
between today and tomorrow (I just need a reliable connection).

Bug#905618: mutt: Tracking bug for security updates to mutt in stretch

[Antonio Radici]

On Tue, Aug 07, 2018 at 11:08:36AM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Tue, Aug 07, 2018 at 09:55:59AM +0100, Antonio Radici wrote:
> > Package: mutt
> > Version: 1.7.2-1
> > Severity: grave
> > Tags: security upstream
> > Justification: security update
> > 
> > Tracking bug for security updates for mutt in stretch.
> > 
> > Details on https://security-tracker.debian.org/tracker/source-package/mutt
> 
> FTR, There is #904051 (for those issues which are fixed in 1.10.1-1
> but not those which were affected only in the neomutt patch).
> 
> There are a couple of CVEs which are adressed in sid by 1.9.1-1 where
> it was switched to official mutt.org package without neomutt patchset
> and were previous versions were shipping the neomutt patchset.
> 
> So I think in principle we cann forcemerge 905618 into 904051.

Ack, it makes sense, I can use that one.I did open a new one because #904051 was
closed. 

I've just finished with all the patches and they are in git right now, I'm
building the package as we speak (or write).

Bug#905618: mutt: Tracking bug for security updates to mutt in stretch

[Antonio Radici]

Package: mutt
Version: 1.7.2-1
Severity: grave
Tags: security upstream
Justification: security update

Tracking bug for security updates for mutt in stretch.

Details on https://security-tracker.debian.org/tracker/source-package/mutt

Patches are already provided by robe...@debian.org for jessie and currently
stored in jessie-updates.

-- Package-specific info:
Mutt 1.10.1 (2018-07-13)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.17.0-1-amd64 (x86_64)
ncurses: ncurses 6.1.20180714 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-25' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-25) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-92M5sF/mutt-1.10.1=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-92M5sF/mutt-1.10.1=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  +USE_SIDEBAR  +USE_COMPRESSED  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), 
LANGUAGE=en_IE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutt depends on:
ii  libassuan02.5.1-2
ii  libc6 2.27-5
ii  libcom-err2   1.44.3-1
ii  libgnutls30   3.5.19-1
ii  libgpg-error0 1.32-1
ii  libgpgme111.11.1-1
ii  libgssapi-krb5-2  1.16-2
ii  libidn11  1.33-2.2
ii  libk5cry

Bug#883799: [Pkg-mutt-maintainers] Bug#883799: mutt: update-alternatives for mutt family

[Antonio Radici]

On Thu, Dec 07, 2017 at 05:51:18PM +0100, Richard Hartmann wrote:
> Package: mutt
> Severity: normal
> 
> Now that the mutt package is back to an upstream version and a neomutt
> package exists, I keep seeing installations of people break left and
> right.
> 
> While the case could be made that neomutt and mutt are different, all
> neomutt users I know consider neomutt the now-canonical version of mutt.
> 
> Long story short, would you be willing to have neomutt linked as mutt
> via update-alternatives?
> 
> 
We have a bug on the neomutt side for the same problem. I'm planning to offer
both and set up update-alternatives.

Bug#883106: mutt: null pointer dereference in mbox_to_udomain()

[Antonio Radici]

On Wed, Nov 29, 2017 at 07:40:09PM +0100, Jakub Wilk wrote:
> Package: mutt
> Version: 1.9.1-5
> 
> Mutt crashes on this mbox:
> 
>   $ printf 'From Wed Nov 0 0: 0\nTo:=??B??=:\n' > nullptr.mbox
>   $ mutt -R -f nullptr.mbox >/dev/null 2>&1

Thanks for the patch, I will do an upload tonight.

Bug#883007: [Pkg-mutt-maintainers] Bug#883007: Bug#883007: neomutt: sendmail configuration

[Antonio Radici]

On Tue, Nov 28, 2017 at 07:44:13PM +0100, Elimar Riesebieter wrote:
> * Arthur Gautier  [2017-11-28 18:08 +]:
> 
> Sorry, my fault. I can now reproduce with 20171027 installed. This
> was fixed in git commit 55f99f3e three weeks ago. You should ask
> Antonio whether he'll backport that commit or update to master.
> Possibly we'll get a new upstream release shortly, though. neomutt
> has to be build with autosetup then.
> 

I'll backport the commit, neomutt in Debian is already built using autosetup :)

Bug#882690: [Pkg-mutt-maintainers] Bug#882690: mutt: creates short name local mail address instead of FQDN

[Antonio Radici]

On Sat, Nov 25, 2017 at 11:19:33AM -0700, Bob Proulx wrote:
> Package: mutt
> Version: 1.9.1-4
> Severity: normal
> 
> With the latest mutt package it appears that local email addresses are
> now created using the short host name instead of the FQDN as done
> previously.
> 
> With the previous mutt version:
> 
>   $ mutt rwp
>   To: Bob Proulx 
> 
> With the current mutt version:
> 
>   $ mutt rwp
>   To: Bob Proulx 
> 
> With the default email configuration here at least the short name is
> not recognized and this generates a bounce[1].  In any case it seems
> an undesirable change.
> 
> Thank you for maintaining mutt in Debian.
> 

This is caused by a patch that has been dropped, I need to reinstate that.

I'll prepare an upload tomorrow.

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

[Antonio Radici]

Tags: + pending

Hi Bob,
thanks for your report, I've fixed this in git, it will be included in 1.9.1-5

Bug#882461: mutt: out-of-date package description

[Antonio Radici]

On Thu, Nov 23, 2017 at 09:10:56AM +0100, Jakub Wilk wrote:
> Package: mutt
> Version: 1.9.1-2
> 
> The package description says "This package is built with the NeoMutt
> patchset", but this is no longer the case.
> 

I've already fixed this in git, it will be in the next Debian release of this
package.

Bug#882300: ITP: neomutt -- A command line mail reader (or MUA). It's a version of Mutt with added features.

[Antonio Radici]

On Wed, Nov 22, 2017 at 08:29:20AM +0100, Elimar Riesebieter wrote:
> * Antonio Radici  [2017-11-21 08:58 +]:
> 
> > Package: wnpp
> > Severity: wishlist
> > Owner: anto...@debian.org
> > 
> > * Package name: neomutt
> >   Version : 1.9.1+20171027
> 
> Shouldn't be the version 20171027 only if you are going to package
> neomutt's git tag neomutt-20171027? neomutt doesn't use mutt's
> version anymore.
> 

Hi Elimar,
yes I spoke with Richard and we are going to use date only, he confirmed that
this is the one he is going to use in the future

Bug#882320: mutt: fails on startup when loading notmuch.rc

[Antonio Radici]

On Tue, Nov 21, 2017 at 10:38:41AM -0200, Antonio Terceiro wrote:
> Package: mutt
> Version: 1.9.1-1
> Severity: normal
> 
> Freshly-created account, no muttrc, nothing
> 
> tmpuser@host:~$ mutt
> Error in /etc/Muttrc.d/notmuch.rc, line 6: change-vfolder: no such function 
> in map
> Error in /etc/Muttrc.d/notmuch.rc, line 9: entire-thread: no such function in 
> map
> Error in /etc/Muttrc.d/notmuch.rc, line 12: modify-labels: no such function 
> in map
> Error in /etc/Muttrc.d/notmuch.rc, line 15: vfolder-from-query: no such 
> function in map
> Error in /usr/lib/mutt/source-muttrc.d|, line 5: source: errors in 
> /etc/Muttrc.d/notmuch.rc
> Error in /etc/Muttrc, line 141: source: errors in 
> /usr/lib/mutt/source-muttrc.d|
> source: errors in /etc/Muttrc
> Press any key to continue...
> tmpuser@host:~$ dpkg -S /etc/Muttrc.d/notmuch.rc
> mutt: /etc/Muttrc.d/notmuch.rc

Hi,
I'll fix this bug today, this is due to the fact that we reverted to the source
code form mutt.org which does not include notmuch yet.

I've started a conversation with the upstream dev to see if the patch can be
incorporated, I'll remove the Muttrc.d file in the meantime.

Bug#882300: ITP: neomutt -- A command line mail reader (or MUA). It's a version of Mutt with added features.

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: anto...@debian.org

* Package name: neomutt
  Version : 1.9.1+20171027
  Upstream Author : Richard Russon 
* URL : http://www.neomutt.org
* License : GPLv2
  Programming Lang: C
  Description : NeoMutt is a command line mail reader (or MUA). It's a 
version of Mutt with added features.


To give more context, have a look at b/870635; neomutt was packaged as 'mutt' in
stretch but the current mutt maintainer has raised issue of the tarball being
used: since the codebase of neomutt diverged (initially due to code formatting
changes, then due to some API changes and code split), which made patching mutt
with a single huge neomutt patch impractical (the patch was larger than the
source code).

We have restored original mutt source code at version 1.9.1-1 and given that
this was just done, I plan to spin up a new neomutt package starting from the
same version (with the latest version of neomutt); the plan is to fork the
pkg-mutt git repository from the latest tag and start from there, packaging the
new neomutt version.

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

[Antonio Radici]

Can I please ask both of you to stop this flame?

It's not helping anyone.

I'm currently the maintainer of the mutt package and I have made my commitment
to Kevin in multiple occasions to fix the current situation and I'm going to fix
it.

I've collaborated with Kevin in the past and he has always been very
collaborative, the same applies to the Richard from the neomutt community; the
relationship between the two hasn't been great but at the same time it is
legitimate to ask to package mutt as the mutt tarball and I'm going to honor
that commitment that I took in the past.

Please refrain from engaging in flames, it's just a waste of time and it's not
going to change the current situation or convince me to take a different avenue.

On Mon, Nov 20, 2017 at 01:18:26PM -0800, Kevin J. McCarthy wrote:
> 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:
[...]

Bug#870635: [Pkg-mutt-maintainers] Bug#870635: mutt package is not using the official mutt tarball

[Antonio Radici]

On Fri, Nov 17, 2017 at 04:46:21PM +, Jonathan Dowland wrote:
> debian-de...@lists.debian.org
> Bcc: Subject: Re: Bug#870635: mutt package is not using the official mutt
> tarball
> Reply-To: In-Reply-To: <2017074105.iz5bje4kgkl3q...@cherubino.dyne.org>
> 
> CCing -devel because I think this might be of wider interest.

I believe you haven't CC'd -devel but feel free to forward your response and my
response to the -devel list, I only hit 'g' in mutt and ended up replying to the
original To/CC

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

[Antonio Radici]

On Fri, Nov 17, 2017 at 04:46:21PM +, Jonathan Dowland wrote:
> debian-de...@lists.debian.org
> Bcc: Subject: Re: Bug#870635: mutt package is not using the official mutt
> tarball
> Reply-To: In-Reply-To: <2017074105.iz5bje4kgkl3q...@cherubino.dyne.org>
> 
> CCing -devel because I think this might be of wider interest.

[...]
> 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.) If you are suggesting that the package name "mutt" is
> going to be real "mutt" in future, then what happens to existing
> users? What are their expectations? Do you reassign all existing bugs to
> a new neomutt package name? Do you attempt to triage all bugs to figure
> out whether they apply to one, the other, or both? Would users who are
> using neomutt features not find the change to be a regression from their
> point of view?

I think this is the most problematic point and one of the reason against having
a mutt package that is not a transitional package, despite that I still believe
that we need a 'neomutt' package, this need was raised by the mutt maintainer,
we cannot continue to distribute something called mutt where the source code
comes from another package, which is now completely different.

To provide more context: initially we shipped neomutt as a patch on the top of
the original mutt source code, then at some stage the neomutt team (it is in
thei right) to format their code in a consistent way across all files, so the
neomutt patch became bigger than the mutt source code, which is why I switched
to the neomutt tarball. That was the first and last upload with the neomutt
tarball (also the last upload for neomutt).

The original mutt maintainer raised the point that we cannot call the mutt
package as 'mutt' if the source comes from another package, especially since he
disagrees with some technical choices of the other package, so I think his
reasoning is correct.

> Secondly, is there a need for both mutt and neomutt in Debian? Our
> mission is not to package every piece of software on earth, but to build
> a useful operating system. Is there sufficient distinction between the
> two, from a user's perspective, that there is a genuine need for both in
> the archive? (Of course, the distinction is very important for the
> authors of the software. But that's not the same thing.) For enough
> users to justify the work? I've been a daily mutt (and now neomutt) user
> in Debian for nearly 20 years, and I don't think there is.

In an ideal world yes, in a real world where the maintenance is done by humans
probably not

 
> Thirdly, let's look honestly at how well the existing package maintenance
> is working. This particular issue was raise in late June[1], and you
> said at the time that'd you have come up with a transition plan within a
> couple of weeks[2]. For my pet neomutt bug[3] (which coincidentally I
> reported at around the same time) you expected to have the patch applied
> shortly, possibly even within a week[4], but it remains unfixed.

Unfortunately some non-Debian related commitments trumped my plans; yes I could
have uploaded bugfixes as I did in the past but I made a commitment to Kevin
(original mutt maintainer) to solve the source code issue first. Unfortunately
no easy solution is in sight, so for the benefit of the users I think that it is
better to have mutt as transational package + neomutt.

> I am not trying to criticise your personal contributions to Debian. We
> are all volunteers, and we all do what we can and nobody should expect
> more from us than we are prepared or able to give. I am extremely
> grateful for the work you have done and continue to do. But I think it's
> important to communicate as realistically as possible what we are able
> to do. I am very guilty of getting this wrong, and over-promising and
> under-delivering for my own efforts in Debian. I simply wish to point
> out that the existing Mutt packaging team appears to be stretched. It
> seems to me that having two mutt packages to manage is only going to
> make this situation much worse.

The existing Mutt packaging team it's just me for some time now, I had a similar
slow period in the past (I was the only maintainer at the time) and we ended up
with the decision of switching to neomutt, decision which I'm still trying to
sort out years later. I'm not trying to blame anyone here, I think who
contributed at the time did a fantastic work; the fact remains that the current
situation is not good for the maintainer of the upstream mutt package and it
needs to be fixed.

Thanks a lot for your feedback, it is very valuable. My last commitment, which
in theory should work, is to fix this situation before the end of the month. I
know that at this point in time this is '10 days from 

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

[Antonio Radici]

On Wed, Nov 08, 2017 at 09:52:06AM +, Jonathan Dowland wrote:
> On Thu, Aug 03, 2017 at 10:21:51PM +0000, Antonio Radici wrote:
> > as I said on the original thread I'm planning to fix this, and as you
> > can see there have been no new releases until the fix is in place.
> 
> It would be great if you could summarize *in this bug* what's your plan of
> action.
> 
> We are packaging neomutt, but calling it mutt. The obvious solution is to
> rename the package.  "mutt" could be used as transitional name to smoothly
> handle upgrades. This would not need to live for more than one release.
> 
> This would not proclude someone else from packaging "vanilla" mutt if they
> wanted to.

Sorry for the delay, my plan of action is to stop packaging neomutt with this
name, I'll create a new neomutt package (TBD by end of the month) and I'll think
if there is the need of a transitional package, the problem of a transitional
package is that mutt won't be packaged as mutt in stretch. To prevent that from
happening we will need two packages (mutt and neomutt) from two different
upstream sources.

So far the only thing which is certainly going to happen is the creation of the
neomutt package, then I could package the newest mutt as 'mutt' and think about
whether mutt needs to become a transitional package (which in that case will
remove mutt).

This is roughly my plan of action

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

[Antonio Radici]

On Thu, Aug 03, 2017 at 09:33:09AM -0700, Kevin McCarthy wrote:
> Package: mutt
> Version: 1.8.3+neomutt20170609-2
> Severity: serious
> Justification: Policy 2.3
> 
> Dear Maintainer,
> 
> I am the upstream project maintainer of Mutt.  Your version of the
> "mutt" package in unstable and testing is based on the NeoMutt
> tarball, not the official Mutt 1.8.3 release tarball.
> 
> If you wish to call your package "mutt", then you should be using the
> official Mutt release tarball are your "orig" tarball for the package.
> To do anything else is an unacceptable ethical and legal breach by
> Debian.
> 
> You have been aware of this issue since at least June 30th, see
> . As Erik
> Christiansen mentioned in that thread, while the GPLv2:
> 
>   "permits derivative works, it does not permit a derivative work to
>purport to be the copyrighted original work. Misrepresenting the
>"debneomutt" work as "mutt" would seem to clearly contravene the
>asserted and enforcible licence."
> 
> Even if the legal argument is not airtight, doing this is insulting
> and disrepectful to the Mutt project and to me as its maintainer.
> 
> Please correct this issue ASAP.

Hi Kevin,
as I said on the original thread I'm planning to fix this, and as you can see
there have been no new releases until the fix is in place.

As I stated already this is not going to be fixed for the existing stable
distribution (because we cannot change what was already shipped), but this is
certainly going to be fixed for the current unstable/testing.

I would expect this to be done in August, it is a slight delay from what we
discussed on a mailing list but nothing has changed from my plans.

Bug#867201: postgrey: crashes with "FATAL: Can't call method "network" on an undefined value at /usr/sbin/postgrey line 204."

[Antonio Radici]

Control: tags -1 + moreinfo

On Thu, Jul 06, 2017 at 10:38:37AM +0200, Julien Cristau wrote:
> All good, at least the crash prompted me to look at this and update our
> exim config.  Might not have noticed otherwise :)
> 

Hi Julien,
this bug will be automatically closed by the 1.36-4 upload in unstable, but
obviously it's not solved for stretch so I'll reopen it.

Could you try the latest version in unstable in stretch? I can provide a
backport if needed, it builds clean without changes on a stretch pbuilder.

I've ported the new ip parsing code which should prevent this from happening,
I'm not sure if I have to resize the patch for stable-proposed-updates.

Looking forward to your feedback!

Bug#867201: postgrey: crashes with "FATAL: Can't call method "network" on an undefined value at /usr/sbin/postgrey line 204."

[Antonio Radici]

On Tue, Jul 04, 2017 at 09:38:35PM +0200, Julien Cristau wrote:
> Control: severity -1 normal
> 
> On Tue, Jul  4, 2017 at 19:27:09 +0200, Julien Cristau wrote:
> 
> > Source: postgrey
> > Version: 1.36-3
> > Severity: grave
> > User: debian-ad...@lists.debian.org
> > Usertags: needed-by-DSA-Team
> > X-Debbugs-Cc: debian-ad...@lists.debian.org
> > 
> > After upgrading one of our mail relays to stretch, postgrey regularly
> > crashes with the error is $subject.
> > 
> > This might or might not be fixed upstream with
> > https://github.com/schweikert/postgrey/commit/95a2cd8f7f132aae8c62e9706dd9459afca84a5c
> > which changed the relevant code and among other things added checks for
> > NetAddr::IP->new returning undef.
> > 
> Turns out this was most likely due to the recently-added ipv6 support in
> postgrey [0], and our exim config [1] using the ${mask:...} operator,
> which would return addresses such as
> "2a02.1600......" [2].  NetAddr::IP would then
> parse that as an ipv4 address and fail, and postgrey doesn't check for
> that condition.
> 

This is unfortunate, I will have a patch for stable-proposed-updates on
Saturday, sorry for the inconvenience :(

Bug#866312: [Pkg-mutt-maintainers] Bug#866312: mutt: mailspell uses deprecated POSIX::tmpnam()

[Antonio Radici]

Control: tags -1 + confirmed pending

On Wed, Jun 28, 2017 at 10:49:14PM +0300, Niko Tyni wrote:
> Package: mutt
> Version: 1.8.3+neomutt20170609-2
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.26-transition
> 
> The mailspell helper uses POSIX::tmpnam(), which was deprecated in
> Perl 5.22.and is removed in Perl 5.26 (currently in experimental.)
> 
>   % /usr/lib/mutt/mailspell /dev/null
>   Calling POSIX::tmpnam() is deprecated at /usr/lib/mutt/mailspell line 37.
> 
> Please use File::Temp instead.
> -- 

Fixed in git, will be part of the next upload.

Bug#866366: mutt: my index_format setting is corrupted with newer (neo)mutts

[Antonio Radici]

On Thu, Jun 29, 2017 at 05:02:55PM +0100, Jonathan Dowland wrote:
> tags 866366 +patch
> thanks
> 
> fd852e5556dc6c9194d5e72acce734321defe2f8 from upstream's repo (branch
> devel/expando, also attached) fixes this and applies cleanly on top of the
> package sources (I dropped it into debian/patches/applyme and modified series
> and all was well)

Thanks a lot for this (and thanks to Richard).
This will be released shortly, even this weekend if I manage to fix a
couple of segfaults that are still around.

Bug#845067: mutt: Crash when scrolling past the end of a message

[Antonio Radici]

Control: tag -1 + moreijnfo

On Sun, Nov 20, 2016 at 01:47:14AM +, Sam Morris wrote:
> Package: mutt
> Version: 1.7.1-3
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I triggered this by pressing space while at the end of a message.
> Backtrace attached...

Any chance you could send us a copy of that message? Feel free to remove any
confidential information, I know some people are having segfaults with similar
backtraces but I've been unable to reproduce this so far.

Bug#836779: [Pkg-mutt-maintainers] Bug#836779: mutt: fails to display the correct count of message in the virtual folder index

[Antonio Radici]

Control: tag -1 + moreinfo

On Mon, Sep 05, 2016 at 06:38:32PM +0200, Nicolas Évrard wrote:
> Package: mutt
> Version: 1.7.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I use mutt with notmuch and I bound a key to change-vfolder.
> When this key is pressed if I use '?' insead of switching to a vfolder, you
> will go to a screen displaying all the vfolders with the mail and unread
> counts.
> 
> Both counts are 0 when they should be different (although in some situation 
> the
> unread count is correct but I haven't found yet a pattern).

Hi there!
are you still able to reproduce the bug with 1.8.3+neomutt20170609-2?

Bug#530584: mutt: should use /var/tmp for mail drafts by default

[Antonio Radici]

Control: tags -1 + pending

Time to revisit this bug, probably worth changing the default at this point.

Bug#838720: [Pkg-mutt-maintainers] Bug#838720: closed by Sebastian Ramacher (Re: Bug#837584: mutt: crash while navigating through inbox)

[Antonio Radici]

On Sun, Jun 25, 2017 at 07:50:00PM +, Antonio Radici wrote:
> On Sun, Jun 25, 2017 at 12:14:29PM -0400, Peter Colberg wrote:
> > Control: reopen -1
> > Control: found -1 1.7.2-1
> > Control: tags -1 stretch
> > 
> > > On 2017-06-24 18:49:55, Antonio Radici wrote:
> > > > On Mon, Sep 12, 2016 at 04:51:21PM +0200, Sebastian Ramacher wrote:
> > > > 
> > > > I believe this has been solved in 1.8.3+neomutt20170609-1; I've removed 
> > > > all
> > > > pager.c patches and we moved to neomutt upstream.
> > > > 
> > > > Could you tell me if this is still happening for you?
> > > 
> > > I haven't seen the crash since upgrading to 1.8.0-1, so let's close it 
> > > with that
> > > version.
> > 
> > Could you please backport the fix(es) for inclusion in the next stable
> > point release? mutt in stable is still segfaulting on a regular basis.
> > 
> 
> Hi Peter,
> I would happily do it but unfortunately I've been unable to identify the
> culprit, despite me spending a lot of time in pager.c
> 
> In mutt 1.8.0 upstread did completely rewrite the pager, and neomutt also put
> some patches on the top on that, to clean up the code, so the problem is 
> fixed. 
> 
> I will try to investigate a bit more and try to write a patch for stretch but 
> it
> will require some more time unfortunately.
> 

Hi Peter,
I've tried to reproduce the problem and the procedure outlined in the message
sent by Hannes on Mon, 12 Sep 2016 21:37:10 +0200 does not make it reproducible.

Could you please post a stacktrace of your issue? it seems to me that it
might not be related to this bug (maybe it's the imap ssl problem)