Including and signing DLL files #2950

ltguillaume commented 2026年03月29日 21:07:53 +02:00

There are a couple of things related to DLL files in LW releases I've just found:

1. ✅ I saw that Firefox now also ships msvcp140_atomic_wait.dll in addition to msvcp140.dll, vcruntime140.dll and vcruntime140_1.dll. We should do the same.
2. ✅ The commit above doesn't yet address the next issue: the DLL source (https://github.com/abbodi1406/vcredist/releases) doesn't include ARM files, so our ARM release doesn't ship any of the files from (1) (see https://codeberg.org/librewolf/bsys6/actions/runs/105/jobs/3/attempt/1#jobstep-2-3266).
3. ✅ The setup file bundles the VC redist executable, which I don't think is needed if the necessary files are already bundled. Firefox doesn't bundle them, either.
4. ✅ For some reason, the executable nmhproxy.exe is not getting signed. Is this file added later on in the process for some reason, or does it come from a different location than is traversed by the line below?
   librewolf/bsys6 – src/build.sh

   Line 19 in librewolf/bsys6@aaa6e6d

   find "$SOURCE/obj-$MOZ_TARGET/dist/bin" -type f -name "*.exe" | while IFS= read -r file; do
5. ✅ Then there's the signing of the DLL files: Mozilla signs them all, but there's a subset that's already signed by Microsoft, so those shouldn't be touched. If ossign doesn't overwrite existing certificates, then we can just let it skip them, otherwise we should first check for every DLL if they're already signed (in https://codeberg.org/librewolf/bsys6/src/branch/master/src/build.sh), or put them in an array manually.

Signed by	EXE File
OSSign	desktop-launcher\desktop-launcher.exe
OSSign	uninstall\helper.exe
OSSign	librewolf.exe
x	nmhproxy.exe
OSSign	plugin-container.exe
OSSign	private_browsing.exe

Signed by	DLL File
x	gmp-clearkey0円.1\clearkey.dll
x	installation_dir_layout\versioned\InstallationDirLayout.dll
x	AccessibleMarshal.dll
Microsoft	CoreMessagingXP.dll
x	dxcompiler.dll
x	freebl3.dll
x	gkcodecs.dll
x	InstallationDirLayout.dll
x	lgpllibs.dll
x	libEGL.dll
x	libGLESv2.dll
Microsoft	marshal.dll
Microsoft	Microsoft.InputStateManager.dll
Microsoft	Microsoft.Internal.FrameworkUdk.dll
Microsoft	Microsoft.UI.Composition.OSSupport.dll
Microsoft	Microsoft.UI.Input.dll
Microsoft	Microsoft.UI.Windowing.Core.dll
Microsoft	Microsoft.UI.Windowing.dll
x	mozavcodec.dll
x	mozavutil.dll
x	mozglue.dll
x	mozinference.dll
Microsoft	msvcp140.dll
Microsoft	msvcp140_atomic_wait.dll
x	notificationserver.dll
x	nss3.dll
x	onnxruntime.dll
x	softokn3.dll
Microsoft	vcruntime140.dll
Microsoft	vcruntime140_1.dll
x	xul.dll

There are a couple of things related to DLL files in LW releases I've just found: 1. ✅ I saw that Firefox now also ships `msvcp140_atomic_wait.dll` in addition to `msvcp140.dll`, `vcruntime140.dll` and `vcruntime140_1.dll`. We should do the same. 1. ✅ The commit above doesn't yet address the next issue: the DLL source (https://github.com/abbodi1406/vcredist/releases) doesn't include ARM files, so our ARM release doesn't ship any of the files from (1) (see https://codeberg.org/librewolf/bsys6/actions/runs/105/jobs/3/attempt/1#jobstep-2-3266). 1. ✅ The setup file bundles the VC redist executable, which I don't think is needed if the necessary files are already bundled. Firefox doesn't bundle them, either. 1. ✅ For some reason, the executable `nmhproxy.exe` is not getting signed. Is this file added later on in the process for some reason, or does it come from a different location than is traversed by the line below? https://codeberg.org/librewolf/bsys6/src/commit/aaa6e6d41caf59bc0c47a3a1ce51bde67df2d93c/src/build.sh#L19 1. ✅ Then there's the signing of the DLL files: Mozilla signs them all, but there's a subset that's already signed by Microsoft, so those shouldn't be touched. If `ossign` doesn't overwrite existing certificates, then we can just let it skip them, otherwise we should first check for every DLL if they're already signed (in https://codeberg.org/librewolf/bsys6/src/branch/master/src/build.sh), or put them in an array manually. Signed by | EXE File --|-- OSSign | desktop-launcher\desktop-launcher.exe OSSign | uninstall\helper.exe OSSign | librewolf.exe x | nmhproxy.exe OSSign | plugin-container.exe OSSign | private_browsing.exe Signed by | DLL File --|-- x | gmp-clearkey0円.1\clearkey.dll x | installation_dir_layout\versioned\InstallationDirLayout.dll x | AccessibleMarshal.dll Microsoft | CoreMessagingXP.dll x | dxcompiler.dll x | freebl3.dll x | gkcodecs.dll x | InstallationDirLayout.dll x | lgpllibs.dll x | libEGL.dll x | libGLESv2.dll Microsoft | marshal.dll Microsoft | Microsoft.InputStateManager.dll Microsoft | Microsoft.Internal.FrameworkUdk.dll Microsoft | Microsoft.UI.Composition.OSSupport.dll Microsoft | Microsoft.UI.Input.dll Microsoft | Microsoft.UI.Windowing.Core.dll Microsoft | Microsoft.UI.Windowing.dll x | mozavcodec.dll x | mozavutil.dll x | mozglue.dll x | mozinference.dll Microsoft | msvcp140.dll Microsoft | msvcp140_atomic_wait.dll x | notificationserver.dll x | nss3.dll x | onnxruntime.dll x | softokn3.dll Microsoft | vcruntime140.dll Microsoft | vcruntime140_1.dll x | xul.dll

alyx161 commented 2026年03月29日 21:54:54 +02:00

Think that is a good idea!

[...] If ossign doesn't overwrite existing certificates, then we can just let it skip them [...]

Probably best to have a skip on our side in place in general, just to make sure that any changes in ossign don't accidentally make it sign the wrong files. Good chance that Defender and co will become suspicious if we accidentally ship re-signed Windows DLLs 😅

Think that is a good idea! > [...] If ossign doesn't overwrite existing certificates, then we can just let it skip them [...] Probably best to have a skip on our side in place in general, just to make sure that any changes in ossign don't accidentally make it sign the wrong files. Good chance that Defender and co will become suspicious if we accidentally ship re-signed Windows DLLs 😅

ltguillaume commented 2026年03月29日 22:15:29 +02:00

Probably best to have a skip on our side in place in general

That's absolutely true. To do such a check, we'd probably need a separate tool, or do it manually. It's late here, so for now I'll dump what I've found so far, we can check if it'll be useful later:

• https://trailofbits.github.io/winchecksec (Authenticode check currently unsupported on Linux)
• chktrust from Mono (seems overkill)
• Just looking for a string inside the DLLs

@alyx161 Any what's causing (3)? Is nmhproxy.exe outside of $SOURCE/obj-$MOZ_TARGET/dist/bin at that point or something?

>Probably best to have a skip on our side in place in general That's absolutely true. To do such a check, we'd probably need a separate tool, or do it manually. It's late here, so for now I'll dump what I've found so far, we can check if it'll be useful later: - https://trailofbits.github.io/winchecksec (Authenticode check currently unsupported on Linux) - `chktrust` from Mono (seems overkill) - Just looking for a string inside the DLLs @alyx161 Any what's causing (3)? Is `nmhproxy.exe` outside of `$SOURCE/obj-$MOZ_TARGET/dist/bin` at that point or something?

alyx161 commented 2026年03月29日 22:44:40 +02:00

Also a little confused about the nmhproxy issue.
Late here too, but have a long train ride tomorrow, will try to dig into that issue then 🙂

Also a little confused about the nmhproxy issue. Late here too, but have a long train ride tomorrow, will try to dig into that issue then 🙂

ltguillaume commented 2026年04月01日 21:13:36 +02:00

Okay, ossign is based on relic, so it has a verify [filename] command which neatly returns an errorlevel: 0 if signed (for files signed by ossign and by MS), 1 if not (correctly) signed.

So librewolf/bsys6#42 should work (as in, tested locally, needs testing in the build env).

It does not, however, address the issue of nmhproxy.exe not being signed for some reason. I looked into the logs and every executable, except for nmhproxy.exe is mentioned during the signing process.
It seems to be compiled into /root/.local/share/bsys6/work/librewolf-149.0-1/browser/app/nmhproxy/nmhproxy.exe
Signing is done later for every file inside /root/.local/share/bsys6/work/librewolf-149.0-1/obj-aarch64-pc-windows-msvc/dist/bin/.
I couldn't deduce from the log or find in our scripts if (and if so, why) nmhproxy.exe wouldn't be in that last directory at that moment.

Okay, `ossign` is based on [relic](https://github.com/sassoftware/relic), so it has a `verify [filename]` command which neatly returns an errorlevel: 0 if signed (for files signed by ossign and by MS), 1 if not (correctly) signed. So https://codeberg.org/librewolf/bsys6/pulls/42 _should_ work (as in, tested locally, needs testing in the build env). It does not, however, address the issue of `nmhproxy.exe` not being signed for some reason. I looked into the logs and every executable, except for `nmhproxy.exe` is mentioned during the signing process. It seems to be compiled into `/root/.local/share/bsys6/work/librewolf-149.0-1/browser/app/nmhproxy/nmhproxy.exe` Signing is done later for every file inside `/root/.local/share/bsys6/work/librewolf-149.0-1/obj-aarch64-pc-windows-msvc/dist/bin/`. I couldn't deduce from the log or find in our scripts if (and if so, why) `nmhproxy.exe` wouldn't be in that last directory at that moment.

ltguillaume commented 2026年04月03日 00:15:41 +02:00

@ltguillaume wrote in #2950 (comment):

Okay, ossign is based on relic, so it has a verify [filename] command which neatly returns an errorlevel: 0 if signed (for files signed by ossign and by MS), 1 if not (correctly) signed.

So, apparently, not quite: ossign teared most relic features out of their version. So we need to get relic(-client) for this to work.

To remedy nmhproxy.exe (and possibly some dll's) not being signed + ossign doing some sign work on at least 3 files in dist/bin that won't be in the eventual package anyway (certutil.exe, logalloc-replay.exe, pk12util.exe and possibly some dll's), in the sign branch (for now), I moved the procedure from build.sh to setup.sh, just before creating the installer. Then it leaves the cleanup to portable.sh, so the files can be re-used for packaging the portable zip.

So these are the changes: ltguillaume/librewolf-bsys6@91de020376
...with a small fix: ltguillaume/librewolf-bsys6@a6c6002580

I'm just not sure what you think about bringing in the pre-compiled relic-client binary (even though it's what ossign is based on).

@ltguillaume wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12533544: > Okay, `ossign` is based on [relic](https://github.com/sassoftware/relic), so it has a `verify [filename]` command which neatly returns an errorlevel: 0 if signed (for files signed by ossign and by MS), 1 if not (correctly) signed. So, apparently, not quite: ossign teared most relic features out of their version. So we need to get relic(-client) for this to work. To remedy `nmhproxy.exe` (and possibly some dll's) not being signed + ossign doing some sign work on at least 3 files in `dist/bin` that won't be in the eventual package anyway (`certutil.exe`, `logalloc-replay.exe`, `pk12util.exe` and possibly some dll's), in the `sign` branch (for now), I moved the procedure from `build.sh` to `setup.sh`, just before creating the installer. Then it leaves the cleanup to `portable.sh`, so the files can be re-used for packaging the portable zip. So these are the changes: https://codeberg.org/ltguillaume/librewolf-bsys6/commit/91de0203762e5771a9b092765b5799410850843a ...with a small fix: https://codeberg.org/ltguillaume/librewolf-bsys6/commit/a6c6002580d9762e5ef132115575d24391c37efc I'm just not sure what you think about bringing in the pre-compiled relic-client binary (even though it's what ossign is based on).

ltguillaume commented 2026年04月04日 13:34:47 +02:00

@alyx161 @maltejur @ohfp So, with librewolf/bsys6#43 everything works (see https://codeberg.org/librewolf/bsys6/actions/runs/117/jobs/2/attempt/1), but it currently pulls in a binary of ossign's upstream project relic from GitHub for the verification checks (because ossign itself can't do that). I don't know how you all feel about that. Maybe it would be better to pin the version of the binary, extend download.sh to take a SHA256 to verify integrity, so we would know the binary hasn't been tampered with and/or host the file somewhere ourselves + download it at the very beginning, so it won't fail the job after 1.25 hours.

@alyx161 @maltejur @ohfp So, with https://codeberg.org/librewolf/bsys6/pulls/43 everything works (see https://codeberg.org/librewolf/bsys6/actions/runs/117/jobs/2/attempt/1), but it currently pulls in a binary of ossign's upstream project relic from GitHub for the verification checks (because ossign itself can't do that). I don't know how you all feel about that. Maybe it would be better to pin the version of the binary, extend `download.sh` to take a SHA256 to verify integrity, so we would know the binary hasn't been tampered with and/or host the file somewhere ourselves + download it at the very beginning, so it won't fail the job after 1.25 hours.

any1here commented 2026年04月04日 16:02:06 +02:00

@ltguillaume wrote in #2950 (comment):

and/or host the file somewhere ourselves

I would just compile it, throw it into the bsys6 repo and use it from there

@ltguillaume wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12645513: > and/or host the file somewhere ourselves I would just compile it, throw it into the bsys6 repo and use it from there

alyx161 commented 2026年04月04日 16:12:46 +02:00

Mh.. guess we should avoid binary blobs in the git repo.

But aside from this, I'm more wondering why ossign did a own thing over just using relic directly? 🤔

Mh.. guess we should avoid binary blobs in the git repo. But aside from this, I'm more wondering why ossign did a own thing over just using relic directly? 🤔

ltguillaume commented 2026年04月04日 16:19:41 +02:00

@alyx161 wrote in #2950 (comment):

Mh.. guess we should avoid binary blobs in the git repo.

True, I think it'd be better to fork to Codeberg and compile it ourselves, then pull it from there. Already running at https://codeberg.org/ltguillaume/relic/actions/runs/3/jobs/0/attempt/1. Will move it to librewolf org if it's all working.

But aside from this, I'm more wondering why ossign did a own thing over just using relic directly? 🤔

To hardcode all their secrets in the binary, of course 😉 But yeah, I was wondering the same thing.

@alyx161 wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12650304: > Mh.. guess we should avoid binary blobs in the git repo. True, I think it'd be better to fork to Codeberg and compile it ourselves, then pull it from there. Already running at https://codeberg.org/ltguillaume/relic/actions/runs/3/jobs/0/attempt/1. Will move it to librewolf org if it's all working. > But aside from this, I'm more wondering why ossign did a own thing over just using relic directly? :thinking: To hardcode all their secrets in the binary, of course 😉 But yeah, I was wondering the same thing.

alyx161 commented 2026年04月04日 16:23:58 +02:00

@ltguillaume wrote in #2950 (comment):

I think it'd be better to fork to Codeberg and compile it ourselves

Not sure of that isn't a little overkill either 😅
At the moment we just install the latest ossign package too.

If our goal is to improve on this, I guess its enough to just pin the version/signature.

@ltguillaume wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12650454: > I think it'd be better to fork to Codeberg and compile it ourselves Not sure of that isn't a little overkill either 😅 At the moment we just install the latest ossign package too. If our goal is to improve on this, I guess its enough to just pin the version/signature.

ltguillaume commented 2026年04月04日 16:49:00 +02:00

@alyx161 wrote in #2950 (comment):

If our goal is to improve on this, I guess its enough to just pin the version/signature.

librewolf/bsys6@!43 (commit 9fff561d73)

@alyx161 wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12650553: > If our goal is to improve on this, I guess its enough to just pin the version/signature. https://codeberg.org/librewolf/bsys6/pulls/43/commits/9fff561d735d06d1c60563e5fcec0eaf2d7ea2bf

any1here commented 2026年04月04日 21:40:48 +02:00

@alyx161 wrote in #2950 (comment):

binary blobs

But I like blobs :c

@alyx161 wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12650304: > binary blobs But I like blobs :c

alyx161 commented 2026年04月04日 21:47:10 +02:00

@any1here wrote in #2950 (comment):

@alyx161 wrote in #2950 (comment):

binary blobs

But I like blobs :c

Blobcats are allowed, but no binary blobs :3
says the non-binary person with the blobcat avatar

@any1here wrote in https://codeberg.org/librewolf/issues/issues/2950#issuecomment-12658215: > @alyx161 wrote in #2950 (comment): > > > binary blobs > > But I like blobs :c Blobcats are allowed, but no binary blobs :3 *says the non-binary person with the blobcat avatar*

ltguillaume commented 2026年04月04日 22:35:58 +02:00

Lolz 😬

Upside to having a new build is that it's built with the latest stable version of Go, while https://github.com/sassoftware/relic/releases/tag/v8.2.0 is from Jan 17, 2025 (and there have been quite a few security fixes for Go since then).

Lolz 😬 Upside to having a [new build](https://codeberg.org/ltguillaume/sassoftware-relic/releases/latest) is that it's built with the latest stable version of Go, while https://github.com/sassoftware/relic/releases/tag/v8.2.0 is from Jan 17, 2025 (and there have been quite a few security fixes for Go since then).

alyx161 commented 2026年04月04日 23:27:00 +02:00

Ignoring the go stuff, if a project has no changes for over a year I would classify it as unmaintained.
I'm not entirely sure if we should rely on unmaintained stuff? 🤔

Ignoring the go stuff, if a project has no changes for over a year I would classify it as unmaintained. I'm not entirely sure if we should rely on unmaintained stuff? 🤔

ltguillaume commented 2026年04月04日 23:39:29 +02:00

Does it matter if it just has to check if a certificate is already attached to a file? I'm still using a find-and-replace CLI tool that's from 2008 on my systems.

That said, it's probably not really very important what go version is used, considering we don't need it to do an entire chain verification for this (hence --no-trust-chain), thus it won't do any online lookups (revocation lists).

Does it matter if it just has to check if a certificate is already attached to a file? I'm still using a find-and-replace CLI tool that's from 2008 on my systems. That said, it's probably not really very important what go version is used, considering we don't need it to do an entire chain verification for this (hence `--no-trust-chain`), thus it won't do any online lookups (revocation lists).

alyx161 commented 2026年04月05日 01:03:06 +02:00

(削除) If you replace ossign with relic, its not checking for certs, its handling the signing and keys? (削除ここまで)

I should not do this at 1am 🥴

~~If you replace ossign with relic, its not checking for certs, its handling the signing and keys?~~ I should not do this at 1am 🥴

ltguillaume commented 2026年04月05日 19:35:20 +02:00

@any1here wrote a tool to do the check without the need of relic, very nice 😎 Works perfectly!

@any1here wrote a tool to do the check without the need of relic, very nice 😎 Works perfectly!

ltguillaume commented 2026年04月05日 23:20:04 +02:00

Merged. What remains:

1. ✅ The commit above doesn't yet address the next issue: the DLL source (https://github.com/abbodi1406/vcredist/releases) doesn't include ARM files, so our ARM release doesn't ship any of the files from (1) (see https://codeberg.org/librewolf/bsys6/actions/runs/105/jobs/3/attempt/1#jobstep-2-3266).

Pending review, this has been resolved via https://codeberg.org/librewolf/vc_redist, which extracts and packages (only) the necessary files straight from the belly of the beast. See librewolf/bsys6#45 for the necessary changes.

2. ✅ The setup file bundles the VC redist executable, which I don't think is needed if the necessary files are already bundled. Firefox doesn't bundle them, either.

I tested on a VM without the runtimes installed and Firefox doesn't try install them dynamically, either. Both FF and LW run without issues, so the 4 bundled libraries are really the only ones necessary. librewolf/bsys6#45 now includes a commit to remove the bundling of the vc_redist installer.

Merged. What remains: 1. ✅ The commit above doesn't yet address the next issue: the DLL source (https://github.com/abbodi1406/vcredist/releases) doesn't include ARM files, so our ARM release doesn't ship any of the files from (1) (see https://codeberg.org/librewolf/bsys6/actions/runs/105/jobs/3/attempt/1#jobstep-2-3266). Pending review, this has been resolved via https://codeberg.org/librewolf/vc_redist, which extracts and packages (only) the necessary files straight from the belly of the beast. See https://codeberg.org/librewolf/bsys6/pulls/45 for the necessary changes. 2. ✅ The setup file bundles the VC redist executable, which I don't think is needed if the necessary files are already bundled. Firefox doesn't bundle them, either. I tested on a VM without the runtimes installed and Firefox doesn't try install them dynamically, either. Both FF and LW run without issues, so the 4 bundled libraries are really the only ones necessary. https://codeberg.org/librewolf/bsys6/pulls/45 now includes a commit to remove the bundling of the vc_redist installer.