Description of problem: Thunderbird 78 is be a major "breaking" upgrade: https://www.thunderbird.net/en-US/thunderbird/78.2.1/releasenotes/#changes We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." https://developer.thunderbird.net/add-ons/updating/tb78/changes Thunderbird > 68 has significant API changes. XUL has been completely removed for extensions, as well as numerous other breaking API changes, including to preferences and address books. Extensions are not expected to be compatible without significant effort. Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020: https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78/ Having rolled back my own system so that I can continue to use the SOGo extension, the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Given that downgrading is not trivial, can this update be backed out ASAP?
I disagree with you. Thunderbird's update is not broken, it has no API/ABI breakages. Everything works just fine. Version 68.x is now EOL. It will no longer receive even security updates. All users must switch to 78.3.x branch as soon as possible. Fedora is a bleeding edge distribution. If you need a legacy version of any package, you can always build it in COPR. I want to use the most recent version. OpenPGP is now build-in into Thunderbird core. No third party addons required.
Considering this has already been updated in Fedora 32 (stable) as well as Fedora 31 (pending), I don't think this is viable to revert in Fedora 33.
the cat is out of the bag - thunderbird-78.3.1-1.fc32.x86_64 - over and out - enigmail is included
The issue isn't enigmail, it's the entire ecosystem of add-ons that are obsoleted by significant changes in Thunderbird > 68. Given the policy that package maintainers "must" avoid breaking API changes within a release, why was this released for Fedora 32?
because TB 68 is EOL - it's that simple it's not relevant how few days ago a last release happened when GKH releases the last 5.x kernel at the same moment you have "EOL" on the right side that means literally that no update ever will happen that means also in the last point release backported regressions will never get fixed EOL is end-of-life - period
This isn't the kernel. When a kernel is marked EOL, it doesn't see any additional upstream activity. That is not the case here. Additionally, consumers of the kernel often backport security fixes to EOL kernels, just as Fedora package maintainers often backport security fixes to packages as a "downstream" consumer. But that's the kernel, not sure why we're talking about it in the first place. This seems like it was really a no-win situation for the maintainer. Thunderbird's support policy seems ambiguous: "Unlike the Mozilla Firefox ESR, Thunderbird does not provide a separate ESR release. This is because the regular Thunderbird release is already an ESR release. It remains stable and on that major version for approximately one year."[0] The 68.x branch is still seeing updates[1] (that, ironically, disable updates to Thunderbird 78). Even worse, Thunderbird didn't seem to want to officially support updates to 78 couching their release notes with "Thunderbird version 78.0 is only offered as direct download from thunderbird.net and not as an upgrade from Thunderbird version 68 or earlier. A future release will provide updates from earlier versions."[2] While the caveat is gone with 78.2.2[3], I don't see any mention in the release notes of supporting updates. Extension developers seem to not be real on board with the update either. That being said, there are CVEs only marked as fixed in 78.X[4], and 68.X certainly doesn't seem to be seeing any kind of regular security fixes, and asking a maintainer to backport is a significant maintenance burden, and also not without risk of its own. I think in this kind of no-win situation, the needs of the many outweigh the needs of the few. Most people benefit from security fixes, only a few seem to have their settings broken. [0] - https://www.thunderbird.net/en-US/organizations/ [1] - https://www.thunderbird.net/en-US/thunderbird/68.12.1/releasenotes/ [2] - https://www.thunderbird.net/en-US/thunderbird/78.0/releasenotes/ [3] - https://www.thunderbird.net/en-US/thunderbird/78.2.2/releasenotes/ [4] - https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/
> This isn't the kernel i know > consumers of the kernel often backport security fixes to EOL kernels not on Fedora > not sure why we're talking about it in the first place i simply explained what EOL means given that on the mailing list people argued that there was a release for the old Thunderbird just 5 days ago > Thunderbird version 78.0 is only offered as direct download > A future release will provide updates from earlier versions and that is *now* the main reason was that the now intregrated Enigmail wasn't ready now it is > 68.X certainly doesn't seem to be seeing any kind of regular security fixes so what we are discussing here about something which is unaviodable? be happy that the Fedora maintainer didn't the same as with Firefox 47 where he had trhown *beta* releases onto Fedora users :-) > Extension developers seem to not be real on board with the update either because that fools either wait until the absolutely *must* and so we would have the same situation a year ago from now or have abandoned their extensions long ago without telling anyone
I don't think it's useful to argue this by anecdote or analogy. I believe the facts of the matter are: 1: Thunderbird 78 is a breaking change. Following the upgrade, a significant number of add-ons do not function. Simple desktop users may be unaffected by the update, but business users that sync calendars and contacts with groupware servers like SOGo may lose critical functionality. 2: Fedoras policies state that maintainers must avoid major updates and API changes "if at all possible". This change is without question a major update with API changes, so the only question is whether or not it was possible to avoid updating. I believe that this policy serves several purposes, including not breaking user applications and communicating significant changes in advance. This update breaks user applications without any notice. 3: There has only been one update in the 78 update channel since the last update in the 68 update channel, and the release notes indicate "In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts." 4: I've tested an existing install of Thunderbird on a Windows system. That installation auto-updated to version 68 and now reports "Thunderbird is up to date" and "You are currently on the release update channel". The vendor is not yet automatically upgrading TB 68 users to version 78. Based on those facts, I think that the upstream vendor manifestly does not believe that the fixes in 78.3 warrant breaking the application for users of 68 at this time. They *do* plan to automatically upgrade the application for those users, but haven't done so yet. If the upstream vendor doesn't believe that an upgrade is *required*, then it should be permissible for Fedora to push no update at this time, consistent with the upstream vendor's policy. I'm sympathetic to the view that this is a no-win situation, but I think Fedoras policies represent an agreement to communicate significant changes so that everyone has the opportunity to avoid unexpected breaking changes, and that didn't happen in this instance. If nothing else can be done, we should at least plan to do better the next time.
If you don't like 78, use 68 if you wish. 68 won't get any updates anyway (from upstream or any other side). If you ask maintainers to backport security fixes from 78 to 68 to keep 68 up to date, that's unreal. We don't even do that for RHEL for paying customers.
"I'm sympathetic to the view that this is a no-win situation, but I think Fedoras policies represent an agreement to communicate significant changes so that everyone has the opportunity to avoid unexpected breaking changes, and that didn't happen in this instance. If nothing else can be done, we should at least plan to do better the next time." Martin, this is certainly realistic, isn't it?
(In reply to Miro Hrončok from comment #10) > "I'm sympathetic to the view that this is a no-win situation, but I think > Fedoras policies represent an agreement to communicate significant changes > so that everyone has the opportunity to avoid unexpected breaking changes, > and that didn't happen in this instance. If nothing else can be done, we > should at least plan to do better the next time." > > Martin, this is certainly realistic, isn't it? Yes, you're absolutely right. There should be better communication from TB maintainers side about such radical changes next time. There's no doubt about it. But I believe this but asks to remove TB78 from Fedora 33 which is unreal. I'm not sure why did you opened this bug what do you want to achieve by it?
> Martin, this is certainly realistic, isn't it? he did, as said with Firefox 47 (the same breaking change) he threw a beta to the Fedora users for no good reason now there is a good reason and it don't matter if the upgrade happens today or in two weeks extension maintainers living under a stome for months won't wake up magically later
Thunderbird does not support downgrading. If you will downgrade a package via Epoch bump, you will break the profiles of users who have already installed this update. They will loose their settings and email. This is unacceptable at all. Also Thunderbird 68.x has reached its EOL and has at least 3 critical vulnerabilities with assigned CVE numbers. Forcing users to use the vulnerable version is a bad practice.
> I'm not sure why did you opened this bug what do you want to achieve by it? I wanted to continue the conversation about the problem. You are right that this BZ might not be the best place for that.
As the person who opened the bug, I want to clarify: I was not asking for change to be backported, that would certainly be unreasonable. I think the vendor *has* provided better communication about "radical" changes. They've been vocal about the API breaking changes, and clear that they are not currently upgrading existing users, but will soon. By opening the bug, I had hoped that the thunderbird 78 package would simply be removed from the updates repository, for several reasons. Primarily: Fedora 33 is currently in beta and I believe that policies require no major version changes with breaking API changes within a release, and surely during the beta period. Thunderbird 78.3 does have serveral fixes with assigned CVE numbers, but they are "moderate" risk, and the vendor notes that they are not exploitable while viewing email, and manifestly does not view them as a compelling reason to either upgrade users of 68, or to publish an update for that version. I am not monitoring other groupware vendors, but at least SOGo expects a new plugin very shortly: https://marc.info/?t=160097859300004&r=1&w=4 I'd like to further suggest that Fedora's code of conduct applies not only to how we treat each other, but to how we treat other developers as well. Rather than calling them "fools" who are "living under a stone", we should understand that they are actively working on adapting to a very significant change in Thunderbird, and the upstream Thunderbird maintainers are giving them time to make those changes by not automatically upgrading Thunderbird 68 users at this time. I'm happy to discuss this elsewhere. Please let me know where the discussion is moved, if possible.
(In reply to Gordon Messmer from comment #15) > As the person who opened the bug, I want to clarify: > > I was not asking for change to be backported, that would certainly be > unreasonable. > > By opening the bug, I had hoped that the thunderbird 78 package would simply > be removed from the updates repository, for several reasons. Primarily: > Fedora 33 is currently in beta and I believe that policies require no major > version changes with breaking API changes within a release, and surely > during the beta period. Unfortunately there are only two options here: 1) Stop updating TB on all releases and keep 68 line there. It has security implications. 2) Update TB on all Fedoras. That may break user experience. We took the second way and updated Fedora 32/31. We also have to update Fedora 33 to avoid profile breakage when users update from 32 to 33. That should not be shipped as 0day update as it may cause more confusion. I think it's better to ship F33 with the TB 78 as we have on 32/31. If we strictly keep a Fedora policy of "no major version changes and API changes within a release" we can't update TB in any release as well as we can't Firefox in any release.
It is possible to request and communicate policy exceptions.
(In reply to Miro Hrončok from comment #17) > It is possible to request and communicate policy exceptions. I'm for any improvement which helps users to bear with such issues.