You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
@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?)
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
The text was updated successfully, but these errors were encountered: