[Feature]: Artifact signing support

[svrooij]

Is your feature request related to a problem? Please describe.

We are thinking about side loading specifically for a beta version of an app.
The store has 1 version and will always update to the latest, being able to provided a trusted app msix would be great

Describe the solution you'd like

Integration with Azure Artifact signing to use a GitHub action that can actually publish a signed application artifact.

Additional context

MVP summit discussion with @TheJoeFin

[chiaramooney]

Could you give a little more information on exactly how you would want this feature to work? Would you like the winapp sign command to offer support for signing with an Azure Artifact or cert from Azure Key Vault?

[svrooij]

@chiaramooney I would say the Azure Artifact signing way would be the most relevant (very cost efficient, easy to use), people that actually managed to get a trusted Code signing in their Key Vault probably have another way to sign.

• 🥇 Azure Artifact signing
• 🥈 Support for code signing cert from key vault

[zateutsch]

@svrooij

Hey there, we did some investigation into what this could look like. I've come up with two different options for what this could look like. I'm leaning towards option A as I believe option B has too many limitations and risks and may be out of scope for the CLI

Option A (think this is the way to go): Minimal signing that assumes user has set up signing accounts via Azure and requires you to pass your own metadata.json file

This approach would require that the user meets all the prerequisites for enabling signing artifacts via azure. For this option, a user would run winapp az-sign --token <token> --metadata-file <path-to-metadata.json> and we would use signtool to sign via Azure. The token flag would be optional and we can auth through Azure Identity if no token is passed. You would need to provide your own metadata file.

Option B: We provide an interactive flow that helps users create signing profiles, add signing roles, and select from available resources when setting up signing. Interactive flow could be skipped by providing Azure scopes or metadata file.
The flow would look like this:

1. User runs winapp az-sign <artifact-path>
2. They are prompted to authenticate with Azure via link and provided code for auth. Skippable with --token flag.
3. We surface a list of resource groups with a max of 10. The last option in the list will be enter a custom resource group. Skippable with --resource-group flag.
4. We surface a list of signing accounts within the resource group. Skippable with --signing-account. If none are found, we refer them to Azure documentation for creating and validating a Trusted Signing Account. Also follows max 10 rule for display. Polling for signing accounts will also return the required signing endpoint for metadata.json
5. We poll for identity verification, if this fails, we point them to to Azure documentation for getting Trusted Signing set up properly. We offload this responsibility.
6. We surface a list of signing profiles within this account. If none are available, we prompt for creation of one. Once again, max 10 rule for custom input applies. Skippable with --signing-profile. Signing profile creation will prompt for a name along with signing type (list of four)
7. We poll for the Trusted Certificate Signer role. If succeeds, we proceed. If it fails, we try to create add that role for the current user at the lowest possible level, ie just the profile. If this fails due to permissions, we output the required Azure command that they need to send to their admin to gain the role, and fail.
8. If all succeeds, we construct a temporary metadata.json file, and sign using the executable path and this file. We clean up afterwards. All input is skippable if --metadata-file is provided, assuming validation passes.
9. Signed executable is output on success.

Flags

• --metadata-file / -m This will allow user to skip entire prompting flow, this is the final constructed requirement for signtool.
• --resource-group / -r Skip resource group prompting up front by providing up front
• --signing-account / -a Skip resource group prompting and signing account prompting by providing up front
• --signing-profile/ -p This one is tricky, signing profiles need at least an associated signing account to be identified. If this flag is provided, we should fail and say a signing account is necessary. I don't think we should prompt for signing account if this specified, as it will make the order of flow confusing
• --token / -t Skip authentication and provide token directly. Mostly see this for use within CI/CD.

I've have some pretty strong concerns about interacting with Azure in this way for the user. I think that we may be taken on too much burden, but open to any input this matter.

Further Details
Feel free to check out this doc for more info:

AzureArtifactSigning.md

Let me know what you envisioned.

[svrooij]

I have to read your full comment, but my initial reaction is as follows:

Option A YES!!!

Maybe an extra feature to generate the metadata file from an existing signing account. Creating an Azure Artifact Signing resource with everything needed should not be in this tool. But a flow where you can interactively select the resource that will then generate the metadata would actually be a nice user experience.

Option A security:
Please DO NOT create the --token parameter. Code signing is a security feature! And giving users an option to supply a token opens the door for all kind of unsecure options. Just DefaultAzureCredential should be the only available option, or even better a combination of InteractiveAzureCredential (if interactive session) and just AzureCliCredential. And if this does not result in a valid session you output "make sure you installed Azure CLI and run az login with your choosen authentication method."

There are plenty examples to use the Azure CLI authentication in all pipelines and it works locally.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity after requesting information from the author. It will be closed in 7 days if no further activity occurs.