Require all developers to MANDATORY digitally sign all application and installation files

When an application is not signed with a trusted digital certificate, it’s vulnerable to manipulation and exploitation by bad actors to distribute malware, ransomware and other nasty processes.

To prevent this exploitation, Asobo and or Microsoft should MANDATORY require all add-on developers to digitally sign every installation and application file with a trusted verifiable digital certificate from 3rd party certificate authority. No self-signed untrusted digital certificates.

A user should have 100% confidence that any flight simulation add-on software they bought and installed is the original packaged code the developer wrote.

Because bad actors can’t create something themselves and digitally sign things…

Only the owners of the company can obtain trusted certificates in that company name and jurisdiction. Only individuals can obtain trusted certificates in their name and jurisdiction.

By digital signing the application with a trusted certificate, it’s providing confirmation the original packaged code downloaded from the developer website or elsewhere is not tempered and indeed genuine. This provides user confidence to install the software.

For example. the Chrome exe file,

Flight simulation add-on developers do work hard to create the best add-ons available why would you want to have your code manipulated by bad actors? Damage user trust in your software? CDNs do get compromised. Digital signing is the solution.

Hi there,

I don’t quite understand this request - there is no executable code in the packages distributed on the MarketPlace.

There are packages distributed elsewhere that may include executable code (or even just an installer) but:

  • We may not even be aware that they exist
  • They never go through any Microsoft/Asobo pipeline

How could we force people to digitally sign things that we don’t even know about?

Best regards,

Eric / Asobo


There are many reasons why this would not work in the large ecosystem that is the 3rd party sim community.

On top of my head:

  1. That would make pretty much everything unmodable since we’re be stuck with encrypted files from everyone. We’ve already seen what this would look like with Marketplace products where you can’t scan airport data or can’t improve on top of an existing 3rd party aircraft.
  2. It’s unrealistic to think that every creator will have to update their signature on expiry. So many useful mods would be rendered useless after the certificate expires only a few years after a mod’s release.
  3. While there are options to get relatively cheap certificates, the complexity alone would dramatically hinder creativity and innovation that comes from the freeware community.
  4. Just like on Windows and MacOS, the user has the choice of either only purchasing on Marketplace or from outside sources.

Just imagine trying to convince digicert to digitally sign my Egnine.cfg, my FlightModel.cfg, my .WASM file… my GLTF files… my .XML files… my smallest aircraft project has more than 5000 files I believe…

Ultimately I submit to Marketplace, they process the files and they submit an encrypted version for release with all the files I prepared… I mean, users should be able to trust the files from market place…

This suggestions is just not viable with the type of content people create… scenery developers are the same… is a bunch of textures and specific files for MSFS only…


Hi @EPellissier,

Asobo could change the export process within Flight Simulator and only allow packages to be built and exported with a valid digital certificate. Include in the official documentation valid digital certificates are highly recommended by Asobo for developers using SimConnect. Giving the developers a push in the right direction can slowly change an ecosystem.

Digital signing is done by yourself not the certificate authority. They only supply you with the trusted code signing certificate.

again imagine trying to digitally sign over 5,000 files non executables… then Marketplace team encrypts them… and all goes for nothing…

You don’t seen to understand your suggestion is not viable for the type of content at play here… also remember, we pushing content not only for PCs… but also Consoles… and certain things simply put cannot be done…


Let me get this straight…so you think Microsoft should spend time and resources on this draconian effort, only in the hyper-niche flight sim space?

I take it you’re not a fan of add-ons, mods, or the creative community that keeps your hobby relevant.

Woah there, I definitely wouldn’t call digital signing draconian - but I also think it wouldn’t provide any benefit in marketplace add-ons. All WASM & JS code distributed is executed in the sim sandbox, which can make sure it doesn’t do anything nasty. And if someone wants to change my livery texture to say “FREE PALESTINE!”, good luck to them.

1 Like

I didn’t, I called having MS enforce it in this niche space Draconian. By definition of the very word, it is absolutely what I said and how I said it.

A severe and excessive enforcement.

Were seriously talking about enforcement OUTSIDE of marketplace here…in WINDOWS territory, but in the context of…Flight Sim.

Look, I don’t have a horse in this race, we sign our stuff. I also know this request will go nowhere so I’ll save my efforts to enjoy the day ahead. My two cents have been dropped on the table. :metal:

