Date: Fri, 27 Mar 2020 21:57:19 -0400 From: "Mikhail T." <mi+t@aldan.algebra.com> To: Jan Beich <jbeich@FreeBSD.org> Cc: gecko@freebsd.org Subject: Re: Restoring seamonkey Message-ID: <9a797087-e769-3c50-3032-c71b41fab823@aldan.algebra.com> In-Reply-To: <wo75-5lf5-wny@FreeBSD.org> References: <857ef528-1dfd-12b6-6579-b03a137ff199@aldan.algebra.com> <wo75-5lf5-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... 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... > 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? 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... Thanks! Yours, -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9a797087-e769-3c50-3032-c71b41fab823>