Projectreunion: Make Sideloading easier

Created on 25 Jul 2020  Ā·  54Comments  Ā·  Source: microsoft/ProjectReunion

Proposal: Make Sideloading easier

Sideloading an app should be as easy, if not easier than installing an app through a regular installer. Users should not have to go through installing a certificate in order to Sideload an app, just like they don't when installing a traditional desktop app.
It makes the Microsoft Store the only consumer-friendly place to host packaged apps, but what if the app breaks Store Regulations or is an older version of the app?

With WinUI3 Desktop apps, it seems ever so important to make this happen as a lot of these apps will likely break Store Regulations.

Why can't we have something as simple as a popup saying "This app is not signed and could be dangerous. Do you wish to proceed?", or un-ideally but better than nothing, something like macOS.

Rationale

  • It allows pretty much any user to Sideload apps, not just the few that know how to install a packaged app's certificate.
area-App deployment feature proposal

Most helpful comment

Personally, I’d be open to graduated MSIX signing requirements based on the ā€œriskinessā€ of the packaged application. Sandboxed AppContainer applications are _much_ safer than arbitrary Win32 apps - a good start might be to relax signing requirements for those first.

I do strongly agree with the general thrust of this issue - signing is one of the tallest hurdles for native Windows development. I’m excited about the forthcoming Azure signing service in a professional capacity, but even that will be too much effort for many hobbyists.

The ease of sharing what you build with friends+family is a huge part of web development’s appeal. I worry about the long-term health of native Windows development without a similarly easy sharing+distribution story to attract new developers. MSIX feels like it’s _almost_ there but the signing requirement is a big limitation.

All 54 comments

@dynamiquel Please see the following comment: https://github.com/microsoft/ProjectReunion/issues/57#issuecomment-637614754. There it says Microsoft plans on launching a free of charge MSIX-signing service sometimeĀ ā€œthis summer.ā€ Once this is available for use, anyone can obtain a trusted cert from this service that won’t need to be manually installed. Hope this helps!

That sounds good. I'm kinda surprised they're making an entirely new service, surely they could have used a service similar to the Microsoft Store. Like, give every Windows & Xbox partner a certificate?

Users should not have to go through installing a certificate in order to Sideload an app

They don't. By default, Windows trusts a lot of Certificate Authorities and you can purchase a certificate from any one of them and sign your apps (just like you'd sign any regular Win32 app as well). That said, signing is an extra step that can "get in the way" if you just want to (e.g.) build a quick app and hand it to a friend or co-worker sitting right next to you.

So in terms of scope, are you specifically thinking of mass-distribution of an application to the general public, or are you thinking more about sharing directly with a small number of people who already trust you personally, or maybe developer scenarios where developers are more likely to understand the trade-offs of running unsigned software?

So in terms of scope, are you specifically thinking of mass-distribution of an application to the general public, or are you thinking more about sharing directly with a small number of people who already trust you personally, or maybe developer scenarios where developers are more likely to understand the trade-offs of running unsigned software?

I believe he meant "Mass-distribution of an application to the general public", just like the way they install a regular win32 app and they dont need to bother about installing certificates or what not. This is all every UWP devs want.

One of the feature users ask a lot is ability to install apps as "Portable Apps" (Install app on an external drive once and being able to use the app in any user account or any pc, and the all the app data is stored in the installed location). May be this could be worked upon in reunion.

@m98770 / @dynamiquel what do you see as the value of building a packaged app (vs. a normal unpackaged app) if the package is not going to be signed?

@soumyamahunt please open another issue for that suggestion.

@m98770 / @dynamiquel what do you see as the value of building a packaged app (vs. a normal unpackaged app) if the package is not going to be signed?

@soumyamahunt please open another issue for that suggestion.

It's a simple one click installer and uninstaller. It also makes installing/uninstalling consistent within the Windows eco-system as more developers publish with it.

Great, thanks for the info.

Is it possible to have an unpackaged UWP app? I always thought packaging was just part of the process.

Not currently, no. But the goal of Reunion is to make the "UWP features" available to all apps. Which specific UWP features are you looking to use?