WASM is compiled… they cannot changed it… as for .JS… obfuscate it and done… nobody can change it.

Remember MSFS WASM and Coherent basic design is exactly to sandbox the product to make it secure, this prevent any nasty thing from being pushed to end users…


Digital signing doesn’t prevent you modding files you normally would do. It protects the .exe .dll executable code packages. The installation and background process .exe .dll files

This is were time stamping comes in. Your code will always be valid even if the code signing certificate expires.

Payware should be required to have valid trust code signing certificate. Freeware can use self-signed certificates.

Digital signatures don’t take away choice, it improves security and confidence in the software.

Digital signing protects the .exe .dll executable code packages. The installation .exe and background process .exe .dll files.

An aircraft doesn’t have any .EXE or any .DLL, neither an scenery… neither it has installation files, it is all submitted to market place who performs the installation for the user.

In other words, there is nothing to digitally sign enforced by Microsoft / Asobo… You probably talking about installations files outside of MSFS which is not part of the Market Place submission process and therefore outside of Asobo control…


I’m talking about the whole ecosystem.

I would say Asobo and Microsoft do have major control over flight sim packages and the direction these flight sim packages are created.

Hi @EPellissier and all,

Asobo could change the exporter packager within flight simulator to output only digitally signed .cab[1] files for submission to either the marketplace or standalone.

For marketplace, The developer should distribute the marketplace .cab file, to Microsoft, Microsoft checks the signature, extracts it for encryption and distribution within the marketplace.

For standalone, The developer should distribute the standalone .cab file and extract on the user computer and install the files in the flight simulator community folder. For externally written .exe .dll files only a recommendation can be provided.

Giving the developers a push in the right direction can slowly change an ecosystem.

[1] SignTool.exe (Sign Tool) - .NET Framework | Microsoft Learn


Thanks for the link to SignTool but I think I’ve been using it for longer than I can actually remember. :stuck_out_tongue:

There’s still one thing I do not get - according to you, what would be the benefits of this whole signing procedure for add-ons that are published on the Marketplace ?

Best regards,

Eric / Asobo


I think there might be a misunderstanding here of how the sim installation system and sandbox works.

The sim does not install any DLLs or background executables onto your system when a Marketplace package is installed, and in fact it doesn’t run a Windows Installer (MSI, WIZ, CAB, EXE, etc) at all. For all Marketplace packages, there is not any code (nor can there be any code, definitively) that is executed by the system. Instead, there are two possible sandbox technology stacks.

One is a runtime interpreted code system (JavaScript), and as in all other browser based JavaScript environments, it has no access to your system. The reason it does not and it is impossible for it to be hacked or modified in such a way to be made able to, is because JavaScript does not even have any system level APIs. The language itself has no way to call into the system: it cannot directly access memory, it cannot read or write files, it cannot access system resources or drivers. On top of these language constraints, the code is not executed by the system itself (it is not its own process), it is instead executed by MSFS at run time, inside the sandbox.

Similarly, the second available technology stack is WebAssembly by way of the C++ language. WebAssembly similarly is without system level interfaces, and there is no way to directly access system resources, like file I/O, process memory, GPU, etc. No matter how ingenious an attacker, because these interfaces simply do not exist, there are no possible attack vectors here. Additionally, just like the previous tech stack described, this WebAssembly code is not a separate process executed by the system: it is code called only by MSFS at run time, in the sandbox.

In your opinion, how should this duality be handled from a code perspective? What prevents someone from taking the contents of a payware package, then repackaging it self signed as freeware? How would MSFS know which packages are allowed to be self-signed, and which ones are not?

From a purely technical perspective, this is actually an extremely dangerous use of a certificate chain, and the certificate chain will not validate and produce the mandatory public keys being requested with an expired certificate in the signing chain. Of course, you can override this, but this allows attackers to use expired certificates for valid certificate authorities they may have obtained illegally, and leaves it impossible to detect if a certificate chain is “validly expired” (the time stamp idea proposed) or “invalidly expired” (an attack).

Given the already secure environment in which a Marketplace package exists and are executed, I think this is the root of @EPellissier’s question. What security benefits can be derived from the proposed signing scheme and what attack vectors are being prevented?