Automate provisioning of WinGet package for OpenSC about opensc HOT 8 OPEN

PIV specs also have a "pin_policy" which says if global or local pin can be be used and other things if SM is used:
line 424: unsigned int pin_policy; /* from discovery */ It is always used as priv->pin_policy
grep pin_policy src/libopensc/card-piv.c | wc shows 21 uses of "pin_policy" in your branch.

You may want to use yk_pin_policy to avoid confusion and point out it is only for Yubico.

from opensc.

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.

from opensc.

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.

from opensc.

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.

from opensc.

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

from opensc.

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

from opensc.

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...

from opensc.

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.

from opensc.