People have been asking Let's Encrypt itself for this on the Let's Encrypt forum since the project was founded.

The usual answer is that code signing certificates are (supposedly) trying to attest to a legal identity in the hope of being able to punish people offline if they publish malware, or allow people or organizations to have a policy about only installing software known to be from a certain list of publishers. DV certificates for HTTPS are trying to attest to control of a name in the DNS, which is verifiable by automated technical means, and which is not necessarily related to offline identity. (ICANN says it should be ... in an indirect way ... which isn't always complied with, and which, following increased pressure from European privacy law, is often not visible to the public.)

A Let's Encrypt certificate would confirm that a certain key is apparently controlled by someone who apparently also controls a certain DNS name. But a code signing certificate would supposedly go further and confirm that it's apparently controlled by someone acting on behalf of a certain named legal person existing in a certain jurisdiction. This is much more expensive to verify usefully, although maybe some governments will eventually have a way to automate it.

This isn't to say that either kind of certificate is necessarily ideal for all of the different uses to which relying parties end up putting it nowadays, but just that what they're attesting to, and how you would verify it, is pretty different.

Edit: There seems to be a longer discussion about related points in this thread already at https://news.ycombinator.com/item?id=38056024

I'm fine with "installer have been signed with somebody who owns imagemagick.org"

TLS certificates are for encryption. You don't care if the endpoint is "bad" in some way, only that you are communicating with it securely.

Code signing certificates are to make bans stick. Totally different purpose.

There's another catch – you either have to register a company in your name, or find somebody to own it for you. I don't think the latter would be a big problem though: there was a lot of news about shady fintech startups in the Baltics lately and many of them were in fact registered in the name of random people looking for some quick cash.

Now, if I see something like MicroSoft-Inc OÜ (EE) in the app signature, I would probably get a bit suspicious. But if it's a less known brand? Who knows!

It's harder than it sounds, which is why malware authors prefer to steal keys than set up fake companies. Hence the new hardware requirements.

But they don't know who you are, because you're a scammer who is lying to everyone including them.

> Also, there are a lot of laws you can end up breaking with severe penalties in the course of trying to hide your identity for company registration purposes (it enters the world of anti-money laundering).

So is credit card fraud or CFAA violations, which is the thing this is ostensibly to prevent. Criminals don't follow laws.

> It's harder than it sounds, which is why malware authors prefer to steal keys than set up fake companies. Hence the new hardware requirements.

It's not actually that hard, it's just that stealing keys is really easy. And it's not obvious that the new hardware requirements are going to do any good, because that type of consumer hardware has been consistently riddled with vulnerabilities -- Intel essentially gave up on SGX because they couldn't make it work.

If it was that easy to hide your tracks police would never catch criminals, but they do. Every time you increase the complexity of the scheme the chance for mistakes goes up.

> that type of consumer hardware has been consistently riddled with vulnerabilities

USB signing devices aren't really consumer hardware, are they? I don't recall vulns in HSMs being a major source of leaks previously, but I'm sure the game will move there sooner or later.

> Intel essentially gave up on SGX because they couldn't make it work

Intel are selling SGX today, have built new features on top of it, it works fine and all their competitors have been investing heavily into catching up.

I'd argue that code signing for the average person has zero utility on Windows, and negative utility on macOS.

I really don't think anybody understands or even cares what a certificate means, and the only practical outcome is that sometimes they get scary messages when the app they're installing didn't pay MS for a license.

1. A malicious entity can sign up for a developer account.

2. A non-malicious entity's certificate can be compromised.

(1) does not seem to happen often, if it does happen, Apple can revoke the certificate. They can also increase the burden of proof for creating a developer account if it becomes more common.

(2) happens occasionally. Apple can revoke the key. But in general there is a strong incentive for developers to properly protect their signing keys, because Apple could ban them by not signing their keys in the case of repeated issues.

Code signing substantially increases platform security and as a 16 year macOS user, I would not want to go back to pre-signing days, where you could never be sure whether an application bundle was compromised, unless you'd verify the archive/disk image with GnuPG. But that is opening a big can of worms (WoT, etc.).

It kinda depends on what you mean by “default”, but you can always right click an app in Finder and select “open”. When you get the scary “unsigned app” pop-up there will be an extra option there to run it anyway, allowing you to run unsigned binaries without making any settings changes to the os.

That said, I largely agree with the rest of your comment. I do think, as a developer, their stapling stuff is way more onerous than the plain code signing. It basically puts Apple in the position to reject your app in the same way they reject apps in the store, even though there is no store involved.

Although... As long as downloads are always provided from the official domain via HTTPS, and the OS can keep track of that, I don't really see why the executable itself needs to be signed...

imagemagic.com

That's a good way to illustrate the GP's point.

As long as downloads are always provided from the official domain via HTTPS

You are conflating control over the public website with control over the build/signing infrastructure. A good defense-in-depth strategy means that a compromise of one should not lead to an automatic compromise of the other.

[X] Doubt

Do not underestimate the sheer number of people jamming in software names or descriptions into Google and getting their wares on the likes of softpedia.

- Benjamin Olafsson

- Imagemagick Solutions Gmbh

- Imagemaqick LLC

- FutureSoft Inc

It's very common for software to be developed by a company whose name bears no resemblance to the product itself. It's also common for small commercial or open source projects to be signed by an individual developer in their name. Am I going to verify any of these? In practice, no. If I wanted to verify the company name I'd visit the website I downloaded from and check the footer's copyright notice. Unless the website itself is EV validated (almost never) we're back to DV with extra steps.

The only time I've ever looked into the signee is when I downloaded obvious malware from a fake version of GNU Cash's website which I found from a Google ad. The malware was signed with a certificate from a Taiwanese hardware company.

And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.

Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app.

Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago.

A image editor should only need to load and save images I ask it to, no other system integration. iOS, Android and the browser has proven it is possible. Now the desktop needs a similar journey.

Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website.

Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.

Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower.

Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power.

Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.

Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user.

This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS.

The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).

