Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sign all unsigned assemblies in a .msi #673

Open
janstaelensskyline opened this issue Mar 22, 2024 · 3 comments
Open

Sign all unsigned assemblies in a .msi #673

janstaelensskyline opened this issue Mar 22, 2024 · 3 comments
Labels
enhancement Product code improvement that does NOT require public API changes/additions Priority:2 Work that is important, but not critical for the release

Comments

@janstaelensskyline
Copy link

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

@dtivel dtivel added enhancement Product code improvement that does NOT require public API changes/additions Priority:2 Work that is important, but not critical for the release labels May 14, 2024
@dtivel
Copy link
Collaborator

dtivel commented May 14, 2024

@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.

@janstaelensskyline
Copy link
Author

@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?)

@clairernovotny
Copy link
Member

clairernovotny commented Jun 13, 2024

VSIX, Zip, MSIX/AppX, MSIX/AppX Bundles are other supported container types currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Product code improvement that does NOT require public API changes/additions Priority:2 Work that is important, but not critical for the release
Projects
None yet
Development

No branches or pull requests

3 participants