Self signed packaged apps - prompt users to trust certificate

[JaiganeshKumaran]

Proposal: Self signed packaged apps - prompt users to trust certificate

Today it isn't straightforward to install self signed packaged apps. This has caused issues both to developers and users. Not everyone can afford code signing or the Store.

Summary

When installing through App Installer, ask users if they want to trust the certificate (app developer) that's embedded in the package. This will make installing self-signed packages easier.

Rationale

• Make it easier for users and developers
• More indie developers will start using MSIX reducing machine rot on user's machines
• Better reputation for "outside" UWP apps

Scope

Capability	Priority
This proposal will allow developers to use MSIX without purchasing an expensive code signing certificate while still being secure	Must
This proposal will allow end users to install self-signed packaged apps effortlessly	Should
This proposal will allow developers to install self signed apps on user's machine without the user accepting to trust	Won't

[ghost]

why use MSIX in the first place ? why would I as a developer have to care about users machine is being Rot or not ? that should be a concern for OS itself, not Us. sparse packaging is the answer for package identity for now, it's all built upon 30 years of old codebase, wait for some time until someone reverse engineers "package identity" requirement POS.

# https://github.com/microsoft/WindowsAppSDK/issues/128#issuecomment-686636006

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.

https://github.com/microsoft/WindowsAppSDK/issues/128#issuecomment-686663272

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.

Read Both. The moment he said "Azure Trust Service" , it can be safely assumed your clients will need to have connected to the internet , just to install your app. which will be a real pain in the ass.

[JaiganeshKumaran]

why use MSIX in the first place ? why would I as a developer have to care about users machine is being Rot or not ? that should be a concern for OS itself, not Us.

Don't you want better experience for your users?

[ghost]

'Better Experience for users' is subjective.

[sylveon]

why use MSIX in the first place ? why would I as a developer have to care about users machine is being Rot or not ? that should be a concern for OS itself, not Us.

This kind of attitude is what lead to MSIX in the first place, because developers don't care to clean up behind themselves. It is indeed an OS-level concern, and the answer to that concern is a declarative packaging format, so that the OS can know exactly what an app does, allowing it to clean up behind it. You'll notice most OSes which don't suffer from bitrot use something similar: Android with APK/AAB, iOS with IPA, even Linux with package managers and Snap/Flatpak

sparse packaging is the answer for package identity for now, it's all built upon 30 years of old codebase, wait for some time until someone reverse engineers "package identity" requirement POS.

Sparse packaging does not solve the issue presented here. Actually, it's affected by it since sparse packages still need a valid code signature.

[roxk]

why use MSIX in the first place ? why would I as a developer have to care about users machine is being Rot or not ? that should be a concern for OS itself, not Us.

It's like saying "Why throw rubbish to the rubbish bin in the first place? Why would I as a restaurant owner have to care about whether the street is clean or not? That should be a concern for the government itself, not us.".

To answer your question affirmatively: because the OS already solved it, and the solution requires cooperation with developers. Shirking the responsibility to the OS is just irresponsible.

[ghost]

It is indeed an OS-level concern, and the answer to that concern is a declarative packaging format, so that the OS can know exactly what an app does, allowing it to clean up behind it.

Because it's OS level concern, OS must implement the mechanism. instead of doing that throwing at Developers to fit our apps in a preDefined container is NOT the same thing as the OS implementing itself. By Confining ourselves to a box is essentially self confinement, the OS just removes the box upon user request. That's all it does right now. :-) It does not implement real cleaning mechanism. And yes manifests exist for raw EXEs for telling the OS what to do with the executable and it's dependencies , preDefined Container is not introducing anything new in this case.

Sparse packaging does not solve the issue presented here. Actually, it's affected by it since sparse packages still need a valid code signature.

as if this line was targeting this issue ? No. It wasn't. It's an extension of reasoning why not use MSIX.

This kind of attitude is what lead to MSIX in the first place, because developers don't care to clean up behind themselves.

Circular reasoning. why would developers care in the first place ? WHAT'S THE POINT ? Before even try to analyze 'ATTITUDE' , make sure the reasonings don't end up being Subjective. Remind me again. why would developers would care ?! WHAT'S THE POINT ?

Why throw rubbish to the rubbish bin in the first place? Why would I as a restaurant owner have to care about whether the street is clean or not? That should be a concern for the government itself, not us."

