pop-os / packaging-thunderbird

Debian packaging of Mozilla Thunderbird
0 stars 0 forks source link

Maintaining Thunderbird on PopOS 22.04? #8

Closed NathanaelA closed 1 month ago

NathanaelA commented 1 month ago

I'm wondering if you plan on actually maintaining this, or if this was a one time release on 22.04?

According to the thunderbird website, there have been 6 releases since this was released and it is now on 128.2.3esr -- It would be nice if this was maintained, but at this point if you aren't planning on doing it -- it might be better to recommend people use the FlatPak version...

mmstick commented 1 month ago

We are still maintaining this. Ubuntu 22.04 is still on 115

NathanaelA commented 1 month ago

Your comment is unfortunately incorrect in the ways that actually matter --

image

The current released version according to apt info thunderbird is Version: 2:128.0.1esr~1723762298~22.04~fd196ef from the APT-Sources: http://apt.pop-os.org/release jammy/main amd64 Packages

Yes 115 is base Ubuntu 22.04, but those on Pop will have ended up upgraded to 128.0.1...

The problem is the version 128 that was pushed to your POP 22.04 override repo is now 6 versions (& 3 months) out of date on the 128 branch which is:


If PopOS isn't planning on maintaining the 22.04 Thunderbird branch, you might want to remove it (or redirect to the FlatPak version which is maintained) so others don't get stuck with a dead end in-secure and buggy version.

mmstick commented 1 month ago

As mentioned above, Ubuntu 22.04 is still on 115, which is even older than 128. We are still maintaining this.

NathanaelA commented 1 month ago

@mmstick - Uhm, one of us must be confused... :grinning:

Here are the facts as I know them, you can tell me where I'm wrong...

  1. Thunderbird is currently on 128.2.3esr
  2. Ubuntu is showing 115.15.0 and 91.8 as versions they are maintaining and their repos are 500 priority
  3. PopOS 22.04 is showing 128.0.1esr as the latest/current release and PopOS repos are pinned at 1001

Doing an apt get thunderbird (or uprade, like I did in August) will give us the version from Pop-OS repo since it is considered the highest priority repo , giving us 128.0.1 -- so what Ubuntu is maintaining is actually immaterial to this issue.

If you are maintaining this for Jammy 22.04, then why is Thunderbird 6 versions out of date?

m4rc77 commented 4 weeks ago

@NathanaelA I created a separate Ticket due to CVE-2024-9680 have a look at https://github.com/pop-os/packaging-thunderbird/issues/9

NathanaelA commented 4 weeks ago

