This is not how macOS's code signing system works; e.g. it does not use .cire files.
I tried installing two of those applications and I can't reproduce the error myself, but I can see the "Error loading the application. Contact your administrator." message within the strings of /Applications/SecurID.app/Contents/MacOS/SecurID, along with references to ".cire" and some strings from the .cire file ("certificate", "hash"). edit: I also see references to SecTrustCreateWithCertificates, SecTrustEvaluate, and other related functions from Security.framework which are designed to validate certificates (but wouldn't be called directly by applications as part of standard macOS code signing).
Conclusion: They probably rolled their own custom code signing system, albeit one that uses the system trust store to verify certificates.
Nor is this related to Qt in any way. As far as I know Qt has never shipped .cire files as a way to sign the libraries. This is something the vendor of the software token library (stauto32) has done when embedding Qt.
Yep, nothing to do with GateKeeper as the article imply. If I had to guess, the security framework returns that the bundled certs are invalid, and that crashes the apps in question as they can't go forward ?
The "Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates" is actually dated March 2017 -- that was the date the community started realizing Symantec-signed certs should not be trusted.
That it took until August 2021 (~4.5 years) for that to actually affect trust for some things signed by Symantec certs... seems to say something about the ability of the ecosystem to actually act on removing trust from a CA? Like, if those apps won't open because it's been decided they can't be trusted... 4.5 years ago... and if in fact the apps were totally safe all along, why do they have to be rejected now? What should we take from this about how we understand code-signing and other uses of trusted certs and what they do for us?
No need for FUD. Symantec for many years led shoddy certificate validations. As a result of many audits finding inappropriately assigned certs the security community at large decided to just stop trusting them rather than continuously find issues in audits. That being said the audits had already been done, the harm of just immediately distrusting the CA wholesale would be orders of magnitudes more than the harm of whatever cert assignments slipped though the audits. A target date for the distrust needed to be chosen, at the same time the security community had been shifting to a maximum of <3 years on TLS certificates and about the same for code signing certificates with a preference they be even less than that farther in the future. The combination of these 2 goals to harden certificate trust going forward leads to the reasoning of why distrust it after all of these years, any certificates that were trusted prior to the distrust of new Symantec certs should be well expired.
Clearly quick reaction is possible if deemed necessary, new certs were almost immediately untrusted following concensus on action against Symantec. Should the situation have been more dire (e.g. a leak of the CA keys) a more dire course of action may have been warranted.
I'm not an expert on code signing, but wouldn't a code-signing cert with a 2 year lifetime mean that none of the apps it signs can be used for more than 2 years? Or is the code-signing valid as long as the signature was generated within the signing cert's lifetime?
Same problem as for document signatures, one needs a trustworthy timestamping service certifying the time of signature, so the client may check if the whole certificate chain might have been valid at the time. This means that you need far more extensive CA and revocation databases than for TLS, because you need to keep all that historical data.
What lead up to the reasoning for no longer having faith in Symantec-signed certs? Also what exactly made them so trusted/popular originally? Seems like you still see a lot of people using their certs
Regrettably Digicert has gobbled up not just Symantec assets, but also its business ethics and practices. Their undoing from a top notch certificate company to a dumpster fire that it is now was as rapid as it was devastating to watch.
> Citrix Workspace app replaces and extends the full capabilities of Citrix Receiver. Citrix recommends using the latest version of Citrix Workspace app to access workspaces.
Wait i don't get it, if some piece of software isn't signed or has invalid signature on MacOS, you don't get a prompt to run it anyway? It just says "nope"? If so, why would anyone ever use that system if you can't run apps of your choice?!
To be clear because i'm getting downvoted, i'm not opposed to signed builds as the default. For example the GNU/Linux distros i use, by default only distribute signed and reproducible packages. However, users are still free to run any program they want, which is in my understanding why we use general-purpose computers at all.
See also Cory Doctorow's talk "The coming war on general-purpose computation" from 2011 CCC conference.
I tried installing two of those applications and I can't reproduce the error myself, but I can see the "Error loading the application. Contact your administrator." message within the strings of /Applications/SecurID.app/Contents/MacOS/SecurID, along with references to ".cire" and some strings from the .cire file ("certificate", "hash"). edit: I also see references to SecTrustCreateWithCertificates, SecTrustEvaluate, and other related functions from Security.framework which are designed to validate certificates (but wouldn't be called directly by applications as part of standard macOS code signing).
Conclusion: They probably rolled their own custom code signing system, albeit one that uses the system trust store to verify certificates.