4 ms·

You'd be right if the developers were distributing their apps on their own - once Apple has put up a service in the form of the App Store and are taking a 30% c

You'd be right if the developers were distributing their apps on their own - once Apple has put up a service in the form of the App Store and are taking a 30% cut out of every sale, it's their responsibility to keep it running. If that means detecting that many apps use incompatible OpenSSL and communicating with the developers to address that issue before rolling out SHA-2 cert, so be it - all competent services companies do things like these all the time. It's not as if there wasn't a way for Apple to detect this (if there wasn't then again it's their own fault) and it wasn't as if they couldn't have renewed with another SHA-1 cert for a few months until they figured out how to roll out SHA-2 one without causing a lot of people a lot of trouble.

tinalumfoil 11y ago
> It's not as if there wasn't a way for Apple to detect this Assuming developers were statically linking the old OpenSSH versions, how would Apple detect this? Are developers forced to reveal source code before submitting to Apple? Does OSX executables have some format to specify what libraries it's using? I don't develop for OSX so I'm genuinely curious.
- JoachimSchipper 11y ago
  Apple is able to scan iOS code for e.g. use of nonpublic API's; certainly they can grep a binary for a recognizable chunk of OpenSSL code, too. (Neither the iOS scans nor the OpenSSL scan will catch everything, of course.)
  - joosters 11y ago
    A recognizable chunk of OpenSSL code? It could be any statically linked and custom-compiled version, that's millions of possible versions, once you take into account compile options, optimisation levels and linking techniques. Good luck grepping for it! Even if the version number is in there somewhere, there's probably all kinds of false positives that you would hit. Plus, it could be due to other SSL libraries, not just OpenSSL. In short, there's no realistic way to do what you are asking.
    - lstamour 11y ago
      I disagree. Finding recognizable chunks of code is what antivirus software does every day. And while they're not perfect, the OpenSSL code in question here isn't exactly trying to hide, unlike viruses in real life. This was obviously an oversight, but I would expect that after this, they run occasional tests of the app verification process across all apps, and not just verify the apps themselves don't crash. In fact, they must be doing this kind of thing right now -- how else could they contact all the affected developers?
    - dikaiosune 11y ago
      I'm not terribly familiar, but these guys appear to be achieving some pretty sophisticated introspection into binary library usage: https://sourcedna.com/ https://sourcedna.com/ It would be interesting to see this applied to non-mobile apps.
    - vsl 11y ago
      Not what the parent said, true, but you can test for this easily: launch the app, see if it terminates with exit code 173 (receipt check fail) in the first few seconds if fed SHA-2 receipt but not the old SHA-1 one. Won't catch all (apps may validate later during runtime), will catch enough to give you some idea about the scope.
- revelation 11y ago
  ...by testing the apps still run?
- blinkingled 11y ago
  For software of any complexity, and web apps specifically - you don't just deploy changes in Production - you'd need to have some type of test environment - staging, pre-production whatever you wanna call it. The test env is typically a replica of Production env - you deploy your change in test and point your clients to it. Sounds complicated but once you have the env setup done and replication processes defined it's dead simple.
- vacri 11y ago
  For a company the size of Apple (with their exhaustive resources and long history), a comprehensive preproduction test that tests the action of upgrading a lot of the software... that should be within their capabilities. As in "don't just approximate what the users will be doing, actually do what the users will be doing".
digi_owl 11y ago
Apple, third party friendly? Cold day in hell...
tracker1 11y ago
By comparison, Salesforce within this last year disabled a bunch of cipher options on it's HTTPS connections, and communicated it to their developers pretty well, even though most shouldn't/wouldn't have been affected except for edge cases... Compared to this mess with a much larger impact.

tinalumfoil 11y ago

> It's not as if there wasn't a way for Apple to detect this Assuming developers were statically linking the old OpenSSH versions, how would Apple detect this? Are developers forced to reveal source code before submitting to Apple? Does OSX executables have some format to specify what libraries it's using? I don't develop for OSX so I'm genuinely curious.

JoachimSchipper 11y ago
Apple is able to scan iOS code for e.g. use of nonpublic API's; certainly they can grep a binary for a recognizable chunk of OpenSSL code, too. (Neither the iOS scans nor the OpenSSL scan will catch everything, of course.)
- joosters 11y ago
  A recognizable chunk of OpenSSL code? It could be any statically linked and custom-compiled version, that's millions of possible versions, once you take into account compile options, optimisation levels and linking techniques. Good luck grepping for it! Even if the version number is in there somewhere, there's probably all kinds of false positives that you would hit. Plus, it could be due to other SSL libraries, not just OpenSSL. In short, there's no realistic way to do what you are asking.
  - lstamour 11y ago
    I disagree. Finding recognizable chunks of code is what antivirus software does every day. And while they're not perfect, the OpenSSL code in question here isn't exactly trying to hide, unlike viruses in real life. This was obviously an oversight, but I would expect that after this, they run occasional tests of the app verification process across all apps, and not just verify the apps themselves don't crash. In fact, they must be doing this kind of thing right now -- how else could they contact all the affected developers?
  - dikaiosune 11y ago
    I'm not terribly familiar, but these guys appear to be achieving some pretty sophisticated introspection into binary library usage: https://sourcedna.com/ https://sourcedna.com/ It would be interesting to see this applied to non-mobile apps.
  - vsl 11y ago
    Not what the parent said, true, but you can test for this easily: launch the app, see if it terminates with exit code 173 (receipt check fail) in the first few seconds if fed SHA-2 receipt but not the old SHA-1 one. Won't catch all (apps may validate later during runtime), will catch enough to give you some idea about the scope.
revelation 11y ago
...by testing the apps still run?
blinkingled 11y ago
For software of any complexity, and web apps specifically - you don't just deploy changes in Production - you'd need to have some type of test environment - staging, pre-production whatever you wanna call it. The test env is typically a replica of Production env - you deploy your change in test and point your clients to it. Sounds complicated but once you have the env setup done and replication processes defined it's dead simple.
vacri 11y ago
For a company the size of Apple (with their exhaustive resources and long history), a comprehensive preproduction test that tests the action of upgrading a lot of the software... that should be within their capabilities. As in "don't just approximate what the users will be doing, actually do what the users will be doing".

digi_owl 11y ago

Apple, third party friendly? Cold day in hell...

tracker1 11y ago

By comparison, Salesforce within this last year disabled a bunch of cipher options on it's HTTPS connections, and communicated it to their developers pretty well, even though most shouldn't/wouldn't have been affected except for edge cases... Compared to this mess with a much larger impact.