All good points, but I do think there is merit in having a separate port 
for LibreWolf.

The existing FireFox port is quite conservative about how it patches 
Firefox, for OpenBSD-specific requirements. Look more carefully at 
LibreWolf. They have hundreds of patches for Firefox, that they maintain 
per release.

In my experience, they're pretty good about syncing with Mozilla, often 
providing new LibreWolf releases on the same day as each FireFox release.

I think it makes sense to have the relatively vanilla FireFox port in 
its current form, alongside a LibreWolf port. I'll have more work done 
on the port after the OpenBSD 7.9 release, such as:

* Further consolidate the port, such that FireFox and LibreWolf both use 
a common module, that I will add: www/mozilla-browser - then both ports 
would more or less just have the same Makefile, with a few tweaks, but 
both Makefiles would be smaller. Like how you have www/mozilla with lots 
of common config. www/mozilla-browser will just be a common module 
specifically for browsers, still piggybacking off of common www/mozilla

* Remove use of the mozconfig-based bootstrap in LibreWolf, and patch 
using CONFIGURE_ARGS and co, as in FireFox. This will mean that the 
Makefile is relatively in sync with FireFox

* After these two are done, it's quite possible that I could perhaps 
make LibreWolf a *flavour* instead, of the firefox port?

There is already precedent for forks in OpenBSD, e.g. see www/tor-browser

I haven't done these yet, plus there's been one or two new LibreWolf 
releases. I'm not in any rush until after OpenBSD 7.9 is out, since 
ports tree is  locked until then anyway. A few patches and I can have 
the above done in a day (including time taken for compiling, which is a 
lot, on my machine).

But no, I disagree entirely with your fundamental point. Replicating 
LibreWolf's modifications to FireFox would mean adding literally 
handleds of patches. These patches from LibreWolf are Git patches, which 
would be way more patches in OpenBSD which does not allow specifying 
multiple files to change within the same diff file, when patching 
sources, so your proposal would actually result in a much messier 
FireFox port.

Look at the source repo for LibreWolf, from git, and you'll see all the 
patching plus bootstrapping they do. What I use in my OpenBSD port is 
the resulting tarball generated from their bootstap. The LibreWolf 
tarball is, for all intents and purposes, a drop-in that replaces the 
Firefox tarball, and can be used in more or less the same way, but I 
believe OpenBSD should regard it as a separate browser, hence this port.


Am 07.05.26 um 23:57 schrieb Volker Schlecht:
> On 4/24/26 12:06 PM, Leah Rowe wrote:
>
>> New update: I updated the port to use LibreWolf 150.0-1 which 
>> recently came out, mirroring the recent FireFox 150 update in OpenBSD 
>> -current
>
> [...]
>
>> With these changes, the versioning and configuration is now much 
>> closer to OpenBSD's FireFox port. 
>
> I absolutely second that. Bumping the port to 150.0.2 was a 
> no-brainer, too.
> Stellar work on the port (imho, fwiw etc)!
>
> However there is something I find worth pointing out ...
>
>> It should be noted that LibreWolf still adds several more hardening 
>> options versus FireFox, including in this port. I would say that an 
>> OpenBSD user, who likely wants the best security, will find this 
>> LibreWolf port very useful.
> I didn't look in depth at *all* the patches, but I needed to look a 
> while to
> find something that isn't all about rebranding Firefox as Librewolf.
>
> Particularly the "Security" section of 
> https://librewolf.net/docs/features/
> seems to boil down to an opinionated set of default settings:
>
> * Stay up to date with upstream Firefox releases, in order to timely 
> apply
> security patches.
>
> They can't be faster than upstream, can they? So if you use Firefox 
> you'll have
> those patches faster. Add to that the inevitable delay until the port 
> is updated
> and packaged, and Librewolf on OpenBSD quickly turns out to be the 
> worst option of all.
>
> * Always force user interaction when deciding the download location of 
> a file.
>
> It's ~/Downloads on OpenBSD, why would we bother deciding all the time?
> unveil(2) and a patch in the port makes that quite pointless.
>
> * Enable HTTPS-only mode.
>
> /** [SECTION] HTTPS */
> https://codeberg.org/librewolf/settings/src/commit/aaed53fbdde76d4d3732a3a4a0d9f5254d557262/librewolf.cfg#L115 
>
>
> * Enable stricter negotiation rules for TLS/SSL.
> * Revert user-triggered TLS downgrades at the end of each session.
>
> /** [SECTION] TLS/SSL */
> https://codeberg.org/librewolf/settings/src/commit/aaed53fbdde76d4d3732a3a4a0d9f5254d557262/librewolf.cfg#L287 
>
>
> * Disable scripting in the built in pdf reader.
> * Protect against IDN homograph attack.
> https://codeberg.org/librewolf/settings/src/commit/aaed53fbdde76d4d3732a3a4a0d9f5254d557262/librewolf.cfg#L323 
>
>
> * Implement optional extension firewall, which can be enabled manually.
>
> /** [SECTION] EXTENSION FIREWALL
>  * the firewall can be enabled with the below prefs, but it is not a 
> sane default:
> [...]
>  */
>
> ... disabled and not a sane default. Some security feature.
>
> * Set OCSP to hard-fail in case a certain CA cannot be reached.
>
> https://codeberg.org/librewolf/settings/src/commit/aaed53fbdde76d4d3732a3a4a0d9f5254d557262/librewolf.cfg#L260 
>
>
>
> And that's it. All the "hardening" can be achieved on a stock OpenBSD 
> Firefox
> with a few settings. Is that really worth a fork and a port, or 
> shouldn't we rather discuss the pros and cons of adding some of these to
>
> https://cvsweb.openbsd.org/checkout/ports/www/mozilla-firefox/files/all-openbsd.js,v?rev=1.14 
>
>
> ?

-- 
Company director, Minifree Ltd
Registered in England, No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK

• OpenPGP_0x5C654067D383B1FF.asc (3K)