Really? This is _huge_ to you? How many unsigned apps are you downloading and running?
This is one of those features where the benefits seem to very obviously outweigh the drawbacks. 99.9% of users just aren't running unsigned software, so the moment that happens, it is most certainly malware.
If you're developing software yourself, this isn't an issue either, since all the relevant toolchains, debuggers, etc., work just fine under this model. That's a supported workflow. The only thing that isn't supported is downloading some random unverified app bundle from who knows where and treating it as if you could trust it. You 100% can't.
And yes, I also believe that if an OSS project considers "muggles" their target audience, they should prioritize setting up code-signing. Consider it a service to their users. If the fee is a problem, it's important enough to spend the effort to find a way to finance it. If you can't find someone who is willing to put their name on it, you shouldn't ask people to run your software on their machines in the first place.
> How many unsigned apps are you downloading and running?
For me, quite a few? Internal tools at work, open source projects which publish builds on their github, that sort of stuff.
(And no, paying Apple a yearly subscription for the privilege of letting users run an app is not a reasonable expectation of small open source projects)
Yeah, but you only need to approve an app once. I think I Ctrl+Open an app like once a quarter on average, sometimes going most of a year. This really isn't a big deal.
As a creator of a programming language that can compile binaries of any supported platform from any platform it is an unsolveable problem.
I can't do the signing as it requires Apple stuff. Not to mention it is unethical to require it as it's used for gatekeeping not just security (requiring Apple to decide if you can run an executable is unacceptable).
Compare it to Android where you can use self-signed certificates and it has an actual function, it allows updates signed with the same certificate to access the existing stored data on the device. It improves security without gatekeeping. At least that was on the older Androids, haven't done work on any newer ones.
I can't do some kind of universal launcher that is signed by me because it would allow to run arbitrary code and therefore it would be banned.
Therefore the only solution is to search for various workarounds (eg. by teaching the users how to run the software) or if not possible anymore stop supporting newer versions of MacOS and rely on web applications to support the platform (like it's the only way on iOS).
Which would be even worse on the desktop as the usability can be quite bad, but at least users would have some chance to use the applications even on their closed system.
I hope you're able to see how your use case is incredibly niche, and should not be a priority for a general security model for an operating system.
Your problems are extremely insignificant in the big picture, where the priority of a serious operating system should be to support regular people in avoiding malware and malicious social engineering. macOS is a general purpose operating system, not a hobbyist or tinkerer OS, and the vast majority of its users are non-technical.
I get that it's annoying, but pushing the work on you is a massive benefit to your users.
You're right that as a developer of the language it's quite niche position, however the language is then used by developers to create actual applications and they're affected by this, or rather the users are.
It also allows to be used from a C/C++ project so you can do all the required steps, but it's quite more involved compared to simply building the software for all platforms at once.
It's also not related to how popular my language is. It affects any language including C/C++ if you want to have unified cross-compilation to all supported platforms (which is quite typical for any serious project).
You may not be aware but Apple has put roadblocks for such usages as well, you can't rent a Mac VM for automatic builds, it has to be rented for 24 hours at minimum. Using someone's private Mac for building may not be a good idea for various reasons.
And then you compare it to other platforms that don't require anything like this. I even mentioned Android which shows that you can use signing to provide a security aspect without the gatekeeping aspect.
The issue is wider and basically it's an anticompetitive behavior of Apple to any competitor to Xcode.
A paid developer account would be required by every developer wishing to publish their cross-platform application also on MacOS. Even if it was free it would be an issue because it would require an extra registration and workflow that requires internet access and having Apple to arbitrarily decide that your application (or you as a developer) is banned.
Therefore instructions how the users can run the application is the only solution.
> How many unsigned apps are you downloading and running?
Enough for this to be annoying. Plenty of tiny tools don't pay for the privilege of doing free work, so aren't signed
> This is one of those features where the benefits seem to very obviously outweigh the drawbacks. 99.9% of users just aren't running unsigned software, so the moment that happens, it is most certainly malware.
You're obviously wrong with your made up stats (you don't need to be a power '1% user to want to install some a single useful unsigned app over the whole lifetime of using a Mac) and ignore the fact that part of the reason why it's 99% and not 88% is precisely because of features like this that make it harder to do so.
But there is an easy way to reconcile - make the old behavior configurable then the imaginary nonexisting 0.0000% users can continue without permanent disruptions
Quite a lot apparently considering how often I have to bypass gatekeeper.
I don't really see how the average user is positively affected by these changes - it's not like they will accidentally open terminal and enter random strings infinite monkey theorem style until they hit sudo spctl –master-disable.
Ctrl-click was at least possible to stumble over, but I see no good reason not to at least provide a .plist setting to re-enable that behavior. Except to bully more devs into getting signing certs.
The problem is not - and has never been - accidentally stumbling on insecure features. The problem is social engineering, where inexperienced users are guided by malware operators to run insecure software, either over the phone or through countless malware sites on the web that claim to solve their problems.
> This is one of those features where the benefits seem to very obviously outweigh the drawbacks
That has never been true. Neither for pro- nor casual users. This might be good for the bottom line of Apple, but I doubt that too, since they squander their reputation. This is non-engineers calling the shots, just like Jobs warned us about.
I do run quite a few unsigned apps and I don't even use a mac that often. This is just stupid...
This is one of those features where the benefits seem to very obviously outweigh the drawbacks. 99.9% of users just aren't running unsigned software, so the moment that happens, it is most certainly malware.
If you're developing software yourself, this isn't an issue either, since all the relevant toolchains, debuggers, etc., work just fine under this model. That's a supported workflow. The only thing that isn't supported is downloading some random unverified app bundle from who knows where and treating it as if you could trust it. You 100% can't.
And yes, I also believe that if an OSS project considers "muggles" their target audience, they should prioritize setting up code-signing. Consider it a service to their users. If the fee is a problem, it's important enough to spend the effort to find a way to finance it. If you can't find someone who is willing to put their name on it, you shouldn't ask people to run your software on their machines in the first place.