Closed mgravell closed 4 months ago
This is awesome feedback from the docs perspective @mgravell really appreciate it. I'll talk with the team about these precise guidelines, so that we can refer our customers on how to perform application registrations and a mechanism to obtain this data.
cc: @ianjmcm
This is how we set it up for the @ImageMagick project: https://dlemstra.github.io/github-stories/2023/imagemagick-now-uses-azure-code-signing/. It still uses the old name but the same steps should still be done.
Hi @mgravell, were you able to get up and running with this action? The steps in the previously mentioned article should be a really good guide: https://dlemstra.github.io/github-stories/2023/imagemagick-now-uses-azure-code-signing/
Just parachuting in here because it was noted in https://github.com/wez/wezterm/issues/5074 that this service exists, but I can't find any useful documentation on really what it is, or whether it is something I can use, so consider this a vote for improving the docs!
I'm an OSS maintainer, so I'm in a similar situation to the imagemagick blog that was linked above. Scanning through it, they are registering an existing LLC in their certificate. In my OSS maintainer role, I do not have an LLC and wish to avoid registering one if at all possible, because I consider it to be an unreasonable burden.
Are there other verification options that are compatible with this service? For example, with Let's Encrypt, I just need proof of domain ownership to get a certificate. For an OSS project hosted on github, is there some kind of proof-of-github-repo/org-ownership that could be established? Or is there already something like this in place for this service?
What I would like to see is some information geared up for OSS maintainers to help them decide whether this service is a fit for them, and that information shouldn't require an azure account to discover or learn more about.
Thanks!
hey @wez
In my OSS maintainer role, I do not have an LLC and wish to avoid registering one if at all possible, because I consider it to be an unreasonable burden.
Thats a reasonable approach, which is why we are on the process of rolling out this feature for individual maintainers and or young corporations, our expectation is that it should be publicly available in the next upcoming weeks.
For an OSS project hosted on github, is there some kind of proof-of-github-repo/org-ownership that could be established? Or is there already something like this in place for this service?
We do have a vetting service that allows us to perform that proof of ownership.
What I would like to see is some information geared up for OSS maintainers to help them decide whether this service is a fit for them, and that information shouldn't require an azure account to discover or learn more about.
This is fair feedback, and we need to do a better job documentation-wise to answer these inquiries, especially as we rollout individual maintainers features. I'll pass this feedback to the team.
In my OSS maintainer role, I do not have an LLC and wish to avoid registering one if at all possible, because I consider it to be an unreasonable burden.
Thats a reasonable approach, which is why we are on the process of rolling out this feature for individual maintainers and or young corporations, our expectation is that it should be publicly available in the next upcoming weeks.
I'm very happy to read this! Azure Trusted Signing seems like the most affordable and CI-compatible code signing solution, and I jumped through all the various Azure hoops before finally getting stumped on the identity validation form because I don't have (or want) an LLC. Following this thread with the hope of an update soon :)
Context: I'm an experience library developer who knows exactly zero (on a good day) about the machinery of code-signing, hence my libraries are not currently signed; "if only there was a MSFT service that could help me with this?!"
So: I have (after some stumbles) successfully created a Trusted Signing certificate profile in Azure; next step:"now let's sign something" - find this supported GitHub Action, and see:
ELI5; if we assume that a Trusted Signing certificate profile exists in an Azure account accessible to the user, how do I get from there to here? What CLIENT_ID and CLIENT_SECRET is it asking me for, and where would I find and/or generate them? The docs right now assume a lot of information that is probably obvious when you've done it at least once, but which is unfamiliar if you're coming in cold. Unfortunately the "learn" docs stop at the point when a certificate profile exists, and just waves vaguely in the direction of "oh, and you might want to use it with GitHub Actions", without saying how.