publish-job: microsoft store

[davidkna]

It would be nice to add publishing to the microsoft store. MS provides an official action for publishing MSI and exe-installers.

The disadvantage of publishing MSI/exe-installers is that installers that cause SmartScreen warnings (e.g., if they are not signed), will be rejected. To avoid this, publishing MSIX packages is possible, but the action does not support those (microsoft/store-submission#12), though you can apparently work around that. For publishing CLI-applications as MSIX, you also need to obtain a HeadlessAppByPass waiver by contacting MS, which will also add a requirement to add a privacy policy to the application. I did implement MSIX-bundling for starship at one point (davidkna/starship@ea31911), but did not end up publishing the app due to the privacy policy requirement. I also remember reading that the MSIX-bundle would have to be (self-)signed for publishing, but the generated MSIX-bundle wasn't rejected outright without signing after uploading it.

[Gankra]

Wow this is a ton of great info, thanks! The smart screen stuff is definitely a mess, and only getting messier (cf #21).

[ashleygwilliams]

@davidkna this is a ton of great info. based on your experience with starship (big fans of the distribution work ya'll do over there!!) what would you think makes the most sense for cargo-dist?

we have a (hidden, but shipped) version of signing using ssl.com certs and so for folks who take that route, they can have the smart screen happy path.

in general code signing is a huge pain the butt, so trying to help build tooling and pave the way for the non-code signed path is appealing to me. privacy policy is an unfortunate requirement, though for most CLI apps, my suspicion is that the app itself could have a very generic one (most CLIs operate exclusively locally). and if the CLI "phones home" the privacy policy could point to the cloud service's privacy policy?

[davidkna]

@ashleygwilliams

One other advantage of the putting msi installers on the MS store is that it would require much less additional implementation work for cargo-dist because it already has signing and msi-packaging capabilities.

Assuming that an application is working exclusively locally, I would agree that a privacy policy could follow a generic approach. That being said, in a community-lead software project, there won't necessarily be any members with sufficient legal expertise to comfortably adapt an existing privacy policy or to review the final policy. I might get around to writing a privacy policy for starship at some point, but that has stalled our progress on ms store packaging so far.

If you think that writing a privacy policy isn't an undue burden, I think the msix approach for ms store submission could work well in cargo-dist.