In theory, sure.

In practice, when Ubuntu added a sandbox to the calculator it started taking longer to start than Eclipse. Took them about 4 years to fix it.

Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.

Even simple optimizations like shared caches fall afoul of proper isolation. In the past browser caches could be abused to find out if a user frequented specific sites just by checking how long it would take to request a site specific resource. Result: no more shared caching, all resources had to be loaded for each site separately.

Any reasonable representation of its color would classify the Sun as white, except when comparing it to other stars, where the small differences matter a lot.

[0] https://www.e-education.psu.edu/meteo300/node/683

This is exactly how Qubes OS works. My daily driver, can't recommend it enough.

• Admin privs aren't needed

• Packages declare what integration points they need in an XML file

It's similar to the way macOS, iOS and Android work. You can also (starting soon in Win11) declare that the app will be sandboxed.

However, developers have to actually use this system and most don't know it exists or how to use it.

The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor [1], which is a product my company makes. It can make these MSIX files along with all the new formats it requires for things like icons, and it can do so from Linux or macOS or whatever the developers prefer to use. So you can do releases locally without needing CI/CD or cloud signing.

Now, they'd like to have releases be done by GitHub Actions instead of using local hardware, and that would require a cloud signing service as they say. Conveyor can use those too. But that's not a technical requirement anymore, because it doesn't use any of the native toolchains so you don't need to release Windows binaries from Windows (or Mac from Mac). Conveyor can create all the files for installing and updates, and then upload them to a GitHub Release or ordinary web server, and it's free for open source projects. Given that they're initiating the release process from a laptop anyway, they can do it all locally.

Conveyor can also self-sign but that's more just to enable the tracking of permissions and things for all software. Self signed binaries still trigger warnings obviously.

[1] https://conveyor.hydraulic.dev/

By "cheap" you mean $500/year[0]? Then for anyone who isn't open source it's another $45/month on top for Conveyor. That's hardly "accessible".

That said, Conveyor looks awesome. We (thankfully) distribute our application via Steam/EGS/etc but when we were looking at bundling installers before that it was a nightmare and we probably would have just paid for Conveyor.

[0] https://order.digicert.com/step1/code_signing

So this stuff only applies if you don't want to go via the store.

Now you picked DigiCert and their cloud HSM solution. They're unfortunately quite expensive. SSL.com is a lot cheaper:

https://www.ssl.com/certificates/code-signing/buy/

So about $100 / yr, with a one off fee to buy a USB key.

And then ImageMagick is open source so they could use the tool for free.

Even commercially, $100/yr plus $45/month isn't particularly expensive compared to the labor cost of developing software commercially. The cost of the tool is like one hour of skilled labor at contracting rates per month. It'll save far more time than that given that as you said, doing deployment by hand is a nightmare.

And as you note, if your app is open source then you can use it for free. So then we're down to using the MS Store + Conveyor for free: $19, one off. Anyone can afford that.

I'm going to ignore Conveyor because that post was just a sly advertisement.

Whatever woes Windows's UX and design choices cause, I'd still take it a million times over any of these three terribly improductive environments

"BlueHat IL 2023 - Default Security"

https://www.youtube.com/watch?v=8T6ClX-y2AE

"Modernize your Win32 application for security and privacy"

https://build.microsoft.com/en-US/sessions/d2ad7043-223f-4bb...

Screen readers are a good example, proper accessibility APIs came later, as a response to screen readers' needs. The first screen readers used various tricks for injecting code into other processes and emulating GPU drivers to intercept GDI calls.

Sure, if you're making a game or some browser replacement, then go for sandboxing. But most productivity software shouldn't be confined to that. We need computing to stay open, not to all be closed down mobile OS style.

Thankfully open-snitch is now available on Debian.

User-only installs are possible:

> C:\Users\YourUsername\AppData\Local is intended for MSI installations for a single user but typically doesn't require Administrative privileges. This folder is normally hidden.

* https://superuser.com/questions/1327037/what-choices-do-i-ha...

This is the variable %LOCALAPPDATA%:

* https://pureinfotech.com/list-environment-variables-windows-...

See also perhaps CSIDL_DEFAULT_APPDATA and CSIDL_DEFAULT_LOCAL_APPDATA:

* https://learn.microsoft.com/en-us/windows/deployment/usmt/us...

This means that these signatures tend to expire when the code signing certificate or the CA itself expires.

https://learn.microsoft.com/en-us/windows/win32/seccrypto/ti...

My first code signing certificate from long ago is already expired; the signed executables under that certificate are still trusted by Windows.

Maybe I’m naive but I feel like the solution is pretty obvious: just crowdsource the cost of the certificate and only sign the software as long as the money keeps coming in.

If people really do care that much they should be willing to help shoulder the cost, and if they’re not then there shouldn’t be a problem with it being unsigned.

For utility style apps, Microsoft's app store is a joke.