9 ms·
Also if you didn’t read the article, at least forHP: it was HP’s mistake and fully acknowledged by the company. Apple’s anti-malware system was actually just w
by an_d_rew 6y ago
Also if you didn’t read the article, at least forHP: it was HP’s mistake and fully acknowledged by the company.
Apple’s anti-malware system was actually just working exactly as designed.
- _qulr 6y ago> Apple’s anti-malware system was actually just working exactly as designed. That's an interesting take, considering that there was no malware involved, and many Mac users were left unable to use their printers.
- olliej 6y agoIt was an invalid signing certificate. One of the major reasons to revoke a certificate is that the private key is compromised. Hence anything signed with an explicitly revoked cert must be blocked.
- _qulr 6y ago> One of the major reasons to revoke a certificate is that the private key is compromised. The private key was not compromised. The proof of this is that Apple un-revoked the very same certificate. The cert is valid again.
- simonh 6y agoThat’s really not how private keys work. If I had stolen a copy of the private key, or if HP published it on their web site, un-revoking the certificate would still work fine.
- _qulr 6y ago> un-revoking the certificate would still work fine It's not a question of whether it would "work". If the private key was out in the wild, then Apple would never un-revoke the cert. That would be insane, because anyone could sign software with it.
- simonh 6y agoThey wouldn’t necessarily know.
- _qulr 6y agoWhy wouldn't they know? It seems that some people want to claim that Apple has to act based on a single email and is incapable of replying to that email or calling on the phone, when Apple has the phone # of every registered developer.
- simonh 6y agoHow could Apple possibly know for sure whether HP had actually lost a key or not? All they have to go on is what HP tells them. Anyway this could have nothing to do with key security. Apple gets certificate revocation requests all the time, to disable test builds, disabled badly bugged software versions, to disable software for licensing reasons. It’s the developer’s choice when or if they revoke a cert. Do you have any evidence this request was different enough to require escalated investigation compared to any other routine request? HP doesn’t seem to think it was.
- _qulr 6y ago> Apple gets certificate revocation requests all the time, to disable test builds, disabled badly bugged software versions, to disable software for licensing reasons. How do you know this? What is the evidence for this claim? The strange thing about this claim is that certificate revocation does not disable specific builds, it disabled every piece of software ever signed with the cert, so this wouldn't even accomplish what you claim it accomplishes.
- deleted 6y ago[deleted]
- simonh 6y agoYou just sign different builds with different certs. That’s how come this revocation only disabled particular HP drivers, not ever piece of software for the Mac released by HP.
- Xylakant 6y agoHP, the author of the software in question explicitly revoked the certificate, indicating that they no longer trust that the software they signed with it is secure. Yes, HP may have done that in error, but how can apple know or reasonably assume an error here and retain trust? No actual malware ot breach was involved in this case, but what is the system supposed to do if the org responsible for the software revokes the trust anchor? Continue just as if trust was still established? What if the certificate had actually been used to distribute malware? The system worked as designed, but HP needs to figure out how that to revocation happened.
- _qulr 6y ago> HP, the author of the software in question explicitly revoked the certificate HP cannot revoke the cert. Only the CA, Apple, can revoke the cert. HP can only request that Apple revoke the cert, but there was no reason for Apple to grant this request. See section 4.8 on certificate revocation: https://images.apple.com/certificateauthority/pdf/Apple_Developer_ID_CPS_v3.0.pdf https://images.apple.com/certificateauthority/pdf/Apple_Deve...
- JumpCrisscross 6y ago> HP can only request that Apple revoke the cert, but there was no reason for Apple to grant this request This is a security-usability tradeoff. Do you eagerly grant revocations, in the process protecting more users in cases of disaster but exposing yourself to the pain of false positives (like this one)? Or do you verify such requests, thereby making accidental revocations unlikely but increasing the time it takes for compromised software to get pulled? Given revocation is more easily reversed than fixing a compromised computer, I stand with Apple’s decision to revoke first and ask questions later. But this is a preference, nothing more. Based on how Apple has positioned itself with respect to privacy and security, I imagine this is not an uncommon preference among its customers.
- _qulr 6y ago> I stand with Apple’s decision to revoke first and ask questions later. There are only 2 reasons to revoke a code signing certificate: 1) The private key is compromised. 2) The owner of the certificate is signing malware. Obviously HP is not a malware author, so unless HP emailed Apple and said their private key is compromised, there's no good reason for Apple to revoke the cert. There aren't questions, plural, there's only one question.
- heavyset_go 6y ago> Apple’s anti-malware system was actually just working exactly as designed. This is something that Stallman[1] and others[2] have talked about for a while now. [1] https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html [2] https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html https://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
- beached_whale 6y agoStallman is from a time when you didn't have a billion people click yes on everything presented to them in order to play a game. Even in 2012 when the article was written, this was true. Or a plethora of fake AV that look as legit as the real stuff. It would be different if legitimate software that did what it implied/said and scam software were differentiable. Just like we don't allow unapproved vehicles to be driven on community roads.
- fortran77 6y agoI thought OSX was "secure by design" and that there was no malware on Macs. This is what Mac users are always saying. (For example, they say on Quora, that Mac viruses are never really seen in the wild: https://www.quora.com/What-is-the-reason-why-Mac-computers-do-not-get-viruses?no_redirect=1 https://www.quora.com/What-is-the-reason-why-Mac-computers-d... )
- olliej 6y agoWhich is why Apple introduced this kind of thing - to try and limit or block malware and viruses, etc. This is simply part of the many layers used to prevent viruses and malware from getting onto the system. Back in the days of PPC macs didn’t get viruses (because why bother? :) )
- fortran77 6y ago> Back in the days of PPC macs didn’t get viruses (because why bother? :) ) This is simply not true. Not sure what your motives are. https://lowendmac.com/2015/classic-mac-os-viruses/ https://lowendmac.com/2015/classic-mac-os-viruses/
- rgovostes 6y agoWe're talking about a 20-year-old operating system here, what motives could one possibly have? Classic MacOS never had widespread malware to the extent of Windows worms like Melissa or ILOVEYOU, a claim backed up by your link. It's very plausible that the reason for this was that with far more users, Windows was a more attractive target. There is a reason that Bill Gates wrote the Trustworthy Computing memo and not Steve Jobs. (I doubt MacOS was actually more secure by design at that time.)
- olliej 6y agoI was joking about the relative lack of value in targeting PPC era Macs.
- Talanes 6y ago
- fortran77 6y agoThen explain this: https://twitter.com/robbyrussell/status/1320787070369984512 https://twitter.com/robbyrussell/status/1320787070369984512
- lilyball 6y agoPresumably a certificate issue there too, just one that hasn’t been (publicly) diagnosed yet.
- olliej 6y agoThe comment explicitly stated that their comment was in the context of HP, not Amazon. HP revoked its own signing certs rendering their existing signed code invalid. That it took them days to re-sign and published fixed binaries is HP’s fault not Apple’s
- _qulr 6y ago> HP revoked its own signing certs rendering their existing signed code invalid. That it took them days to re-sign and published fixed binaries is HP’s fault not Apple’s No, HP requested that Apple revoke the cert. Inexplicably, Apple complied with this unusual request. Apple later un-revoked the cert after Mac users started reporting problems.
- aw1621107 6y ago> Inexplicably, Apple complied with this unusual request. Kind of curious: how closely do CAs look at requests to revoke certificates? Is there a general pattern? Or does it vary by CA?
- deleted 6y ago[deleted]
- jlgaddis 6y ago> ... how closely do CAs look at requests to revoke certificates? If they want to remain a CA, very closely! -- Per the (Server Certificate) Baseline Requirements [0]: > 4.9.1.1 Reasons for Revoking a Subscriber Certificate > The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: > 1. The Subscriber requests in writing that the CA revoke the Certificate; > ... The Code Signing BR's [1] have almost the same requirement. For code signing certificates, the CA "MUST*" revoke the certificate upon request "within one business day" (cf. 13.1.5, IIRC). I'm not sure if this particular certificate falls under those BR's or not, though (see my other comment). My guess would be that it does not. -- [0]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-... (PDF) [1]: https://cabforum.org/wp-content/uploads/baseline_requirements_for_the_issuance_and_management_of_code_signing.v.2.0.pdf https://cabforum.org/wp-content/uploads/baseline_requirement... (PDF)
- treesprite82 6y agoI worry that claiming the file contains malware and "will damage your computer", when it does not and will not, reduces how seriously users take those messages. This kind of message should be reserved for when malware has actually been detected. Would be fairer to say that the file is untrusted or potentially compromised.