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.
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