Date: Sun, 29 Mar 2020 01:47:42 +0100 From: Jan Beich <jbeich@FreeBSD.org> To: "Mikhail T." <mi+t@aldan.algebra.com> Cc: gecko@freebsd.org Subject: Re: Restoring seamonkey Message-ID: <4ku8-x9zl-wny@FreeBSD.org> References: <857ef528-1dfd-12b6-6579-b03a137ff199@aldan.algebra.com> <wo75-5lf5-wny@FreeBSD.org> <9a797087-e769-3c50-3032-c71b41fab823@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Mikhail T." <mi+t@aldan.algebra.com> writes: > On 27.03.20 21:15, Jan Beich wrote: > >> Good luck: >> - 2.53.1 is still vulnerable >> - Upstream has unstable release cadence >> - ESR60 engine may not build with new dependencies >> - Expecting someone else to do the work >> > What, I wonder, made you think, I am expecting someone else to do the > work? My question was quite agnostic of /who/ would do it, just > /whether /it can/should be done... Lack of the homework. Patches do the talking better. > > If the fresh (February) release is still vulnerable, then, perhaps, it > should stay buried... Can you give example of a still-open CVE? I'm > staring at the list here > <https://www.cvedetails.com/vulnerability-list.php?vendor_id=452&product_id=7048>, > but can't see, what's still open... According to SeaMonkey 2.53.1 release notes the engine was updated to Firefox 60.2ser with security fixes up to Firefox 72. Current version of Firefox is 74 while 75 is expected next week. Finding applicable vulnerabilities requires checking the code e.g., trying every fix against SeaMonkey tree but assuming some rebase churn. >> I'm only opposed on using Mk/bsd.gecko.mk and having gecko@ as the maintainer. > I understand the latter, but not the former. As long as gecko@ are not > responsible for it, what's wrong with still using bsd.gecko.mk? portmgr@ expects ports/ to not break ports maintained by others. Being forced to test and avoid breaking bsd.gecko.mk consumers that I don't maintain is exhausting. Besides, the file has been planned for removal for months/years due to unnecessarily complicating maintenance. See www/cliqz for an example of a Firefox fork that doesn't use bsd.gecko.mk. > That said, if we're sticking to firefox and thunderbird /only/, maybe > the two can be modified to share more components -- libxul.so in > particular, but also others?.. At least then, running both on the same > machine will still share the shared libraries saving RAM... libxul.so is no longer the same between various Gecko-based projects. Even back when XULrunner was supported API/ABI wasn't compatible between major releases.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ku8-x9zl-wny>