> There is no need for an online connection. There is some misunderstanding of what the certificate is. It has no online connection dependency. It is a developer certification that is extremely common on macOS apps. The cert only caused an issue because we let it expire. We now have strict processes in place to maintain the certification
The article also says that the expired certificate breaks auto updates. What kind of certificate is this exactly?
Without a signature, Gatekeeper will throw up a dialog saying "This app could contain malware" or something to that effect.
If you're using other libraries, such as the Sparkle Framework (a popular macOS Objective-C(?) library for updater logic), I believe you have to sign those as well.
That said, the autoupdater may have technically been a second .app bundled within the main one and trying to launch it resulted in a failure to recognise the certificate.
As far as I understand, certain compilers such as Go are signed themselves and technically fiddle with created binaries in an above-board way that they pass Apple's requirements, otherwise you would have to explicitly allow them to run every time.
Having signed some open-source apps myself though, I didn't realise that certificates could retroactively expire. I haven't tried but I assumed that you would just be unable to sign new versions.
Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?
If you compile hello-world.c into a binary then it will have a placeholder (ad-hoc) signature that was signed by an "empty" key that can never expire.
The Go compiler isn't doing anything special. By default all binaries are signed this way unless they were compiled with the explicit intention of App Store distribution.
Yes of course apps will continue to operate after the signing cert expires, and this is documented by Apple in several places. It would be absolutely insane if apps stopped working, because all Developer ID signing certs expire after 5 years.
The valid dates for code signing certificates apply, naturally, to signing. You can't sign an app anymore with an expired certificate, but if an old app was signed with a cert that was valid at the time of signing, then the app will continue functioning forever.
This issue was just a dumb screwup by Logitech. If apps stopped functioning when the signing cert expired, you'd see Mac apps dying all the time.
OP said something confusing about the Go compiler, so I was only added clarification for that one statement.
You walked by half listening to a conversation, stuck your head in the room and said something tangentially related but more confusing.
There are distribution and development certificates that can all be used for signing a binary. Different rules for each, and there's also auto-signed (com.apple.provenance). It's all documented on Apple's website if you want to read more about it. But I suspect you already know this and are just trying to pick a fight.
This is a gross mischaracterization of the thread. I replied to spondyl, not to you. Then you replied to me, so if anyone was "trying to pick a fight" involving me, it was you.
The crucial point is this: there are no builds that expire on macOS. Developer ID signed builds do not expire. Ad hoc signed builds do not expire. When the Developer ID code signing certificate expires, it cannot be used to sign new builds, but the old builds last forever. Build expiration is not a thing in any case.
So when spondryl asked, "Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?" and you responded "No, sorry. That's not what I'm saying." that was actually confusing, not what I said.
The only reason the Logitech software died is that Logitech itself was doing some custom and badly designed validation above and beyond anything that macOS itself does. Your mention of App Store apps and CLI tools was itself a tangent and completely irrelevant to the issue.
Always hated Logitech Options bloatware, why should the software drain my battery, phone home, and require screen recording permission just to emulate a keystroke when I push a button on the mouse?
I enjoyed my trip to Micro Center today to finally ditch Logitech after those buttons stopped working. Put up with Options for over a decade because at least it did the one thing I needed.
I love the hardware. Software sucks. When this broke today, I just downloaded SteerMouse and updated my license. Never going back to the Logitech software.
The downside of ridiculously overcomplicating the task. Certificates for IPC? So if somebody runs a virus on the computer they can't tell that one program told the other that you want your RGB to be brighter?
The point of certificates is that they prevent things like MITM attacks on updates that replace the legitimate app with a malicious version. They also prevent you from installing fake software if you know how to use them, e.g from a malicious ad that looked just like the real Logitech site. They're also requited for all mac app store apps, it's not really about the specific use case of the app.
Maybe? Maybe not? My point was that there are perfectly legitimate reasons to have tight security on software that deals with input devices. In the age of sandboxed software I wouldn't be surprised if you can't just get all key presses as non-interactive background software, or if you could get them by reading them from Logi Options.
They say on Reddit: https://old.reddit.com/r/logitech/comments/1q66q1l/just_real...
> There is no need for an online connection. There is some misunderstanding of what the certificate is. It has no online connection dependency. It is a developer certification that is extremely common on macOS apps. The cert only caused an issue because we let it expire. We now have strict processes in place to maintain the certification
The article also says that the expired certificate breaks auto updates. What kind of certificate is this exactly?
This will be a standard Apple Developer code-signing certificate used in the signing and notarision process: https://support.apple.com/en-nz/guide/security/sec3ad8e6e53/...
Without a signature, Gatekeeper will throw up a dialog saying "This app could contain malware" or something to that effect.
If you're using other libraries, such as the Sparkle Framework (a popular macOS Objective-C(?) library for updater logic), I believe you have to sign those as well.
That said, the autoupdater may have technically been a second .app bundled within the main one and trying to launch it resulted in a failure to recognise the certificate.
As far as I understand, certain compilers such as Go are signed themselves and technically fiddle with created binaries in an above-board way that they pass Apple's requirements, otherwise you would have to explicitly allow them to run every time.
Having signed some open-source apps myself though, I didn't realise that certificates could retroactively expire. I haven't tried but I assumed that you would just be unable to sign new versions.
This is only applies to App Store published .app bundles. Does not apply to binaries you compile yourself or non-app binaries like cli tools
Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?
No, sorry. That's not what I'm saying.
If you compile hello-world.c into a binary then it will have a placeholder (ad-hoc) signature that was signed by an "empty" key that can never expire. The Go compiler isn't doing anything special. By default all binaries are signed this way unless they were compiled with the explicit intention of App Store distribution.
And the above does not apply to .app bundles.
Yes of course apps will continue to operate after the signing cert expires, and this is documented by Apple in several places. It would be absolutely insane if apps stopped working, because all Developer ID signing certs expire after 5 years.
The valid dates for code signing certificates apply, naturally, to signing. You can't sign an app anymore with an expired certificate, but if an old app was signed with a cert that was valid at the time of signing, then the app will continue functioning forever.
This issue was just a dumb screwup by Logitech. If apps stopped functioning when the signing cert expired, you'd see Mac apps dying all the time.
This only applies to distribution certificate signed apps, not true in the general sense.
> not true in the general sense.
What does that even mean? What exactly are you saying is not true?
It's not at all helpful or informative to keep saying "does not apply," as if that meant anything by itself.
OP said something confusing about the Go compiler, so I was only added clarification for that one statement.
You walked by half listening to a conversation, stuck your head in the room and said something tangentially related but more confusing.
There are distribution and development certificates that can all be used for signing a binary. Different rules for each, and there's also auto-signed (com.apple.provenance). It's all documented on Apple's website if you want to read more about it. But I suspect you already know this and are just trying to pick a fight.
This is a gross mischaracterization of the thread. I replied to spondyl, not to you. Then you replied to me, so if anyone was "trying to pick a fight" involving me, it was you.
The crucial point is this: there are no builds that expire on macOS. Developer ID signed builds do not expire. Ad hoc signed builds do not expire. When the Developer ID code signing certificate expires, it cannot be used to sign new builds, but the old builds last forever. Build expiration is not a thing in any case.
So when spondryl asked, "Just to be clear, you're saying that .app bundles (and CLI tools) distributed outside of the App Store (and CLI tools) will continue to operate once the expiration date of the signing certificate has passed?" and you responded "No, sorry. That's not what I'm saying." that was actually confusing, not what I said.
The only reason the Logitech software died is that Logitech itself was doing some custom and badly designed validation above and beyond anything that macOS itself does. Your mention of App Store apps and CLI tools was itself a tangent and completely irrelevant to the issue.
So what happens when I codesign with the the --expires flag?
Do you? Does anyone? I see that the flag exists, but I've never seen anyone use it. That would seem a bit insane.
Yeah, it’s used for dog fooding or private distribution. It’s also used on iOS side-loading and test flight builds.
It's probably the dev cert for macOS.
The code signing certificate for macOS apps.
Always hated Logitech Options bloatware, why should the software drain my battery, phone home, and require screen recording permission just to emulate a keystroke when I push a button on the mouse?
I enjoyed my trip to Micro Center today to finally ditch Logitech after those buttons stopped working. Put up with Options for over a decade because at least it did the one thing I needed.
I love the hardware. Software sucks. When this broke today, I just downloaded SteerMouse and updated my license. Never going back to the Logitech software.
In my frustration I didn’t even think to look if there was a third party solution.
Looks like that would do the one thing I need, and I’m finding the grass to be just as brown with Razer Synapse is it is with LogiOptions.
Just install something like "Better touch tool" you'll get the functionality (and more) without the bloat.
To be fair, it lack some functionality, like mapping a single modifier to a button
The downside of ridiculously overcomplicating the task. Certificates for IPC? So if somebody runs a virus on the computer they can't tell that one program told the other that you want your RGB to be brighter?
The point of certificates is that they prevent things like MITM attacks on updates that replace the legitimate app with a malicious version. They also prevent you from installing fake software if you know how to use them, e.g from a malicious ad that looked just like the real Logitech site. They're also requited for all mac app store apps, it's not really about the specific use case of the app.
I'm not understanding the relevance to IPC. What do updates and the app store have to do with inter process communication?
Or they can't write a piece of software that sees your keypresses in the background?
Key loggers do not need to attack Logitech software to work, so I don't see the relevance
Maybe? Maybe not? My point was that there are perfectly legitimate reasons to have tight security on software that deals with input devices. In the age of sandboxed software I wouldn't be surprised if you can't just get all key presses as non-interactive background software, or if you could get them by reading them from Logi Options.
Related: https://news.ycombinator.com/edit?id=46548904