really bad analogy. Before the Government even let the restaurant to function, the restaurant and the restaurant owner has to agree to abide by the laws, the restaurant owner doesn't clean the rubbish by themselves just because "It's Good You Know", it's because they have to, otherwise there are consequences. ¯_(ツ)_/¯

To answer your question affirmatively: because the OS already solved it

You are assuming that. The OS didn't solve anything. The OS literally see everything what an application does at runtime, what APIs are being called, what garbage are being produced by which apps. yet it does nothing upon users Uninstall request. :-)

[riverar]

Hey folks, let's keep this on-topic with the proposal. Thoughts on whether or not MSIX is useful is not relevant here.

@Jaiganeshkumaran How do you distinguish between bad and good packages? I'm concerned that this change would train users to ignore certificate warnings, some of which could be legitimate. (There would be no way to know.) Perhaps you could require Development Mode to be enabled? And maybe just allow for unsigned MSIX packages if Development Mode is enabled?

[wjk]

@riverar Ignore what certificate warnings, exactly? This is really no different than when a user confirms elevation of an EXE-based installer. As long as you keep the MSIX certificate settings quite separate from the more dangerous certificate settings (e.g. trusted-root certificates used by one’s browser), I do not believe that making MSIX signing easier to deal with will cause any security problems with certificates overall. I also believe that installing self-signed packages should not require Developer Mode to be enabled. Remember that the goal we’re all working towards is being able to actually ship software to potentially non-technical end users using MSIX.

In terms of user interface, I am partial to the following message: “%1 declares that this program is safe. Do not install if you do not trust %1.” (where %1 is the publisher display name from the manifest file). Makes it clear to the user that they are choosing to install an application from a potentially unknown developer, but allow the user to easily override the warning if they trust the developer IRL. (Only the user can choose who they “trust.” Placing mechanical restrictions on this decision only makes security worse over time, as users disable OS security features to install and run what they want to. I especially despise Microsoft Edge’s “reputation” system that requires your app to be installed X number of times for the scary warnings to disappear, but provides no easy way to override said scary warnings so that people actually install the app.)

I understand that without a trusted CA we have no way of implementing a revocation list. However, why can’t the signatures of “bad” (malicious) packages be put into Windows Defender, and have the App Installer run the MSIX through AMSI first? Due to the way MSIX works, a malicious package can be detected with 100% certainty simply by examining the package ID and signing certificate public key, which makes maintaining a banned-package list much simpler.

Also a concern: If this feature is implemented in OS core such that it works only on Windows 11, I will be most pissed because then there is no way I could make use of it. Due to Windows 11’s preposterous hardware requirements, I must continue to support Windows 10 indefinitely. MSIX hasn’t taken off precisely because of the onerous signing requirements, and there are far more Windows 10 PCs in the world than Windows 11 PCs. To adopt MSIX, I must be able to downlevel-target my packages to earlier than the bleeding-edge latest-and-greatest. Can this be implemented such that the App Installer app can be updated to include these changes on all still-supported builds of Windows 10 automatically? (Remember that one of the long-forgotten original goals of Reunion/App SDK was to make downlevel targeting easier by decoupling developer features from OS updates.)

[sylveon]

I doubt such a feature would be able to be ported downlevel.

[Samuel12321]

This is essential for .MSIX to serve as a viable replacement to .exe and .msi installers.

The current limitations which require developers to purchase signing certificates is a lose-lose situation, open source projects and small developers don't want/ cant buy a certificate so avoid .MSIX. This results in the users not benefiting from the security, convenience and clean uninstallation of .MSIX.

While I do understand the reasoning behind forcing a trusted CA Certificate, it isn't increasing security, it's actually just making developers use .exe and .msi rather than .MSIX.

[jvintzel]

Thank you for the feedback. Its not the goal of the app installation flow to elevate and install certificates, primarily for security concerns to the device. IRT making it easier to get trusted certificates we are currently in a private preview for the Azure Code Signing service to help in this area.

[wjk]

we are currently in a private preview for the Azure Code Signing service

Why is it still in private preview, given that it was announced some three or four years ago? What's taking so long?

[jvintzel]

It actually was announced at Build 2020. 2020 had its own challenges and it did take a bit longer than expected to ensure we complied with everything needed to be a public authority.