I haven't spent that much time with UWP, but WinUI 3 and the libraries they can access (such as RoamingStorage) seems to hit most boxes (for me anyway). I haven't checked if this can work, but WinUI 3 Desktop apps as Game Bar widgets? Not really that important though.

My previous comment was in reference to:

@ptorr-msft what do you see as the value of building a packaged app (vs. a normal unpackaged app) if the package is not going to be signed?

If UWP apps have to be packaged, then unsigned UWP apps could also benefit from easier Sideloading.

One question I've always wanted to know, is WebView 2 coming to actual UWP or is it only for Desktop?

WinUI 3 is designed to work with desktop apps, but unfortunately roaming storage has been deprecated. GameBar has a hosting model that I'm not too familiar with. WebView 2 for UWP is in preview.

Personally, I’d be open to graduated MSIX signing requirements based on the ā€œriskinessā€ of the packaged application. Sandboxed AppContainer applications are _much_ safer than arbitrary Win32 apps - a good start might be to relax signing requirements for those first.

I do strongly agree with the general thrust of this issue - signing is one of the tallest hurdles for native Windows development. I’m excited about the forthcoming Azure signing service in a professional capacity, but even that will be too much effort for many hobbyists.

The ease of sharing what you build with friends+family is a huge part of web development’s appeal. I worry about the long-term health of native Windows development without a similarly easy sharing+distribution story to attract new developers. MSIX feels like it’s _almost_ there but the signing requirement is a big limitation.

Speaking of websites, in general do you think that "hobbyists" / people who primarily share with friends & family use SSL on their websites? (As more features are added as web standards, it does become strange that you can do X in a website but not with sandboxed native code... although things like "being a PWA" do require an SSL-protected site).

That’s a good question, I’m not sure. Running your own SSL certificate is certainly difficult, but many people can leave that to their web host and/or Let’s Encrypt.

I’ve used Let’s Encrypt via Netlify to secure my static websites, and Let’s Encrypt/Certbot on its own to secure ASP.NET Core APIs. Both were remarkably easy+cheap compared to code signing on Windows.

