Broken neomutt version 20250109 - DO NOT USE
Hi, it has just come to my attention that Neomutt version 20250109 had a major bug [0]: copying or moving an email to an existing folder results in the mailbox being truncated first (!). This results in permanent loss of email, if not otherwise backed up. DO NOT USE NEOMUTT VERSION 20250109! Timeline ======== Unfortunately I had just submitted this version of neomutt to Factory [1] before the release was retracted by upstream (with no notifications). Upstream prepared a fixed version 20250113 already yesterday, but I did not realise the severity of the bug (it was not mentioned in the release notes) and the release had been published unsigned, so I asked upstream if the signature could be provided [2]. I have now submitted the fixed version to Factory [3]. I just asked that it is processed quickly, or that the previous version is reverted. Unfortunately it is now late in the day so I don't know how soon that will happen. Remediation =========== In the meantime DO NOT USE Neomutt version 20250109. You can find your currently installed Neomutt version with $ rpm -q neomutt neomutt-20241212-1.2.x86_64 If you get versions earlier than 20250109, you're safe. You can prevent any neomutt updates for the time being by adding a lock: $ sudo zypper addlock neomutt If you get version 20250109, DO NOT USE IT! The best course of action is probably to revert to the BTRFS snapshot just before the update, and lock neomutt as shown above before updating again. Once the fixed Neomutt version 20250113 is available in Factory, you can remove the lock and update normally. I will let you know once that is the case. Sorry for the trouble, Filippo [0] https://github.com/neomutt/neomutt/issues/4541 [1] https://build.opensuse.org/requests/1237318 [2] https://github.com/neomutt/neomutt/issues/4544 [3] https://build.opensuse.org/requests/1237908 -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On Tue, Jan 14, 2025 at 07:50:52PM +0100, Filippo Bonazzi wrote:
Hi, A brief update on the situation described above and in the previous message. The neomutt version in Factory has been reverted to the previous safe one (20241212) yesterday morning. The Factory snapshot was not published to Tumbleweed before this morning due to some technical circumstances I do not control or understand. It should become available in the next few hours. I will notify you with a final email here once the situation is stable. In the meantime, these are the measures you can take: Remediation =========== You can find your currently installed Neomutt version with $ rpm -q neomutt neomutt-20241212-1.2.x86_64 If you never updated neomutt to 20250109 ---------------------------------------- The same measures suggested in the previous email apply. Do not update neomutt. You can guarantee that by applying a lock: $ sudo zypper addlock neomutt neomutt-doc neomutt-lang This way, you can perform other updates normally with zypper dup while leaving neomutt at the safe version you already have. These locks can be removed once the Tumbleweed repos contain the safe version again (see above). If you updated neomutt to 20250109 ---------------------------------- DO NOT USE NEOMUTT version 20250109. Now you can install the old safe neomutt version 20241212, without needing to roll back BTRFS snapshots as suggested in the previous email. You can do that like this: $ wget https://download.opensuse.org/tumbleweed/repo/oss/x86_64/neomutt-20241212-1.... $ wget https://download.opensuse.org/tumbleweed/repo/oss/noarch/neomutt-doc-2024121... $ wget https://download.opensuse.org/tumbleweed/repo/oss/noarch/neomutt-lang-202412... $ sudo zypper install --oldpackage neomutt-20241212-1.2.x86_64.rpm neomutt-doc-20241212-1.2.noarch.rpm neomutt-lang-20241212-1.2.noarch.rpm Once you have downgraded these three packages, apply a lock on them: $ sudo zypper addlock neomutt neomutt neomutt-doc neomutt-lang This way, you can perform other updates normally with zypper dup while leaving neomutt at the safe version you just downgraded to. These locks can be removed once the Tumbleweed repos contain the safe version again (see above). Sorry again for the trouble, Filippo -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On Thu, Jan 16, 2025 at 12:46:35PM +0100, Filippo Bonazzi wrote:
Hi, A final update on the situation described above and in the previous message. The neomutt version in Tumbleweed has been reverted to the previous safe one (20241212). It is now safe to install or update neomutt. Updating ======== Take note of the neomutt version you have currently installed: $ rpm -q neomutt neomutt-20241212-1.2.x86_64 If you had applied any locks to the neomutt packages, it is now safe to remove them: $ sudo zypper removelock neomutt neomutt-doc neomutt-lang You can now update your system, forcing a refresh to guarantee getting the newly reverted version of neomutt: $ sudo zypper refresh --force $ sudo zypper dup If you still had the broken neomutt version 20250109 installed, zypper might warn you of the neomutt packages being downgraded. That is intended. After the update is completed, take note of the neomutt version: $ rpm -q neomutt neomutt-20241212-2.1.x86_64 NOTE: this version number (20241212-2.1) is greater than the previous one (20241212-1.2). This is intended. If you see any other neomutt version than this one, something has gone wrong. Analysis and Next steps ======================= This bug [0] was introduced upstream in version 20250109, and promptly noticed and fixed in version 20250113. A bug like this one is uncharacteristic of neomutt, at least I don't remember something like this. I had just submitted version 20250109 to Factory when version 20250113 was released. Since the release notes of version 20250113 did not mention the bug, I did not realise there was an urgent problem to deal with. By the time I got around to submitting version 20250113, enough time had passed to let version 20250109 arrive in Tumbleweed. At that point, realising there could still be other minor issues in version 20250113 [1], I decided it was better to revert neomutt to the previous version 20241212 instead of going forward. From here on you know the rest. I will now evaluate future neomutt releases much closer, before submitting them to Factory. Although I would not have spotted the bug myself, I could have noticed the bug report on Github had I waited a bit before submitting. I am considering now letting a few more days pass between new release and submission, waiting for any major bugs like this one to be discovered by others. I am aware this is contrary to the point of a rolling release. If you have a better plan, feel free to get in touch. Acknowledgements ================ Thank you to upstream contributor luchr and upstream author flatcap for noticing and promptly fixing the bug. Also thank you to the openSUSE contributors (Ana in particular) who helped me resolve this incident. Sorry again for the trouble, Filippo [0] https://github.com/neomutt/neomutt/issues/4541 [1] https://github.com/neomutt/neomutt/issues/4539 -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On Tue, Jan 21, 2025 at 12:02:13PM +0100, Pit Suetterlin via openSUSE Factory wrote:
NOTE: I am not the mutt maintainer, perhaps they can weigh in as well. I think mutt is completely unaffected. The bug happened on the bleeding edge of neomutt releases, which happen in [0] completely independent of mutt [1]. A cursory look in the mutt package changelog [2] can confirm that this bug has had no time or way to reach whatever form of packaging our mutt package uses. [0] https://github.com/neomutt/neomutt [1] https://gitlab.com/muttmua/mutt [2] https://build.opensuse.org/projects/openSUSE:Factory/packages/mutt/files/mut... -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On 2025/01/21 13:14:32 +0100, Filippo Bonazzi wrote:
You missed this one [3] https://gitlab.com/muttmua/mutt/-/issues/490 looks like upstream does not agree with the reports -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On Tue, Jan 14, 2025 at 07:50:52PM +0100, Filippo Bonazzi wrote:
Hi, A brief update on the situation described above and in the previous message. The neomutt version in Factory has been reverted to the previous safe one (20241212) yesterday morning. The Factory snapshot was not published to Tumbleweed before this morning due to some technical circumstances I do not control or understand. It should become available in the next few hours. I will notify you with a final email here once the situation is stable. In the meantime, these are the measures you can take: Remediation =========== You can find your currently installed Neomutt version with $ rpm -q neomutt neomutt-20241212-1.2.x86_64 If you never updated neomutt to 20250109 ---------------------------------------- The same measures suggested in the previous email apply. Do not update neomutt. You can guarantee that by applying a lock: $ sudo zypper addlock neomutt neomutt-doc neomutt-lang This way, you can perform other updates normally with zypper dup while leaving neomutt at the safe version you already have. These locks can be removed once the Tumbleweed repos contain the safe version again (see above). If you updated neomutt to 20250109 ---------------------------------- DO NOT USE NEOMUTT version 20250109. Now you can install the old safe neomutt version 20241212, without needing to roll back BTRFS snapshots as suggested in the previous email. You can do that like this: $ wget https://download.opensuse.org/tumbleweed/repo/oss/x86_64/neomutt-20241212-1.... $ wget https://download.opensuse.org/tumbleweed/repo/oss/noarch/neomutt-doc-2024121... $ wget https://download.opensuse.org/tumbleweed/repo/oss/noarch/neomutt-lang-202412... $ sudo zypper install --oldpackage neomutt-20241212-1.2.x86_64.rpm neomutt-doc-20241212-1.2.noarch.rpm neomutt-lang-20241212-1.2.noarch.rpm Once you have downgraded these three packages, apply a lock on them: $ sudo zypper addlock neomutt neomutt neomutt-doc neomutt-lang This way, you can perform other updates normally with zypper dup while leaving neomutt at the safe version you just downgraded to. These locks can be removed once the Tumbleweed repos contain the safe version again (see above). Sorry again for the trouble, Filippo -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On Thu, Jan 16, 2025 at 12:46:35PM +0100, Filippo Bonazzi wrote:
Hi, A final update on the situation described above and in the previous message. The neomutt version in Tumbleweed has been reverted to the previous safe one (20241212). It is now safe to install or update neomutt. Updating ======== Take note of the neomutt version you have currently installed: $ rpm -q neomutt neomutt-20241212-1.2.x86_64 If you had applied any locks to the neomutt packages, it is now safe to remove them: $ sudo zypper removelock neomutt neomutt-doc neomutt-lang You can now update your system, forcing a refresh to guarantee getting the newly reverted version of neomutt: $ sudo zypper refresh --force $ sudo zypper dup If you still had the broken neomutt version 20250109 installed, zypper might warn you of the neomutt packages being downgraded. That is intended. After the update is completed, take note of the neomutt version: $ rpm -q neomutt neomutt-20241212-2.1.x86_64 NOTE: this version number (20241212-2.1) is greater than the previous one (20241212-1.2). This is intended. If you see any other neomutt version than this one, something has gone wrong. Analysis and Next steps ======================= This bug [0] was introduced upstream in version 20250109, and promptly noticed and fixed in version 20250113. A bug like this one is uncharacteristic of neomutt, at least I don't remember something like this. I had just submitted version 20250109 to Factory when version 20250113 was released. Since the release notes of version 20250113 did not mention the bug, I did not realise there was an urgent problem to deal with. By the time I got around to submitting version 20250113, enough time had passed to let version 20250109 arrive in Tumbleweed. At that point, realising there could still be other minor issues in version 20250113 [1], I decided it was better to revert neomutt to the previous version 20241212 instead of going forward. From here on you know the rest. I will now evaluate future neomutt releases much closer, before submitting them to Factory. Although I would not have spotted the bug myself, I could have noticed the bug report on Github had I waited a bit before submitting. I am considering now letting a few more days pass between new release and submission, waiting for any major bugs like this one to be discovered by others. I am aware this is contrary to the point of a rolling release. If you have a better plan, feel free to get in touch. Acknowledgements ================ Thank you to upstream contributor luchr and upstream author flatcap for noticing and promptly fixing the bug. Also thank you to the openSUSE contributors (Ana in particular) who helped me resolve this incident. Sorry again for the trouble, Filippo [0] https://github.com/neomutt/neomutt/issues/4541 [1] https://github.com/neomutt/neomutt/issues/4539 -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On Tue, Jan 21, 2025 at 12:02:13PM +0100, Pit Suetterlin via openSUSE Factory wrote:
NOTE: I am not the mutt maintainer, perhaps they can weigh in as well. I think mutt is completely unaffected. The bug happened on the bleeding edge of neomutt releases, which happen in [0] completely independent of mutt [1]. A cursory look in the mutt package changelog [2] can confirm that this bug has had no time or way to reach whatever form of packaging our mutt package uses. [0] https://github.com/neomutt/neomutt [1] https://gitlab.com/muttmua/mutt [2] https://build.opensuse.org/projects/openSUSE:Factory/packages/mutt/files/mut... -- Filippo Bonazzi Security Engineer suse.com 8257 4398 947A 2DBE F21D 76E6 937A 63F0 5B36 46D9
On 2025/01/21 13:14:32 +0100, Filippo Bonazzi wrote:
You missed this one [3] https://gitlab.com/muttmua/mutt/-/issues/490 looks like upstream does not agree with the reports -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
participants (3)
-
Dr. Werner Fink -
Filippo Bonazzi -
Pit Suetterlin