3 ms·
> if you don't like the "walled garden" approach you shouldn't be using Apple But I use none of Apple's online services. Not even the app store. App store for
by grishka 4y ago
> if you don't like the "walled garden" approach you shouldn't be using Apple
But I use none of Apple's online services. Not even the app store. App store for me is the place to update Apple apps, and that's really it.
> and if your complaint is paying to have your code signed properly as a dev, that's the same across macOS and Windows,
Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator.
> in a similar vein to SSL certs for websites
And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche.
See, it's about choice. If you want to throw your money away for some reason, sure you can still pay for an SSL certificate. Or you can use Let's Encrypt for free, set it up once and forget. Your users would see a lock icon either way. No such luck with macOS app signing — Apple is your only option.
I like Android's security model better. You sign your apk with a self-signed certificate. No signing identity is enforced upon initial installation, but if you release an update, the new apk has to be signed with the same certificate. You can install an apk with the same package id but a different signature only after you uninstall the previous one (and delete all its private data). This helps with security and data integrity. I see no reason why Apple couldn't adopt a similar scheme on their platforms, except that they want all control they could get away with.
- sbuk 4y ago> Windows? I know you can sign Windows executables, but why would anyone want to? I have Windows 11 on a VM. It runs unsigned executables just fine and, unlike macOS, doesn't treat them like they're radioactive. You just get a differently-colored confirmation window if you run them as administrator. It ought to! I'd love to see this in Linux and the BSD's too. Signing applications and binaries should be the norm. > And before Let's Encrypt and other similar free automatic CAs came along, SSL/TLS was very niche. Let's Encrypt came about to help with security. Happy to hear arguments pro a similar service for application signing, but it will have to follow similar, or tighter restrictions and you'd still be at the whim of third party. > I like Android's security model better. You sign your apk with a self-signed certificate. That is most definitely not a security policy. Self-signing is no different to not signing at all. There is no provenance, no chain-of-trust.
- 0ct4via 4y agoAbsolutely this.
- grishka 4y ago> There is no provenance, no chain-of-trust. We should've probably started with the fact that I despise security policies based on provenance, chains of trust, public key infrastructure, and third parties. This kind of "security" feels extremely fragile and unnecessarily centralized. We somehow live with how SSH identifies servers by their keys, with no third-party verification, and consider that an okay level of security. Why can't we use the same approach for TLS and for executable signatures? What's so fundamentally different that third parties are required in these cases?
- sbuk 4y agoSSH doesn’t rely on PKI. Using SSH certificates is a password replacement for accessing remote services. While it is a kind of identity verification, its purpose is not the same an application signing. Self signing is open to too much abuse. The whole point of signing is that the provenance can be verified (yes, checksums are a thing) and that the signing can be revoked should something bad happen. Notarising code is the process of a third party verifying your identity. So rather than saying, “hey, you can trust me”, you are asking a third party to vet and prove that you are trustworthy. If you can’t see the value in that for all parties - including the most important party, your customers - then that’s up to you. No sane SOC will allow unsigned or self-signed binaries. Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries, and OS vendors need to take care of the rest. Thinking of the Confidentiality, Integrity and Availability triad, your solution is unworkable.
- grishka 4y agoEveryone used to run unsigned binaries all the time for the entire previous history of computing and somehow the hell didn't break loose. What changed? > Consumers with the slightest bit of savvy will not run unsigned or self-signed binaries I'm a "consumer with the slightest bit of savvy" and I despise code signing schemes that care about the signing identity, so you're already wrong. I absolutely will run unsigned and self-signed binaries. I trust myself and my own judgement more than I do anyone else in the entire universe.