"Mikhail T." <m...@aldan.algebra.com> writes: > On 28.03.20 20:47, Jan Beich wrote: > >> Lack of the homework. > > I really don't understand this, Jan... Let's replay: > > 1. I wanted to install Seamonkey on a system I'm dressing up, and > found, that the port is no longer available. > 2. I looked for the final commit-message, and found: > 1. it was deleted by you, last year; > 2. it was deleted for lack of updates.
3. It was deleted due to being perma-vulnerable. 4. It was deleted because of crashes on amd64 when built by Clang 8. 5. It was deleted because it blocked bsd.gecko.mk cleanup. > 3. So, I looked at the upstream's site, and found, that they've made > several releases since then, most recent -- last month. 2.49.5 was released too late while 2.53.1 was vulnerable since release. 2.53.1 is based on ESR60 which is no longer supported by bsd.gecko.mk. https://svnweb.freebsd.org/changeset/ports/511274 > 4. I then wrote you an e-mail inquiring, if the port can be restored... Did you try to build 2.53.1 before writing the email? > Do the 2. and the 3. not qualify as "homework"? What more should I > have done before approaching you for comment? Work with upstream to fix FreeBSD-specific regressions e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1437670 >> Patches do the talking better. > So, you're angry at me for not doing the work, which you're trying to > dissuade me from doing in the first place? If you don't use bsd.gecko.mk then the revived www/seamonkey wouldn't complicate maintenance of www/firefox + mail/thunderbird. And having a separate maintainer would keep the port under care of a specific person instead of dumping the work on a non-functional team at first opportunity. >> 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. > > So, your earlier statement about it still being vulnerable is not > based on any such research, and cannot be substantiated?.. I'm not a security researcher and don't have access to restricted bugs. Here're a few candidates from a cursory look: - https://hg.mozilla.org/releases/mozilla-release/rev/e50b821c8747 is part of CVE-2020-6800 which applies as is to SeaMonkey 2.53.1. - https://hg.mozilla.org/releases/mozilla-release/rev/c7545f9cfe8f is part of CVE-2020-6798 which needs minor rebase to apply to SeaMonkey 2.53.1. - https://hg.mozilla.org/releases/mozilla-release/rev/23240642f474 is part of CVE-2019-20503 which needs minor rebase to apply to SeaMonkey 2.53.1. - https://hg.mozilla.org/releases/mozilla-release/rev/90e3d7f045bd is part of CVE-2020-6814 which needs minor rebase to apply to SeaMonkey 2.53.1. Thanks to https://wiki.mozilla.org/Security/Bug_Approval_Process obfuscation not all fixes for CVEs are easy to find. _______________________________________________ freebsd-gecko@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"