271–280 of 335 posts
Windows signing is a ripoff, $500/year you're getting nothing. Your certificate is not trusted. You have to "get reputation for it" before Windows Defender would stop giving users warnings. Also, renewing certificate is not a thing. Every time you have to get a new one, with same story of "reputation" again. [1] https://www.digicert.com/order/order-1.php
At least Windows lets you install pretty much whatever you want. None of this nonsense is mandatory.
This is all in stark contrast to macOS's System Integrity Protection, which I can turn off once to never be bothered again.
I understand why Microsoft would enforce higher standards on drivers which can touch the kernel. But, the same fundamental problem applies: it isn't reasonable for non-profit, open source developers—many of whom I consider perfectly trustworthy—to pay hundreds of dollars for a certificate! Let me make the final decision about who I trust. It's my machine—I even built it myself!
The primary place I run into this problem is with drivers to support weird video game controllers.
---
† You can enable a "testsigning" mode via the command line which persists across reboots, but this only seems to work for certain drivers. If anyone can explain why it sometimes works, I'd appreciate it, as my research has never turned up anything.
Earlier quoted context omitted.
> Funny thing about trust: I trust a developer who drops some $$$ on a code-signing certificate more than I trust a developer who doesn't. Even if it's just $20. Why? If I expect to make four figures on spreading malware/adware, and I can assuage the nerves of people like you by spending two or three figures on a certificate, I'm going to buy the certificate and make it look all nice and pretty and take your money. >…
They didn't say they trust the developer who spends the money absolutely , they said they trust the developer who spends the money more than they trust one who doesn't. Which is fair -- as you note, not every scammer will be scared off by the need to spend some money to pull the scam off; but some will, so the ratio of legitimate developers to illegitimate ones will be higher in markets where there's some cost to ent…
Windows signing is a ripoff, $500/year you're getting nothing. Your certificate is not trusted. You have to "get reputation for it" before Windows Defender would stop giving users warnings. Also, renewing certificate is not a thing. Every time you have to get a new one, with same story of "reputation" again. [1] https://www.digicert.com/order/order-1.php
Wait are you saying that Apple Developer program for 99$/year is actually quite a good deal in comparison? I will definitely pull this thread out next time someone complain that Apple is too expensive and that they are milking the poor developers...
(The only acceptable price is $0, IMO.)
Earlier quoted context omitted.
You can deliver unsigned Windows apps.
You can deliver unsigned Mac apps too, just not on the MAS.
[0] https://www.macworld.com/article/3140183/how-to-install-an-a...
Earlier quoted context omitted.
You can deliver unsigned Windows apps.
You can deliver unsigned Mac apps too, just not on the MAS.
I created a huge rant on code signing certificates here: https://www.youtube.com/watch?v=mwuk0E-tfeg It's a nightmare. Complete scam. I needed this for Polar: https://getpolarized.io/ Mind you... it's Open Source but I still want my users to be able to download it without warnings. No joke - it took me 2 weeks to get the CSC with about 4 hours per day working on just this CSC issue. It's just a labyrinth of insanity…
There is also the issue that an EV cert has to live on a USB dongle and be "logged into" with some utility before being available for signing. Logging out the current user or even allowing the screen to sleep will lock the cert again. So, for automating signed builds, the only option is to leave the machine logged in and unlocked at all times, clearly obviating much of the "security" gained from all those restriction…
First, we ran Windows under Parallels on a Mac Mini (we needed the build machine to handle Mac builds as well). I think I set the Windows VM to never lock the screen or sign you out, but the physical Mac would lock its own screen as usual. You could set things up the same way with a VMware VM running on a Windows host.
Then the only problem to solve was how to type in the signing password every time the certificate utility popped up its password dialog.
Like so many things on Windows, it was AutoHotkey to the rescue! I wrote a little 5-10 line AutoHotkey script to watch for the password dialog opening, type in the password and hit Enter.
Bingo, we had fully automated EV code signing for our Windows builds.
You mentioned that logging out or letting the screen go to sleep would lock the cert. I don't quite remember it that way, but I could be remembering wrong. It seemed that the certificate utility simply wanted a password typed into its dialog for every code signing.
So it may be that this AutoHotkey setup would also work with the cert utility running on a physical Windows machine with normal screen locking. In any case, it definitely worked great in a VM.
Of course this meant that we had to store the signing password in plain text inside the VM, but that was a lesser evil than requiring someone to babysit the machine whenever we pushed a build.
Earlier quoted context omitted.
Of course but all of the above mentioned can still happen and does happen today with all security measures in place. With the added benefit that we must ask permission of a private entity to release an app and we must pay 30% of our profits to the gatekeepers /s I think I like the old way better.
You don't have to do anything you don't want to. No one is forcing you to develop for those platforms. Your old way still exists. Approximately all real world users demonstrably prefer the new way, but if you're set on your old way you can still write software for macOS and Windows. It will pop a warning, but you can make it run anyway. Give your users instructions for bypassing those warnings. If you trust them to m…
If your selling software, this probably isn't a good strategy. However, I consider it perfectly reasonable for software that's being created in one's spare time and offered for free.
(I think the current situation we have on Windows / macOS is a perfectly fine balance, btw—except for drivers, where installing unsigned copies is way too difficult)
Earlier quoted context omitted.
"the good old days", as in, "the days when the average person had no freaking clue if something was safe, but installed it anyway because it's completely unreasonable to expect them to do otherwise"? If your security model is "do your research" then you're going to fail.
Just because someone certifies that it wasn't tampered with and comes from who it says it does doesn't mean it is safe.
Earlier quoted context omitted.
> most users won't bother checking it That's also zero effort, though. I don't care if users aren't checking; I published the hash, so I'm covered. I am not liable for the behavior of random materials, even if they happen to be tampered versions of something I produced. Even if you make a signed and certified installer, someone can turn it into a malicious unsigned one and people will install anyway. They will click…
Here's an example of how the signature can help a user [0]. If fewer people fall for it that's still a win. Your argument is that if a mechanism isn't perfect we shouldn't be using it at all. Well seatbelts and airbags also don't guarantee anything but still save people. Security is additive, no layer is perfect but put enough of them together and you can be relatively safe. [0] https://arstechnica.com/information-te…