Historically speaking, OCSP was invented in a world where almost all DNS requests were also in cleartext. So if an attacker can observe DNS requests, then it's already "game over", and the cleartext of the OCSP request is almost redundant at that point.
It's worth noting a couple differences between HTTPS OCSP and Developer ID OCSP. First, with Developer ID, the only DNS request is for ocsp.apple.com, so the DNS request by itself doesn't expose any information about the Mac app being launched, unlike with HTTPS.
Second, the caching of Developer ID OCSP responses tends to be much much shorter than for HTTPS. Prior to Thursday's outage, the standard cache length for Developer ID OCSP responses seemed to be 5 minutes. (Apple seems to have raised it to 12 hours now.) In contrast, I just checked the latest response in my OCSP cache, which was for http://ocsp.digicert.com, and its validity is 7 days. So the rate at which Developer ID OCSP requests are made seems to be much higher than for HTTPS, and thus there's greater chance of exposure.
The static analysis, but also software component analysis tooling are really incredibly helpful though and should really contribute to releasing stable products as well -- it's not just here to satisfy your customers management types, it's there to actually make sure your tool doesn't have 5 RCEs active at any point in time.
I for one am happy companies ask about this type stuff, it's basic hygiene to keep control over your product's security, really, and the tooling really makes it a lot easier.
As someone that works for a SAST vendor I will say it's mixed. By the choices we make in what we support in languages and their dialects we can effect the ecosystem.
And at the same time, I have seen some terrible things that are picked up in code the first time they are scanned, that in theory should have been obvious but were missed for whatever reason.
It gets even worse when you're looking at included libraries.
Also, if you're using these tools, put in requests for new features and languages. This is how we know what customers want and where to focus resources.
I fail to see the point, as far as I know Apple has been vocal about iOS since WWDC and typically releases the OS relatively quick after events. The beta's been out and available for every iOS developer for months in order to prepare for this.
There's enough to rib on Apple on, but this really doesn't seem like one?
Apple has always given one week to use the golden master tools and build to run final tests on and submit your applications so they can be out before a million people try to install it on iOS 14. If your iOS distribution person is out on a camping trip for a couple days, you’re not hitting the deadline anymore. If you live in certain parts of the world where you wake up 7 hours after the event and Xcode takes fifteen hours to download, your don’t hitting the deadline anymore. There is absolutely zero reason why Apple had to do this.
I am in a slightly uncomfortable position of being _fairly_ sure none of our apps were broken under iOS14beta6 last week, but still assumed I'd get the traditional week between the new xCode GM and users getting iOS14 pushed out to them.
The article does mention Apple normally provides at least 3-4 days of Golden Master availability and usually a week+ before General Availability and that this is useful for various reasons. A lot of these are ecosystem failing that developers work around normally, when given enough time. Since it doesn’t seem to provide enough detail maybe I can fill in some missing context.
The App Store submission process is tightly integrated with the Xcode version used to build the app, if you want to be ready before users upgrade the App Store needs to be updated at least a few days before users automatically get the update. The App Store being updated to allow builds from the new version of Xcode is the most important issue. That only happened after 2pm ET on the 15th, and I’ve seen report their had been some delay (thankfully I only had to verify existing builds and didn’t need to submit a new build today). This means even if you had your build completely done based on pre Golden Master beta, and can either quickly reverify it or are comfortable just throwing it out there, you could only actually submit it today. Review times even without back and forth over policy points can take multiple days. Things will be worse for users over the next couple days.
iOS betas are frequently quite noisy and variable, if you test against an early beta you will need to retest against the actual GM with potential backwards compatible breaks each time. If you are either unlikely to have bugs or have enough capacity to spike doing a lot of work within a week you have the option of only doing the expensive thorough verification work against a single release.
There are still many reasons why real device testing with the production IAP environment are necessary. This is mostly a failure on Apple’s part to ever update their test environment’s capabilities and achieve parity with production. Doing this early requires you to be able to afford and have extra hardware of spend extra time having to upgrade and downgrade OS versions in order to verify the new version and continue to support live production hot fixes and support. A week between GM and GA is in the Goldilocks zone for developers, so that if they’re not doing a huge release to correspond with the iOS version they can upgrade test devices once, do one chunk of testing and fixing issues, and have their own build which will happily support both the old and new OS reviewer and live before users actually get the new OS.
Your example forgets to acknowledge that while there may have been good reasons for people to not be allowed to work remotely, COVID is a very pressing reason to do allow it, and the benefit of allowing people to work remotely vs getting absolutely nothing done or getting fined by the government for forcing people to come in is extremely obvious. So much so that the cons of allowing this have to be put aside, or remediated differently (which in some cases can even require investment).
It's a risk assessment that suddenly tilted the other way.
I don't agree with "everybody should work from the office" sentiments, myself, but I have seen this happen very clearly in many organizations.
Yes. From the looks of it, the CEO is just selling a previously-negotiated award on the date of acquisition. He has been awarded, then immediately sells roughly 70,000 shares a day over two days, along with exercising some options.
Table II shows that he still (indirectly) owns around 24 million shares of Class B stock and 130k options.
The filing notes that these trades are following a 10b5-1 plan, which is basically exactly that: you set up trades in advance so that you can make them without falling afoul of the insider trading rules.
I'd argue that if you're writing malicious privilege trampolines for operating systems, you could have very well predicted this would pop up and you get stressed out for it.
It seems a lot of the media is focused on the fact that people are being exposed to the virus. However, the Dutch are adopting a controlled way of doing this while protecting those at risk. All measures to limit contact are in place, in a big departure from what others who claim "herd immunity" are doing.
Any comparison to the (previously?) British approach where in the weekend even concerts weren't cancelled and people are still being forced to go to the office by their employers doesn't quite hit the mark.
OCSP is a good thing, and the web - and your signed applications - are better off with it.