Further Pale Moon packaging questions on NixOS

[OPNA2608]

Hey, apologies for opening another thread but I got too busy after opening the initial one (viewtopic.php?f=37&t=23015&p=175631) and it's now locked. I have more free time now, and more questions regarding our packaging efforts for Nixpkgs.

The build configuration looks perfectly fine for official branding.

Thanks for the confirmation. I've been keeping up with updating our Pale Moon build as much as possible, however while debugging another project I was reminded that Nixpkgs enforces alot of hardening compiler switches by default. Our C/C++ compiler is a wrapper that automatically adds a variety of hardening-related flags. Here's our manual page about this hardening policy: https://nixos.org/nixpkgs/manual/#sec-h ... in-nixpkgs

In cleartext, this adds the following compiler flags to any compilation (from what I can tell so far):

Code: Select all

-Wformat -Wformat-security -Werror=format-security -fstack-protector-strong --param ssp-buffer-size=4 -O2 -D_FORTIFY_SOURCE=2 -fPIC -Wstrict-overflow -z relro -z bindnow -fPIE -pie

If any of this constitutes to a build configuration that can not be considered official, please let me know which (if not all) switches are troublesome and I'll disable the corresponding hardening options. Just making sure our build is as good with you as can be.


Additionally, I've been looking into packaging the official build tarballs for Nixpkgs, like we've done with Firefox. I'm very concerned about following the licensing restrictions, so I wanted to check whether the following situation & solutions would seem problematic to you before I push anything upstream (I have a patched build that seemingly runs about as well as our source builds rn):

Unpacking Pale Moon straight from the package supplied from the website will, under absolutely no circumstances, run on our main distribution NixOS without any changes to the binary itself. Since our filesystem does not follow the common Linux FHS, all the binaries' linker references will at the very least need to be patched via patchelf.

Code: Select all

patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" $out/lib/palemoon-bin-${version}/"$exe"

Additionally, the binaries and libraries will not be able to find a majority of their library dependencies and need either a wrapper script to fix the LD_LIBRARY_PATH or extensions to their rpaths via patchelf (for which an automatic patchelf hook would be used). Also, the built-in update manager as described in the manual installation instructions will never work for users due to all package data getting "frozen" by the package manager post-installation, never to be modified again at any point.

Due to the package being flagged as unfree, these modifications would not be performed and further distributed by us directly; the users' package manager will, if requested, download the official tarballs and run these modifications according to our "recipe". As for the updater, our Firefox wrapper writes a preference JSON file and links it into the Firefox package tree:

Code: Select all

policies = {
    DisableAppUpdate = true;
  };

policiesJson = writeText "no-update-firefox-policy.json" (builtins.toJSON { inherit policies; });

[…]

# See: https://github.com/mozilla/policy-templates/blob/master/README.md
mkdir -p "$out/lib/firefox-bin-${version}/distribution";
ln -s ${policiesJson} "$out/lib/firefox-bin-${version}/distribution/policies.json";

I don't know if there's a similar mechanism for the Pale Moon tarball, let alone if that would be in violation of Pale Moon's redistribution license.


Thanks for reading through all that, hope you can help me with my questions. Cheers.

[stevenpusser]

Since Debian's and Ubuntu's debhelper also automatically passes some hardening flags to Pale Moon's builds, I also hope that is fine with the developers, though I can't imagine them really having any issues with hardening a browser!

[Moonchild]

Since Debian's and Ubuntu's debhelper also automatically passes some hardening flags to Pale Moon's builds, I also hope that is fine with the developers, though I can't imagine them really having any issues with hardening a browser!

We don't, but it should be properly stability-tested if you are using aggressive hardening flags as it's no longer just a matter of "packaging" anymore in that case.

[OPNA2608]

We don't, but it should be properly stability-tested if you are using aggressive hardening flags as it's no longer just a matter of "packaging" anymore in that case.

FWIW I've been running with these flags for almost a year without any problems that couldn't be linked to already reported bugs. Nowhere near a proper stability test of course.

Are any of these hardening flags too aggressive for you?

[adesh]

I think he has pretty much already answered your question. If the browser has been stable enough in daily use for normal browsing over a sufficiently long period of time by enough people, and without peculiar bugs, then "stability test" is passed and it doesn't matter which hardening flags you use.