dotnet
Sign all unsigned assemblies in a .msi
Is your feature request related to a problem? Please describe. Currently, when signing a .msi, it will correctly sign that msi file but none of the assemblies inside are signed. When I attempt to use --file-list to manually specify the names of the assemblies to sign, I don't see them getting a digital signature. I'm using a WiX project to create the .msi file. This happens during dotnet build. I don't want signing to have to get configured within every project and solution by all the developers in my company. They should not have to focus on that framework that we can automate.
Describe the solution you'd like The easiest solution would be an option --recursive-signing that would check the content of the .msi and sign every file (or dll) that doesn't already have a signature. I'm uncertain if unzipping, looping, signing, and rezipping things back into a .msi won't cause corrupted installers though. That would likely need to be considered. Unless the internal Win32 Signing Invoke call used to sign the .msi has a flag or option to already handle such recursive signing?
Describe alternatives you've considered If file-list would have worked, I would have made a pipeline stage that after dotnet build, checks every project to find their created .dll and then add the names to a new text file to use during dotnet sign.
Current workarounds seem to be faffing around with post and pre-build actions (which I'd love to avoid). I've read one blog post of someone attempting to build every project except the WiX first, sign the assemblies then build the WiX but they indicated that WiX rebuilds everything and overwrites the signed assemblies with unsigned ones again.
Additional context sign --version 0.9.1-beta.24170.3+394fc50bebb3ddaa3f79fc975f552d4ea2787552
@janstaelensskyline, thanks for the feature request. For supported container formats, Sign CLI already (and automatically) recursively signs contents. Sign CLI supports signing MSI files but does not support MSI's as a container. Support could be added such that Sign CLI would automatically sign MSI contents (without needed a --recursive-signing option).
You're welcome to raise a PR for a new provider for recursively signing MSI content.
Please upvote this feature request if it's important.
@dtivel Thanks for the feedback! From the readme I can deduce that .nupkg is seen as a supported container format and will have the behavior of trying to sign everything inside of it. The documentation isn't clear if there are other supported supported container formats already. Are there any others already supported. (.vsix for example?)
VSIX, Zip, MSIX/AppX, MSIX/AppX Bundles are other supported container types currently.
@janstaelensskyline I'm an expert in MSIs. Are these MSIs that you build or third party MSIs?
I'm not an expert in MSIs. But I've submitted a PR to fix this. I'd love feedback from anyone watching this issue.
As an InstallShield/WiX/MSI expert of nearly 30 years I don't see this as an installer signing responsibility. It's a pipeline signing step prior to building the installer. Tag, clone by tag, build app, sign app, build installer, sign installer. I wouldn't want this recursive signing to be automatic and I would want a way to specify which files as generally you don't want to sign third party files. This is why I asked previously the use case but the poster never responded.
Personally, I feel like the promise of this sign tool is that you no longer have to deconstruct your CI/CD into project-by-project build and sign steps. You just build everything unsigned then hand it off. It will take care of the tedium of pulling everything apart, signing, re-assembling, signing again, ad nauseam in the right order.
But yes, it sounds like you're one of the users who will suddenly want #647 and #775 if this gets added.
It's also worth noting that this tool is still in preview, so I'm not sure how much weight breaking existing users should really have when considering this. Everything in the documentation for this tool leads me to believe that its designed to sign files within containers--including MSIs.
No. My patterns are documented here:
https://github.com/iswix-llc/iswix-tutorials
Application.sln final project(s) publish profile or postbuild xcopy to \installer\deploy.
Call sign tool using files manifest to sign the files I explicitly care about. e.g. App.exe Common.dll whatever. Sometimes I'll use a powershell script to dynamically create the list of files based last modification date. e.g. Unsigned EXE/DLL that were created in the last 60 minutes.
Installer.sln consume signed files from \installer\deploy. The .wixproj already has support for signing targets to make sure the MSI and bootstrapper and various things internal to the bootstrapper all get signed.
Honestly this really isn't a space I have problems with. I think it's mostly people who are new to that space who are trying to come up with different solutions because the space isn't documented very well.
The .wixproj already has support for signing targets
If you are already using these to sign the final MSIs/burn EXEs, then you don't need this sign tool...
Honestly I work on all kinds of stuff and I don't remember what brought me to this issue on Apr 5. I tried to get help the issue creater but he never responded. I'm actually on vacation right now so I don't have access to look up how I'm using this tool but I'm sure I'm using it for something.