Automate provisioning of WinGet package for OpenSC

[RufusJWB]

Problem Description

Currently the WinGet package for OpenSC is generated manually. This leads to the problem, that the package is outdated:

Proposed Resolution

Generate the package automatically as part of the build process according this documentation: https://www.techwatching.dev/posts/wingetcreate

Steps to reproduce

n/a

Logs

n/a

[frankmorgner]

We don't have the ressources to manage all possible sources of distribution. I don't know who pushed OpenSC to winget in the first place, but you should contact that author for an update. That should also be a good time to verify the package that's available there.

[Jakuje]

As discussed in #3077 (comment), @RufusJWB was the one initiating the push of the package to the winget repository, even though the adding was done by somebody else, but they do not look active anymore in the repository so short term, we should update the package there (I think anyone can do that and manual update does not look much complicated).

Regarding to the automation, again, if you are using this, you would be the best to work on that and we are happy to accept the contribution.

[frankmorgner]

Thank you for the clarification.

Skimming through the integration part for GH actions, we could indeed submit "some" MSI from the release CI process to winget. However, that would NOT be the installer which is available through GH release downloads, because we are triggering the productive code signing of the installer manually in Signpath.io after the run is finished.

[RufusJWB]

because we are triggering the productive code signing of the installer manually in Signpath.io after the run is finished.

If you would start the signing at Signpath.io from a manually triggered GitHub Action, the same action could later build the package and submit it to Microsoft. There is a documentation available, how to do this: https://github.com/microsoft/winget-create?tab=readme-ov-file#using-windows-package-manager-manifest-creator-in-a-cicd-pipeline

[frankmorgner]

We trigger the signing directly in Signpath.io, download the new binary there and upload the new binary on GH releases.

FYI: microsoft/winget-pkgs#147910

[frankmorgner]

Regarding the automation via GH releases, there is an open issue for this (microsoft/winget-pkgs#1515), which isn't officially solved. However, there is a third party GH app, which seems to implement this (https://github.com/marketplace/actions/winget-releaser) and alternatively, there are some repositories which implement this manually based on the winget tools (e.g. https://github.com/microsoft/PowerToys/blob/main/.github/workflows/package-submissions.yml).

All in all, those finding look promising, but I don't have much time for more investigation...

[RufusJWB]

All in all, those finding look promising, but I don't have much time for more investigation...

I'd like to support, but I'm struggling to get the build actions working in my fork of this repo, and even if I'd get it working, I'd still not be able to sign and publish the release version. So I fear one of the maintainer needs to take this over. If I can anyhow support you, please let me know.