I'm going through the process of verifying my identity to purchase a code signing certificate and it is being a real pain in the ass. I'm a student that still lives with my parents so many of the documents that are required (like utility bills to verify my residence location) are in my parent's name. They also want a mobile phone bill, but since I'm on a prepaid plan my carrier does not emit bills. They want a government issued ID with my address: the only one I have is my passport (I don't have a drivers license since I use public transport) but they denied that because on Canadian passports the address is handwritten!

Their support is also not being really useful, consistent, or clear.

Not to mention that they are expensive in general. It cost me 200 for 3 years.

Windows allows installation of unsigned non-packaged apps. Not allowing unsigned packaged apps makes them inferior to non - packaged. Give unsigned packaged apps a generic or arbitrary publisher identity and let them install without a certificate. This should be allowed as along as non-packaged apps have that freedom.

I would rather see a mechanism for small developers to get code signing certs inexpensively than a move towards not requiring signing. Signing helps improve confidence in apps and the Windows ecosystem in general, and being tied to a real-world identity likely discourages some bad behavior.

I would rather see a mechanism for small developers to get code signing certs inexpensively than a move towards not requiring signing. Signing helps improve confidence in apps and the Windows ecosystem in general, and being tied to a real-world identity likely discourages some bad behavior.

Windows already has the ability to install unsigned packages (by self-signing the package on your own machine) but when compared to macOS, it's annoyingly much more complicated to do.

I was mainly thinking of a feature that simplifies the self-signing process for (slightly tech-literate) users, but still shows the dangers of doing so. Perhaps something like these message prompts:
image
image
image

Hiding the 'install anyways' button under a small little 'More details' hyperlink would be a great way of adding a barrier of entry, as most tech-illiterate users will not know pressing this link will proceed with the installation.

I'd say the scarier the prompt, they more developers will be encouraged to sign their apps.

Just like every OS, aside from iOS, every user should have the choice to install what they want, as long as they are aware of the risk

Windows can't really install unsigned packages. The only way is to enable developer mode and to register an already extracted package. Developer mode doesn't allow you to bypass the signature requirement on .msix files.

@sylveon First of all you shouldn't provide unsigned packages.

@Jaiganeshkumaran first of all I shouldn't have to go through a painful, convoluted, and expensive process to acquire a code signature certificate that allows me to distribute my packages.

@sylveon You can create a self-signed certificate instead.

That's not viable for distribution

@sylveon You can create a console application or a portable desktop application that first copies your certificate to Trusted People or Trusted root store and then installs the package by downloading it.

I, as a user, would never trust an application that does that.

@sylveon Many desktop applications use .exe installers rather than .msi installer so you can do something similar.

But they don't install arbitrary certificates into the computer's ultimate root of trust.

@Jaiganeshkumaran you are missing the point here, the whole point is making side loading easier. Why should anyone choose msix if they can write an installer themselves?? The whole point of MSIX was it makes installation simpler both for user and developer.

@sylveon You can use Trusted People instead or Trusted Root. Last time I tried it works. Users will not know.

@soumyamahunt Then buy a certificate from an CA. Companies have money. If you're an individual developer just put it on the store. Here's an example of UWP MSIX package that's fully signed: https://studiocinematic.com/

Users will not know except the big popup they get when a certificate is installed here šŸ˜‚

Point is, the signature requirement largely undermines the point for MSIX. If you need an .exe that manipulates the certificate store to install an MSIX, why even use MSIX at all.

@sylveon Removing it will make it even unsecure.

@soumyamahunt Then buy a certificate from an CA. Companies have money. If you're an individual developer just put it on the store. Here's an example of UWP MSIX package that's fully signed: https://studiocinematic.com/

Again you are missing the point, this is about making side loading easier, many developer don't want to buy certificate and publish to the store.

I've never suggested that. You're arguing against no one here.

My message about unsigned packages was in reply to the one right above, before they edited it to mention self signed certificates.

Store requirements are also not good for a big amount of apps, so those have to buy a code signature certificate. Not to mention a significant part of my userbase has a disdain for the store so I need out of store distribution anyways.

@soumyamahunt @sylveon Companies have enough money to buy a certificate. If you're an individual developer you'll probably use the store because you want a lot of users and as a single person that's difficult. Companies on the other hand can manage to distribute their apps on their own so it doesn't matter.

See previous message

@soumyamahunt @sylveon Companies have enough money to buy a certificate. If you're an individual developer you'll probably use the store because you want a lot of users and as a single person that's difficult. Companies on the other hand can manage to distribute their apps on their own so it doesn't matter.

You are again uninformed and missing the point here, if I would want more users using my app I would distance myself to Windows Store as much as I canšŸ˜‚, since most users don't use it and those who use it will probably fail while trying to download my app and spam me for their issues. So I have to provide side loading method anyway.

@soumyamahunt You don't get it. The main advantage of the store is that users can easily discover new apps. When you put it on your website only a few people will visit it while if you put it on store more people will download even people who don't know you because the store shows your app to them. Microsoft Store isn't a unpopular thing. It's pinned directly to your taskbar and a lot of apps are now available in the Store.

@soumyamahunt You don't get it. The main advantage of the store is that users can easily discover new apps. When you put it on your website only a few people will visit it. Microsoft Store isn't a unpopular thing. It's pinned directly to your taskbar and a lot of apps are now available in the Store.

The discoverability of apps in store goes out of the window when noone is using it, it might work for Apple and Google's store but not in Microsoft Store. I don't have to put my app on website, there are lots of social media platforms like reddit, twitter posting on which makes my app get more users than using store ever would. Even if MS store is pinned to taskbar most people either unpin it or don't use it at all. You can see even MS giving up on store and making their games available to alternative stores like Steam and getting huge amount of users.

@soumyamahunt Games failed because they can't compete against existing store but the store itself hasn't failed. Everything on my PC comes from the Store except few tools and programs. Microsoft just needs to fix the store reputation. It's not Windows 8.1 anymore.

@soumyamahunt Microsoft said they are planning to issue free certificates so don't worry.

@soumyamahunt Microsoft said they are planning to issue free certificates so don't worry.

Yeah there has been discussion about that in this thread, as far as I know it hasn't been finalized yet.

The need for certificates & manually installing them should go away (with a caution saying it may be harmful and proceed anyway) while Sideloading MSIX/APPX packages.

I don't think the need for signature should be dropped, but rather that we should drop the need that the signature comes from a trusted certificate. This is how Android does it.

Microsoft said they are planning to issue free certificates so don't worry.

Where?

Thanks for the lively discussion (please remember to be respectful of others).

The use of trusted signatures is a key component of the MSIX platform, both for integrity protection (e.g. no-one has tampered with your files) and for identity management (e.g. no-one can claim ownership of your toast notifications or other data). I would strongly advise against shipping an EXE to add self-signed certificates to the user's certificate store.

That said, we are aware that the cost / process of obtaining a commercial certificate can be a barrier to developers, hence the Azure Trust Service (sorry I have no data on a timeline).

Are there other concerns beyond the cost / difficulty of obtaining a certificate? For example, is the signtool step too complicated? Is integration with Visual Studio not good enough? Do you have issues with CI / CD builds? etc.

A non trusted certificate still solves the integrity and identity protection issue, as to resign after modifying a package's contents you'd have to use a different certificate, therefore giving it a different package identity. So you can't install a tampered package over a non tampered package, it'll be installed side by side. The only difference is that the certificate isn't explicitly trusted by the OS.

An alternative would be to add a flow in the package installer for a user to manually trust a self signed certificate, essentially adding that certificate in the Trusted People store and allowing users to install other apps from that developer without warning, since the user trusts that developer.

The problem wrt dev experience is mostly with CI builds, especially if you have an EV (because those require a hardware token)

To avoid information leakage, people often use a dedicated machine that handles signature requests from the CI workers. There's a non zero cost to that, and if that machine where to be compromised, your private key is now wide open. Alternatives like manually approving PR builds and having a script download the .pfx from some place also obviously requires you to have it available somewhere internet-facing. If GitHub or your GitHub account get compromised, someone could easily exfiltrate the key.

So really, the best way to sign on CI at the moment is to only self-sign in CI builds, and manually compile your release builds on an offline (if not airgapped) machine.

A non trusted certificate still solves the integrity and identity protection issue, as to resign after modifying a package's contents you'd have to use a different certificate, therefore giving it a different package identity

This is not the case. Notice that every app from the Store is signed with a certificate that is valid for only 3-4 days; you get a new certificate every time you submit. The identity of the package is based on the Subject field of the certificate, which is trivially spoofed if you allow self-signed certificates. I can claim to be CN=sylveon in the certificates I create.

My bad, I expected the package identity to have been based on something less spoofable.

Are there other concerns beyond the cost / difficulty of obtaining a certificate? For example, is the signtool step too complicated? Is integration with Visual Studio not good enough? Do you have issues with CI / CD builds? etc.

This has been painful for us. As sylveon said, the problem is CI. Apologies for going on a bit of a tangent here, I don't have anything to say about sideloading but I've been spending a lot of time recently trying to get our code signing process into a sustainable state.

Our CI/CD system builds, signs, and deploys every master build automatically, and they're immediately made available for our users to update to. We use an EV cert to sign release builds, and at the time when we set the system up this required a hardware token attached to a machine that we have physical access to.

That setup has always been fragile and error-prone, since the system seems to be designed around the workflow of a person occasionally and manually signing builds, not an automated release pipeline. It's become a major problem recently with our office mostly closed due to covid, and our entire engineering team working from home.

I'm in the process of provisioning a new EV cert in Azure Key Vault, and will be using the (excellent!) SignTool project to allow us to sign exes and ClickOnce builds using a certificate stored in Azure, which I expect to be more robust, flexible and secure. It's felt like there's been friction every step of the way, and I was very surprised to find that I needed to deploy and operate something like SignService myself to make it possible. That project's maintainer has been very helpful and responsive, but it started as a side project and while it's now part of the .NET Foundation it doesn't feel like Microsoft has contributed seriously to it at all. To be honest, it's felt like signing releases in our CI/CD pipeline is going completely against the grain and I've wondered a number of times if it's worth doing continuous delivery at all.

The cost and process of obtaining the certificate were _by far_ the easiest parts.

Was this page helpful?
0 / 5 - 0 ratings