Signing Clickonce manifests when binaries are already signed

[JaapMosselman]

I could not yet test ClickOnce due to #735, signing the deployment manifest wil allways sign all underlying artifacts, like the application manifest and the binaries. On exception is signing the deployment manifest. That will work when the other artifacts are not found.

But my scenario is this: I have a pipeline which:

• builds the binaries
• signs the binaries
• builds a msi
• signs the msi
• publishes a zip with the binaries
• publishes the msi

Some customers will use the msi, but for multiple customers we host the app also in our cloud, creating a separate clickonce for each customer. So when deploying to our cloud for a customer, I pick the zip with (already signed) binaries and create the manifests and than I need to sign the application manifest and the deployment manifest. But no need to sign the binaries again. (In my old process with a pfx codesigning certificate (which is expired now and this methods is not allowed anymore by the new regulations) I did this with mage.exe -Sign.

How can I accomplish this scenario with dotnet Sign?

[dlemstra]

Right now there is no option to disable recursive signing but that would probably be a good addition. But it would probably be a good idea to first redesign how we handle containers and filters before we add this feature.

p.s. You can test this locally by cloning my repository,checking out my branch and building the project. I have also done some tests in VM's using the output in the artifacts\bin\Sign.Cli\Debug\net8.0\win-x64 folder.

[JaapMosselman]

@dlemstra I tested with a clone of your repro and the bug seems indeed been fixed. But I discovered that the whole clickonce signing flow in dotnet sign is based on the output of VS/MSBUILD with the .deploy file extension for each file. But I have simply a clickonce created from scratch with mage.exe, so no .deploy files. So I have to rethink my options. Perhaps just rename my files also to .deploy before creating the manifest and deployment file? Does renaming already codesigned file, break the code signing?

[JaapMosselman]

BTW, look like using the --file-list option, you can prevent (re)signing of certain or all files.

And to answer my own question about renaming files: seems that is not a problem, because the sign tool signs a file when it has no .deploy extension and at the end that extension is added again.

[JaapMosselman]

After looking into the code what is exactly happening and doing some changes in my flow, I think I can manage my scenario with the current dotnet sign (including #735 of course). I changed my flow to use .deploy files (with a custom step to add 'mapFileExtensions="true"' to the deployment tag in the deployment manifest). This way we don't need the web.config either which is nice (learned something new ;-) ). And with the help of the --file-list I can say that only the .manifest and .application file should be signed.

So I will close this issue.