fix(nsis): embed signed copies of stock plugins, not unsigned system DLLs - #15422
Conversation
b2b24f5 to
bea3d5f
Compare
|
#14147 (comment) seems like the signing failed not that they were not included? |
|
@Legend-Master Thanks for taking a look. You're right that #14147 itself is an issue about signing failing, and that part was resolved by #14627. What this PR is targeting is a separate problem that's left over: #14627 made the signing step itself succeed, but those signed copies aren't on makensis' plugin search path, so as a result makensis falls back to the unsigned originals and embeds those instead.
|
Package Changes Through 8cf1e53There are 1 changes which include tauri-bundler with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
|
cc @lucasfernog since you wrote the change to use this environment variable in 37b4ca1, I can't seem to find any references of |
|
I can't find any either - https://github.com/search?q=org%3ANSIS-Dev+%22NSISPLUGINS%22&type=code |
|
Just leaving the verification steps here for reference (on macOS). Extract the plugin DLLs from a # extract plugin DLLs from setup.exe
7z x setup.exe -oextracted
# verify each DLL
for dll in extracted/\$PLUGINSDIR/*.dll; do
echo "=== $(basename "$dll") ==="
osslsigncode verify "$dll" 2>&1 | head -2
echo # blank line between entries
doneOutput: Only (NOTE: the |
Legend-Master
left a comment
Legend-Master
left a comment
There was a problem hiding this comment.
Awesome work, thanks! Really appreciate the detailed answers!
Just a bit of nitpicks and we can merge this one
…etry the vc_redist fetch (#7841) * Keep the signed NSIS plugin directory across a bundler upgrade, and retry the vc_redist fetch The template pointed at the signed plugin copy only through the NSISPLUGINS env var. tauri-apps/tauri#15422 removed that variable in bundler 2.9.3 and replaced it with signed_plugins_path, so upgrading the pinned CLI would have left the directive pointing at nothing. A missing plugin directory is a silent no-op in NSIS, so the four stock DLLs would have gone back to shipping unsigned with no build error. Carry both forms, and cover the wiring with a test that also pins the ordering, since !addplugindir after a plugin call either conflicts at compile time or loses to an already packed default. The vc_redist download was a bare Invoke-WebRequest against a Microsoft CDN that cut the response mid body twice in one day. Retry with backoff and reject a truncated or unsigned file, so a flake fails as itself rather than as a confusing installer exit code. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Check each plugin-directory form's position, not just the earliest Both ordering tests took the minimum !addplugindir line, which is always the env var form, so moving only the signed_plugins_path block below an include still passed. That is the one form bundler 2.9.3 and later actually resolves, so the tests would have gone green on a template that ships unsigned plugin DLLs. Parametrise over both forms and require each to precede every include and plugin call. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
3 participants
Summary
closes #14147
When an NSIS bundle is produced with
signCommandconfigured, the stock plugin DLLs (NSISdl.dll,StartMenu.dll,System.dll,nsDialogs.dll) unpacked into$PLUGINSDIRat install time end up unsigned. PR #14627 made the sign step itself run, but the signed local copies were never embedded into the resulting setup.exe.Root cause
When
signCommandis enabled, the bundler copies the system NSIS plugins to<output>/Plugins/x86-unicode/and signs them in place. However,installer.nsionly has an!addplugindirfor theadditional/subdirectory — nothing points makensis at the directory holding the signed stock plugins. makensis therefore falls back to${NSISDIR}/Plugins/<arch>/and embeds the unsigned originals.The signed local copies are never referenced by makensis, so the unsigned versions are what end up inside setup.exe.
Fix
installer.nsi: between!include "StrFunc.nsh"and${StrCase}, add an!addplugindirfor the signed plugin directory (gated on signing being enabled)mod.rs: expose the matchingsigned_plugins_pathtemplate variable only when signing is enabledAlso: drop the
NSISPLUGINSenv lineBefore launching makensis,
mod.rssetnsis_cmd.env("NSISPLUGINS", plugins_path), butNSISPLUGINSis not an environment variable that NSIS recognizes. Grepping the entireNSIS-Dev/nsissource tree and runninggh search code --owner NSIS-Dev 'NSISPLUGINS'both return zero hits — the line was a complete no-op.The intent was presumably to communicate the local-copy plugin directory to makensis, but the proper route is now established by the
!addplugindirchange above, so this dead line is removed as well.