@m4rc77 - I just switched to the flatpak version, I still had no answer on if System76 was going to maintain it (looks like they aren't -- as it is still 128.0.1esr as of today, which is about a month after my initial post). I wasn't willing to continue with the serious issues I had with their super buggy (crashed multiple times a day) 128.0.1esr that PopOS put up months ago.

It was a pain to figure out where Flatpak expected my profile to be, but once I figured it out, I eliminate having to deal with PopOS's on this package since they are unreliable for apparently Mozilla based products. The Flatpak version is maintained by Mozilla and is already on 128.3.2esr (which is now 9 versions past what is on the PopOS Apt repo).

leviport commented 4 weeks ago

looks like they aren't

There's a PR opened. It's linked to #9.

jacobgkau commented 4 weeks ago

We currently have several members of the team subscribed to a mailing list so we're notified every time a Firefox update is available. Perhaps we need to do the same for Thunderbird now?

That said, using the Flatpak is a fine solution for anyone who's good with that. I almost wonder if we should just try to include that as default somehow in 24.04, although I think we try to have everything .deb by default (and we apparently want a default mail client), and having that installed automatically in user-mode would be difficult.

jacobgkau commented 4 weeks ago

The "Mozilla announce" mailing list that we use for Firefox does not include any Thunderbird stuff: https://groups.google.com/a/mozilla.org/g/announce

Unlike the Firefox release notes page, the Thunderbird release notes page does include an RSS feed, though: https://www.thunderbird.net/en-US/thunderbird/releases/atom.xml

jacobgkau commented 4 weeks ago

For the time being, I've subscribed to the Thunderbird release RSS feed via e-mail using https://blogtrottr.com/, which polls every hour for free. @leviport Do you want to do the same, and we can handle this like we do for Firefox? update.sh should work the same way.

(An alternative RSS-to-email service is https://feedrabbit.com/, and it polls every three hours for free accounts.)

leviport commented 4 weeks ago

Subscribed. Thanks for hunting down that RSS!

NathanaelA commented 4 weeks ago

looks like they aren't

There's a PR opened. It's linked to #9.

@leviport -- I'm glad that the PopOS team is FINALLY deciding after a 9.8 CVE is released to finally push a release!

In all reality the PopOS team totally screwed up here and needs to do better in the future. If a developer points out why (not) doing X is going to create a security issue (like I did ~3 weeks ago above: https://github.com/pop-os/packaging-thunderbird/issues/8#issuecomment-2369187726). The PopOS team REALLY need to take it seriously, not blow them off (& close the issue) until an critical CVE is released.

The team needs to take this to heart -- they were warned that with Thunderbird not being maintained on the 22.04 branch and that by pushing their own unmaintained 128.0.1esr that they were directly introducing their users to future security issues. I didn't need a crystal ball, it is trivially easy to know that ALL Browsers (which Thunderbird is one) MUST be maintained more rigorously then any other piece of software on a machine, yet here we are with virtually ALL your PopOS 22.04 users being vulnerable to a 9.8 CVE via Thunderbird when the base Ubuntu is NOT!

SO PLEASE DO BETTER in the future, and don't ignore people who inform you that your team is CREATING a future security issue. I'm not sure the best solution, but what comes to my mind is perhaps implement that in the future if a team member, like mmstick, has no idea, and the reporter claims a "potential" security issue then have the process be that they raise the ticket with someone who actually has some "security" expertise to actually verify/validate it before closing. (i.e. Security issue claimed by anyone on ANY PopOS repo == a PopOS security guy must look at it before it is closed).

Please note, I am not trying to harass anyone, I need the PopOS team to do better, because I use PopOS, and I recommend it to lots of people. So, PLEASE firmly look at your process, and fix it so something trivially avoidable like this can't happen again. :wink:

NathanaelA commented 4 weeks ago

That said, using the Flatpak is a fine solution for anyone who's good with that. I almost wonder if we should just try to include that as default somehow in 24.04, although I think we try to have everything .deb by default (and we apparently want a default mail client), and having that installed automatically in user-mode would be difficult.

@jacobgkau -

I personally prefer .deb, but in this case (and maybe FireFox also) it would be much better to let Mozilla do all the packaging and maintenance of them, and bow out of the loop. Less things you have to worry about, espcially security issue prone software, seems like the best idea to just let Mozilla handle it.

I'm not sure why would a flatpak be difficult to do in user-mode? (But I'm not a flatpak expert, so this is more a question of curiosity) If flatpak is installed, then shouldn't thunderbird be installable at install time (assuming you ship the required flatpak dependencies), right?

mmstick commented 4 weeks ago

@NathanaelA You were not the one who reported a security vulnerability. I created the PR within minutes after someone actually reported a security issue here, linking to a CVE report created only a few days ago. I did not close their issue. So as I told you before, we are maintaining this repository.

jacobgkau commented 4 weeks ago

I'm not sure why would a flatpak be difficult to do in user-mode?

User-mode installations need to be run as the user. If you create a second account and switch over to that one, it would not have the app installed unless some script or something was set up to automatically run a flatpak installation command as that user on first login, which is hacky and not something infrastructure is in place for. That's why user-mode flatpaks being installed by default would be difficult.

I personally prefer .deb, but in this case (and maybe FireFox also) it would be much better to let Mozilla do all the packaging and maintenance of them, and bow out of the loop.

Mozilla's Firefox packaging contains several things we explicitly do not want, such as recommended editorials and advertisements on the New Tab page. In the past, we have also needed to apply changes to Firefox to get things like graphics-accelerated media working properly on our hardware/drivers, and having updates bypass our QA process for something as integral as the default web browser is not likely to be a net benefit for users. That said, we typically update Firefox within one business day of when Mozilla sends out a release announcement, which you can see here has been working fine for a long time: https://github.com/pop-os/packaging-firefox

Michael is perfectly well-versed in security issues, and there is not a dedicated "security guy" at System76 to "escalate" this to, as it's everyone's responsibility to be in on it. Like he said, we had a PR open and QA'd the same day someone reported an actual security issue, and I'll make sure that gets an engineering +2 and is walked through the release process during the business day tomorrow. Like I said, those of us who maintain Firefox are now signed up to get release notifications for Thunderbird (you can ask Mozilla why they don't announce Thunderbird releases on their Mozilla release announcement mailing list). The process has been improved now; thank you for the feedback.

I think part of Michael's confusion before when you were comparing Ubuntu's 115 version with our 128 version is that Michael was under the impression Ubuntu's 115.x release was actually older than ours (and hence, took that as a signal that Canonical was not concerned about being on a release older than ours from a security standpoint) when in reality, 115 is an extended-support release channel similar to 128, and Ubuntu's current 115.16.0 version was actually updated as recently as last week (although it, too, is already two versions behind according to the Thunderbird release log). You didn't quite articulate how Ubuntu's version with a lower version number was newer than ours, but I can see where the communication disconnect happened since that would be fairly obvious to someone who already knows how the channels work.

NathanaelA commented 4 weeks ago

Thank @jacobgkau - that makes sense on why you maintain FireFox and why flatpak might not work for Thunderbird as the default install. Thanks for filling me in, I appreciate it!

Jacob: "Michael is perfectly well-versed in security issues, and there is not a dedicated "security guy" at System76 to "escalate" this to, as it's everyone's responsibility to be in on it. Like he said, we had a PR open and QA'd the same day someone reported an actual security issue, and I'll make sure that gets an engineering +2 and is walked through the release process during the business day tomorrow."

I appreciate that you are going to get it patched, and I assume based on the messages above that Levi is now monitoring Thunderbird RSS feed and so it will actually be maintained going forward. I do find it interesting that you don't have a goto security guy as I would figure you would have someone watching the entire eco-system security posture and monitoring all the security related lists to catch things like this. This is a significant security issue, that PopOS created in their eco-system by not maintaining 128, and the only reason you know about is because a random (Thanks Marc) guy was kind enough to track down where to report it 7 days later...

Since you don't have a goto security guy, then perhaps a process could be a second senior person should look at any issue where a end user is claiming ANY potential security issue. That would be a good way forward to make sure things like this issue isn't erroneously closed and avoid something like this major security snafu that should have been trivially avoidable in the future?


However, as much as I hate beating this issue, someone on the PopOS team who really understands what I am saying here really needs to talk to Michael about his erroneous comment (which was just before yours Jacob, and I quoted the relevant part below for the context):

Michael: "So as I told you before, we are maintaining this repository."

Michael is again wrongly trying to defend that PopOS 22.04 version has been maintaining Thunderbird, and he needs to realize it before he creates another security issue with some other package that PopOS is controlling! People are human, and we all make mistakes!!! :grinning: I have no issue with anyone who learns from their mistakes...

Being super blunt here and I'm not going to sugar coat this in the slightest -- Michael closing and dismissing this issue because he somehow believed that a distro abandoning a browser they are controlling (which Thunderbird is) for over 3 months still can be "claimed" as "maintained" is exactly what has created the final piece of this major security issue. Ubuntu had this fixed on day 1, Flatpak was fixed on day 1. Those are what are considered as maintained packages! Had the UNMAINTAINED 128.0.1esr never been pushed by the PopOS team, ALL the users in the PopOS 22.04 ecosystem would have been protected by one of those two actively maintained versions of Thunderbird packages!

This is CRITICAL to understand what is maintained and what isn't, especially for any distro controlled package!

I want you to really seriously think about these facts:

  1. This 9.8 CVE, is a full remote execution that does NOT apparently require any user interaction, and has been in the wild since apparently BEFORE the patch. An remote 9.8 CVE is a MASSIVE security vulnerability and it happens to be against what is now the default installed email client for PopOS 22.04.
  2. Over 20 (yes, TWENTY) rated High (many also with CVE's) are also currently present in 128.0.1 and many have been exploitable now for well over 90 days on PopOS 22.04!
  3. It was completely self inflicted by the PopOS team (PopOs choose to push 128.0.1esr, overwriting the Ubuntu maintained 115.x)
  4. This issue, including the facts about 128 now being multiple versions out of date was then completely IGNORED, and CLOSED by Michael.
  5. The ONLY reason it is finally being patched NOW by the PopOS team is because an END USER reported this CVE to them. It was reported to PopOS SEVEN days after upstream patched and released the fix.
  6. The entire PopOS eco-system would STILL be trivally compromisable (who knows exactly how long more!) without that end user choosing to track down where to report this issue and then actually reporting it here.

Really think about point 6, and then think about point 2. Only by PURE LUCK that a user reported this CVE 7 days later, is ANY of the issues, including it, being actually finally fixed. Go ahead read point 2 & 6 again... Do you see the much bigger security picture now?

If you are going to actually actively maintain a package (especially a browser), you actually have to maintain it by releasing every single security update! You cannot ignore any project (let alone a browser) for any significant time frame. You for sure cannot be skipping multiple security patches and CVE's and decide its all right to just be waiting for some random end user to inform you that you dropped the security ball again on a package your distro overrode.

So in summary after your team has been ignoring ALL security updates now for over 3+ months on a browser based product and you now have multiple vulnerabilities your team just let be exploitable for that entire time. Had a user NOT reported the 9.8 CVE today, it would have been exploitable for who knows how much longer (it will already be 8 days longer than upstream by the time PopOS has released it).

Michael, do you really want continue to state that this repo was being maintained for the last 3+ months for Pop 22.04?

Mistakes happen by ALL of us, learn from them, then move forward, never ever double down on them...


Again, I am super happy that the PopOS appears like they will now (as of today) actually be maintaining Thunderbird 128 on PopOS 22.04 going forward for all the deb users. I really hope you understand why I have been a bit hard nosed here. Either security is important to PopOS, or it isn't. Sloughing off security isn't any way for any distro to maintain any package they are now fully controlling. It also should never be considered an even remotely valid security posture of any distro to abandon any updates for any browser for over a month, let alone to abandon them for over three months on a package they have chosen to control. :wink: