Hacker News new | past | comments | ask | show | jobs | submit login
Mac Store Apps Stopped Working Due to Expired Security Certificate (techcrunch.com)
295 points by jonas21 on Nov 13, 2015 | hide | past | web | favorite | 152 comments



The story has been updated with the following:

"Apple issued a new, stronger (SHA-2) Mac App Store certificate in September, before the older (SHA-1) one expired, as planned. The new Mac App Store certificate was using the current, strong SHA-2 algorithm. However, some apps were running receipt validation code using very old versions of OpenSSL that don’t support SHA-2.

OpenSSL started supporting SHA-2 in 2005, which is why Apple didn’t foresee this issue."


This needs to be upvoted, and the title changed. Turns out it was due to developers using incredibly old security code. Rather than an expired certificate.


Yup, this changes my own point of view from "Gee Apple what a blunder" to "Some developers can be really dumb".


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.


> 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.


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.


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.)


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.


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?


I'm not terribly familiar, but these guys appear to be achieving some pretty sophisticated introspection into binary library usage:

https://sourcedna.com/

It would be interesting to see this applied to non-mobile apps.


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.


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".


...by testing the apps still run?


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.


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


Apple built a lame DRM system, tossed out some half-baked sample code, and then told third parties "OK, you guys go implement this yourselves" without even so much as providing a library to help with the hard parts. Then they made a pretty substantial change without even checking to see if all of these one-off third-party implementations could deal with it.


Given that OpenSSL has supported SHA-2 since 2005, and the Mac App Store was announced in 2010, then released in 2011, I'm really not sure you can blame Apple for thinking it'd be reasonable to expect App Developers to not be using 5 year old versions of dependencies.


Why not? When you're running a service like this, thinking instead of checking is not a wise move.

How much time would it have taken to whip up a script that just tests all of the apps in the store? Even if it's a week of an engineer's time, that seems worthwhile. Testing whether the apps in the store actually run when presented with a valid receipt should already be automated anyway.

I'm looking through Apple's guidance here:

https://developer.apple.com/library/mac/releasenotes/General...

The only thing they say about which version of OpenSSL to use is that you need to bring your own and not rely on the one that ships with the OS, because Apple is still shipping a version of OpenSSL from 2005. They do not say anything about which version of OpenSSL you need to use or what capabilities it needs to have.

I bet a lot of people were using Apple's OpenSSL for this originally, and when it was deprecated the path of least resistance would have been to bundle the same version Apple ships.


To be clear Apple's OpenSSL (currently 0.9.8zg) supports SHA2 despite its deprecated status. You can't link against it in El Capitan any more since they stopped shipping the development headers, but getting an OpenSSL that doesn't support SHA2 is actually somewhat challenging (You'd either need an OpenSSL compiled with OPENSSL_NO_SHA or OPENSSL_NO_SHA256 or one that predates 0.9.7h).

None of that excuses Apple not checking this of course. Security.framework can do all this validation -- did they not historically provide code samples on how to do this without linking an external library?


Sorry, I didn't mean to imply that their ancient OpenSSL doesn't do SHA-2, although I had no idea either way. They just say you can't use it because it's deprecated, and therefore off limits to App Store apps.

Historically, I believe the code samples were more or like the ones in the link I posted. I don't believe they ever posted anything that showed how to use Security.framework for the heavy lifting. I think they wanted to get everybody to bring their own code to make it so you couldn't pirate every app with a patch to one shared library.


App Store was introduced with Snow Leopard, when it was not depreciated.


Interesting, they use a version of OpenSSL that will go EOS at the end of the year? [1] It wouldn't support TLS 1.1 or 1.2, either, unless they've hacked that into their version.

[1] https://www.openssl.org/policies/releasestrat.html


It's not used, exactly. It's more of a historical accident.

Way back when, Apple shipped OpenSSL libraries as part of the OS and included them in the SDK. Naturally, some apps were built that used them.

Then Apple discovered that they couldn't really upgrade the OpenSSL they shipped with the OS, because OpenSSL doesn't maintain binary compatibility. They could ship a new version, but they were stuck shipping the old version as well, and the new version would suffer the same fate.

So instead, they reimplemented what they saw as the important functionality, shipped that as CommonCrypto and Security.framework, and deprecated OpenSSL to try to get people to stop using it. But they still ship it with the OS, because they don't want to break whatever apps do still use it. And they can't upgrade it, because that would defeat the whole purpose of shipping it.


Even today Mac OS X still ships with a copy of OpenSSL 0.9.7 for that reason. I wonder when exactly it was last updated.


No, it does not ship with 0.9.7. It ships with 0.9.8zg, the absolute latest in the 0.9.8 series. It is unfortunate that 0.9.8 is shipping at all (as it has numerous issues), but Apple has removed the development headers in El Capitan so nothing "new" can link against it now (although apps compiled against it on 10.10 and earlier can still use it). It will be interesting to see what Apple does when 0.9.8 is officially EOL at the end of this year. They may choose to backport fixes (if necessary) or they may just ignore it until 10.12 comes out and they decide to fully remove it.


I am talking about the multiple versions shipped for compatibility with old apps. It is not easy to access, but look for /usr/lib/libssl.0.9.7.dylib I think. I think it is used for apps compiled using Leopard or older SDKs, which I hope no App Store apps are using, but... BTW, back in the PowerPC days they even used to ship with the even older 0.9.6 (only got rid of it when Rosetta was killed).


Ah, yes, those are indeed shipped for ABI compatibility with old apps. Chances are that was last updated the last time 0.9.7 got a release, which would be Feb 2007 I believe (0.9.7m).


I think Apple later patched it to for example disable renegotiation I think.


Doesn't matter - if you roll out a service, your number one priority is to keep the users happy by keeping your service running. And there's something called testing too - it's not like it was rocket science for Apple to detect problem apps and get that sorted before the SHA-2 rollout. They are taking a 30% cut for crying out loud.


They could even do something really crazy like telling everybody about the change in advance so third-party developers could double-check their code and make sure it still worked.


Yes! Communication is the first measure to try before anything technical as a second line of defense - but that's not a part of Apple's DNA :)


The expiration date is part of the certificate description. Events like this happen day-in, day-out. "Telling everybody" is not the solution, comprehensive testing is.


The problem wasn't simply the expiration date, but also issuing new certificates with SHA-256 instead of SHA-1. That's a big change you ought to tell developers about when it's their software that had to deal with those certificates.


I wish we could find a way to fix this "old SSL library/configuration" category of bugs across the board.

Neither OS distributors, nor app makers, nor sysadmins seem to be uniformly good at (or interested in) staying on top of this, and it means users get unreliable security.


The article makes it sound like this is now resolved, but it isn't.

One of my Macs is stuck on Snow Leopard. On Lion & El Capitan, I sign in to the App Store again and it's resolved. But on Snow Leopard, it doesn't display the sign-in error like 10.7 - 10.11 do. It just complains and tells you to redownload the apps from the App Store.

But I can't. Apple doesn't let you download old versions from the Mac App Store. Byword 1.5.2 is the last version that works on 10.6, the current 2.x version requires 10.8. Similarly with Tweetbot, Mémoires, Space Gremlin, etc. Unless Apple magically allows old downloads, I don't think this can be fixed without Apple patching Snow Leopard. I'm not going to hold my breath.

It really seems like Apple has permanently broken my purchased apps.


OS X 10.7 is unsupported as of October 2014, so I doubt Apple will be doing anything special to fix it. It still sucks that there's effectively a time limit on the software on your machine though.


Luckily, I'm able to install Windows 10 via Boot Camp on the same machine and it works really well. End-Of-Life on Windows 10 security updates is October 2025, so the machine still has plenty of life in it. It just probably won't spend much time in the Apple ecosystem anymore.


Exactly what I did on my rMBP. Thankfully it works great - the trackpad experience is not ideal but that's a small annoyance compared to not having to deal with OS X. (It feels slower for normal tasks like window switching and painting etc. but my big issues are with SMB and WiFi along with things like this App Store breakage and the constant yearly pressure to upgrade to get security and bug fixes. It's not worth it.)

Actually the other reason for me also was Visual Studio - I develop quite a bit of C/C++ code and recently moved to developing an Android app - VS Emulator for Android is a godsend - you can't do those things on OS X without trouble - Xcode is buggy and the emulator with HAXM is crashy although that's Intel's fault.


Oh my. You bought DRM'd apps and now the DRM comes to bite you. Lesson learned? Boycott companies DRM'ing.


I've just sent you an email with a link and license for non-App Store version of Mémoires that works with Snow Leopard.


This is awesome, thank you so much!

And bonus points to Dmitry of Coding Robots <https://www.codingrobots.com> for offering this, because this was partly my own fault. I'd moved and archived the app, but not actually deleted it, and this didn't clear the App Store install receipt from my computer. I had to actually move the app to the trash for OS X to remove the install receipt. Once I did, the App Store let me reinstall Mémoires again, now code signed until Feb 7 2023. But I'll now be using the non Mac App Store version Dmitry just sent me.

[No such luck with Byword though, as I still can't download the old Snow Leopard version of the app from the App Store.]


Are you really sure about that? I thought that the App Store lets you download the latest version of apps you purchased that are supported on your OS from the "purchased" tab.


Afraid not. When I click on the Install button in the Purchased tab for those apps it tells me "[App name] can't be installed on this computer, because a 64-bit Intel processor is required" or "[App Name] can't be installed on Macintosh HD, because Mac OS X version 10.7 or later is required."

(Thank you for trying to help, though!)


Reportedly, that only works for iOS apps, not OS X ones.


I think "grace periods" should be a lot more common in software. Not every issue is the user's problem, and not every problem requires a drastic response.

For instance, they could have:

- Quietly noted the issue in a file somewhere, waited 24 hours, and checked again.

- If the problem was still present after 24 hours, they could have made the software discreetly submit a problem report to Apple (but still launch and work correctly).

- After 48 hours, they could issue a background notification to the user indicating that a problem has been detected in the program and to “please check for updates on the App Store”; but again, continue to work correctly.

Or in other words, there were only about a half dozen more reasonable things they could have done that didn't involve an Amazonian break-things-immediately type of response.


But if a program keeps running with an invalid security certificate, what is the point of having the certificate at all? If the practice is 'let the program with an invalid cert run silently for 2 days', then you aren't gaining any security at all. Malware could do everything it needs in 48 hours.


This particular bit of verification has nothing whatsoever to do with security. It's an error in purchase verification. If the practice is to let the program run with an invalid purchase receipt for two days, then you're just giving pirates a free two-day trial. Some people might see that as a problem, but I personally value the experience of paying users over inconveniencing pirates.


There's minimal security risk in allowing a formerly-validated piece of software to remain usable so long as it is not modified by any updates that cannot be verified by a current certificate.

Being this strict at the cost of usability isn't about security, it's about DRM and making sure you don't get to keep using your software after the subscription has expired.


But these apps aren't paid for by subscription.


Every app store purchase is a subscription. If it were a purchase, you could resell. As you can't, it's clearly a rental model with payment up-front. Apple decides when they pull the plug on your 'purchase'. The same thing applies to google play, windows store, steam, etc... The era of buying software is drawing to a close. From here on out it's rental only, unless you follow the advice of rms and use libre software exclusively.


There is a fair amount of difference between "an invalid cert" and a certificate that is valid apart from having expired a day ago.


Then why not push the expiration back 2 days, which is effectively what the OP is proposing.

A reasonable thing to do instead is to give a warning like "The security certificate for app X is expiring in two days. Please update it" or something like that.

OR don't have expiration dates on a cert, if that is preferable.


You have to realize that "start warning the user two days before the expiration date" and "start warning the user on the expiration date, but give them a grace period of two days" is just an implementation detail, no?


I think this is a great example of certificate expirations working well and as expected. Clients should update their damn software.


Well as someone else pointed out, Snow Leopard users literally can't.


...and this is why long term support is so important. That was literally the best released OS of all time, it's a shame it's falling off the end of the train.


Software doesn't fall off the Apple train, it's bound, gagged, and shot in the back of the head before being thrown off while on a bridge over deep water.


For example, you could have a parameter on the cert that caused clients to probabilistically reject it 1/10000'th of the time when in the last month of the cert's lifetime (so there are really two deadlines, the probabilistic-failure one and the total-failure one). That would give you the same warning about the coming total failure, without hindring as many users.


Or you just set a calendar reminder up ahead of time or have something like nagios set up to bug you when you get close. Why make "expiration date" not mean expiration date?

If my driver's license expires and I drive, I'm breaking the law. Sure, a judge or cop could be lenient, but there is no legal requirement (or justification?) for them to do so.


You can generally keep driving a car for a few days after failing an inspection so you can take it to get fixed with minimal issues. EX: Cracked headlight, increases risks of a problem in the long term, but if it's working right now it's generally not an actual issue.

IMO, tossing up a quick warning for the next month after expiration seems like a reasonable solution. Sure, something failed, but expired certificates are almost never a sign of a real problem.


> You can generally keep driving a car for a few days after failing an inspection so you can take it to get fixed with minimal issues.

How does this have anything to do with the issue? With a mechanical object, you have risks and probability of failure. The certificate or driver's license or credit card doesn't _fail_, it expires.


It fails otherwise it would still be valid. The question is how you Handel failure. An expired certificate is clearly a lower risk than a revoked sertificate, so only haing one failure mode regardless of cause is unnessisary.

PS: With an expired license the number of days past expiration is important in most states. Wait long enough and you need to retake the driving test, so clearly before that point it's still somewhat valid.


> It fails otherwise it would still be valid.

You're confusing things. The validation fails, as in it doesn't meet a certain requirement, the certificate; it isn't damaged or otherwise broken. A mechanical object fails in that it takes physical damage. You're striving for some semantic technicality to save your argument and I just don't think it's important.

> An expired certificate is clearly a lower risk than a revoked certificate, so only having one failure mode regardless of cause is unnecessary.

Why? You're just throwing an assertion out there that is false and expecting me to believe it's true. Additionally, if there is a 2-day window where an invalid certificate is valid, then all that does is make the expiration date 2-days into the future. If the certificate's owner doesn't notice an invalid certificate until after it doesn't validate, then they won't notice until after the window anyway.

> PS: With an expired license the number of days past expiration is important in most states. Wait long enough and you need to retake the driving test, so clearly before that point it's still somewhat valid.

That doesn't mean an expired license is valid. That simply means there is an implicit expiration date for the validity of your driver's exam.


> Why?

Your not limited to a single response. You could turn the URL red for a week and then after that do a popup etc. hell you could stup a browser to ignore expiration dates with minimal impact.

Remember, certificates are not some binary entity. You can have high and low trust certificates ex: trust to sign OS code, trust to sign user land code etc.

Your stuck in binary terms which are useless from a security standpoint.


> You could turn the URL red for a week and then after that do a popup etc.

And what does this buy you? Nothing, honestly. It just means that the expiration date is a week in the future from the date on the certificate. _You aren't actually changing the problem, just renaming it._ We could show red a week before the certificate is set to expire _now_; what does a grace period buy anyone?

Also, there are still have users that don't understand how to check if you have an SSLed connection, and you expect them to make a judgment on if an expired certificate is safe?

> hell you could setup a browser to ignore expiration dates with minimal impact.

No, no you couldn't. This means that if an old key, or one you've lost, is compromised, someone would be able to impersonate you, and you may be _unable_ to revoke a certificate. At least now, there is a definite amount of time that a scenario like that could happen for, you're proposing it happen indefinitely.

Moreover, it also becomes a forced upgrade requirement, viz sha2 certs currently. Sure, some longer-lived certificates may not have been updated (or supported currently), but they're not the rule. Most sites updated though a matter of course and never realized the security implications.

Additionally, the revocation status of expired certificates isn't currently published. Granted, this is a bureaucratic decision, it keeps the CRL size much smaller than it would be otherwise. (And again, it assumes you still have the keys to revoke an old certificate!)

> Your stuck in binary terms which are useless from a security standpoint.

Right, security isn't a binary thing. However, it is often based upon binary things, as they are easy to check, understand, and present. I also resent you calling me "stuck" when you're essentially asking for the exact same thing, just differently.


any old key...

You can always revoke certificates.

what does a grace period buy anyone?

It avoids bad publicity and lost revenue. At some point you don't want to continue operating with old certificates, but breaking without warning is a terrable idea.


Crls don't often include old certificates to limit the size of the CRL.

You have warning. You know when it will expire the day you buy it.

You still haven't told me how a grace period is different from extending the expiry.


Probably more sensible and simple would just be a warning alert that pops up when launching an app with a certificate that will expire within X days.


Why does this matter to the end user?


Since the issue was actually applications that were using pre-2005 versions of OpenSSL that didn't support SHA-2, the "grace period" here was effectively 10 years.


I guess it a good thing hardly anyone uses the Mac App Store.


I'm "hardly anyone". Despite some misgivings on security policies, it's extremely convenient to have a "Steam for apps". At the end of the day, homebrew is the same thing, except it uses the command line and it doesn't remunerate developers.

I have an issue with the concept of MAS as a monopoly (the same I've had with Windows Update), but MAS as a tool is undoubtedly a good thing.


Oh I wasn't questioning the value of the Mac App Store. As a tool for installing free apps it's fantastic. However as a developer if you want to make money off of an application the Mac App Store is all but useless. Even if your app makes it into the top charts your profits will be almost non existent. The user base for the store is simply far too small.

Source: http://www.macrumors.com/2015/05/07/redacted-mac-app-profits...


Wow, that's terrible. It's really too bad, because the idea of being able to just browse for cool apps is very appealing to me. I use the Mac App Store. I bought Pixelmator, Relax Melodies (2 versions), and a few other apps this way. Pixelmator was the only one that I would have bought anyway, so the App Store is definitely a way to earn extra revenue, if Apple could fix whatever it is that's keeping people from using it (perhaps just awareness?).


Developers are actively leaving the App Store - Panic pulled their popular Coda web development app & recommended customers switch to the version from their own site. The sandboxing requirements of the App Store made many of Coda's features impossible to implement in the App Store, plus Apple had to approve all updates & took a 30% cut (compared to about 2.6% for a direct credit card transaction).

They say after they left the App Store, their revenue went up 44%:

https://www.panic.com/blog/the-2014-panic-report/

"I was pretty nervous to be pulling Coda from the Mac App Store. But when we finally did it, I felt an incredible, almost indescribable sense of relief — mostly because as we began to wrap up bug fix releases, we were able to immediately post them to our customers within minutes of qualifying them. My god. That’s how it should be. There’s just no other way to put it — that’s how you treat your customers well, by reacting quickly and having total control over your destiny. To not be beholden to someone else to do our job feels just fantastic. (Also to not pay someone 30% in exchange for frequent stress is a fine deal.)"


But Coda is already popular among Mac developers. We can't say the same about less popular apps though.


I believe that they have made attempts to increase its visibility. I don't recall when the change happened, but Apple routed all system updates through the Mac App Store, pretty much guaranteeing that every Mac user will have to open the store at some point.


Yes, and this is a major annoyance. It seems I get an update for 'Pages' every day, which is why I hate using it. I have to close the documents I have open, go to the store, install the update and re-open my documents. It makes me hate MAS even more


That's odd, given that Pages (and the rest of iWork) usually only updates every few months.


That's if you view the store as a marketing tool, and hope that Apple will push your app for you.

Oh the other hand, if you do your own marketing and use the app store as a distribution channel, you could probably do just as well (or better) as if your app wasn't in the store. Depends on whether the benefits of the store are worth the 30% cut they're keeping.


That macrumors story is pretty misleading. Its true, you won't make a living selling gimmick apps on the Mac. But you can make a living selling actually useful software (at a higher price point). The top selling charts are irrelevant.


You missed the point. The point isn't that you can't make a living selling a gimmick app.

The point is that 94 units with $452 in sales makes you eighth top paid app.

So, unless you are top 10, as a developer you can expect a maximum revenue in a year of $120,000. IF you can make that EVERY DAY ... and you can stay in the Top 10 ... and you can't. And Apple takes $40K of it.

And most people will never break the top 10.

I knew things were bad, but that's disgustingly bad.


The top paid chart is irrelevant on the Mac App Store, because it's mostly filled with $.99 super-niche or throwaway apps. The bread and butter of the Mac App Store is low volume, higher cost apps. The dynamics are totally different compared to iOS/Android. At higher price points, say $19.99 or $29.99, 94 units per day is more than enough to make a living.

The problem is no-one is going to pay that much money for an app that lets you add black boxes to an image. You have to deliver real value worth paying for. Think apps like Day One, Transmit, DaisyDisk, 1Password, Reeder.

Moreover, your numbers are off, you don't need to be anywhere near the top 10 to make over $120,000/year. In fact, you can be well outside the top 100 if your per-unit price is high enough.


It was a good thing, until it turned out that every app you get from it can simply expire with no warning.

I used the Mac App Store because it really is just very convenient. But I also thought it worked. Now I see that it doesn't, so I will not be obtaining software from it again.


> I have an issue with the concept of MAS as a monopoly (the same I've had with Windows Update)

What possible problem could you have with Windows Update? WU is Microsoft's platform for updating it's operating system, core software, and hardware drivers. It isn't a 3rd party app store and doesn't sell anything. In fact they'll host 3rd party drivers for Windows compatible hardware for free as long as the OEM or IHV goes through the proper certification process. It's not even a monopoly because you can disable it and use LanDesk or some other vendor's update platform.

Were you just trying to get a dig in at Microsoft because you don't like them?


Linux has had apt-get for what, 15 years? Microsoft steadfastly refused to implement anything like that for more than a decade, or to open WU in any shape or form to third-parties. All the while, you could get Office updates and IE updates conveniently through WU, but not for any other software, resulting in a proliferation of insecure tools. Whichever motivation they might have had to keep the situation as it was, it resulted in an obtuse and backward monopolistic setup.

Eventually they got around building an apt-get clone targeted at opensource developers, and an appstore for Metro apps nobody wants. In 15 years, that's not a great track record.


APT of 15 years ago is a pretty far cry from APT of today. In fact APT was abandoned by it's original maintainer and kinda sucked until something like 2007 or 2008 when someone else started working on it again. But you know rose colored lenses.

WU has never really been about software installation or upgrade, it's focus has always been about bug fixes and security patches. Silverlight and IE are the only apps that have ever been upgradable via WU and for IE that's been a relatively new occurrence primarily driven by getting users off of older insecure versions. So really Silverlight is only app ever distributed via WU.

You also have to consider that APT was a solution to the horrible experience of getting and installing Debian libraries and applications which still is a pain in the ass without APT. Windows never had the problem, apps that were available for download were easy to download and install.

Keep in mind that APT is for opensource software and doesn't have to deal with authentication and authorization of software licenses.

And since WU isn't a store front and most Windows software isn't free, opening up WU to 3rd party apps would probably have come with distribution costs that I would wager most app developers wouldn't pay.

So again not a very fair comparison.


It's more likely that parent was talking about Windows Store and just mixed up the names.


It's possible but I don't think so because he refers to his issues with MAS in the present tense and his issues with WU in the past tense. MAS is 2 years older than the Windows Store and WS is much more permissive in comparison so I find it hard to believe he's had issues with WS for longer than MAS.


I didn't know you had to sign up for homebrew and provide all your personal info including an authorized credit card, and then you are forced to randomly re-authenticate with the central authority and verify that your credit card is still valid in order to continue using the apps. Also didn't know homebrew could remotely invalidate an app.


Almost all OS X apps made by Apple are available exclusively through MAS. MAS distributes lots of very popular apps like Xcode, Keynote, Pages, Numbers. Imagine a non-techy user trying to open Pages and getting that error message.


Or imagine any user, techie or not, trying to open Keynote to give a presentation and getting that error message.

It's completely ridiculous and has me vowing never to buy (or get for free) anything from the Mac App Store again. Unfortunately I have little choice on iOS.


This hit me yesterday, I use ScreenInk from the app store to draw on slides with my Wacom tablet. Five minutes before my lecture I get this error. Not amused!


Yeah, that's bad. It's one thing to put stupid DRM on your entertainment products. If a movie doesn't work, well, that's irritating but not a serious problem. Watch another one or read a book or, worst case, talk to your family. Definitely not something you want to happen, but I can deal with it. Software gets used for practical purposes, and spontaneous breakage causes real problems.


Better go uninstall Chrome and anything else that has started doing silent auto-updates in the background too then, because that has the potential for spontaneous breakage as well.

I also think you're perhaps extrapolating a bit too much from this incident. Did the MAS breakage really truly suck? Yes, it did. Was it really embarrassing for Apple? It probably was. Did it cause grief for a lot of people? Yes. But the big question is, does this mean we can't trust the MAS to not accidentally break all our apps again? No, I don't think this incident means that at all. I can't think of any other reason for all my MAS-installed apps to suddenly break besides an expired certificate, and Apple's now renewed the certificate. Worst-case, maybe it'll break again in a few years when that certificate expires, but I bet they're putting in place some procedure or mechanism to guarantee that this won't happen again.

All that said, there are certainly plenty of legitimate ongoing grievances with the MAS. I won't dispute any of that. But vowing to never again acquire any app from the MAS over this one incident seems somewhat absurd.


If I used and depended on Chrome, I would at least have the power to fix such a problem myself, by downloading an old version manually, or downloading Chromium instead. There's a qualitative difference here between spontaneous breakage I can fix myself, and spontaneous breakage where the only solution is to wait for others to fix.

Before this incident happened, I thought that App Store apps which existed on your computer and had the proper credentials (verified by running the app successfully at least once) were permanently good to go. Verification happens offline, after all, so there's no room for error and no need to trust anybody.

Turns out, no, all of these apps come with a built-in expiration date, and you need Apple's cooperation to extend their life. They've fixed that. What else lurks in there? If they didn't actually intend to build a system which is once-and-done, then I really have no idea, and I can't trust that.

I don't see why it would be "absurd" to decide not to patronize a system which has demonstrated that it can't be trusted. I mean, what exactly am I losing by no longer buying there? Virtually all of the good apps are available outside of the store anyway. Used to be that I'd lean towards the App Store version because of convenience. Now I see that this is the wrong choice, so I won't do that anymore. So how is this "absurd"? Because it's not the choice you would make?


No, it's absurd because you're stating a very hard-line vow over a single incident. If you had said "I'm not going to buy from MAS when reasonable alternatives exist", that would be a reasonable stance to take. But instead you're saying "If an application is available only on the MAS, I will refuse to purchase it, no matter what the circumstances are". Even for applications that don't provide mission-critical functionality (e.g. that you can tolerate breaking for one day).


No mission-critical apps currently exist as App Store exclusives. An app can't become mission-critical unless I let it, so the possibility that a new one might show up as an exclusive doesn't make any sense.

So really, you're just upset about my wording. That is, to borrow a term, absurd.


There's a very significant difference in meaning between "I vow to never purchase anything (free or paid) from the MAS ever again", and "I will prefer to get things direct-sale when I can". And you must know that, or you wouldn't have chosen the more dramatic "vow" statement. If you really meant what you said when you used the word "vow", then stand by your statement. If you didn't, then admit that you actually meant something else. But dismissing my argument as a mere complaint over "wording" is disingenuous.


Where am I saying "when I can"? I'm not going to get apps from the Mac App Store again, period. It will not be very difficult to do this, because I don't need to.

But please, continue telling me how my statement about my own actions is "absurd" based on your opinion of the situation.


Can someone please explain why you're choosing to downvote me? I'm taking a very reasonable position here. My only real guess is mikeash fanboys (yes they exist) don't like to see anyone disagree with him, but I really hope that's not the case. If there's some actual problem with my comment besides the personage that I'm disagreeing with, I'd really like to know.


Just speculating here, maybe they don't like seeing sarcastic criticism of somebody's choice to give up a DRM-enabled distribution channel, or derailing the conversation by nitpicking little bits of wording.

Nah, can't be, it must be the fanboys who follow me around downvoting you.


My comment was not directed at you. I do not appreciate your continued ad hominem attacks. Unless you want to address my actual argument instead of whining that I'm being nitpicky (or apparently sarcastic?), then your reply is not welcome. This is why I stopped responding in the sibling thread too.


Ugh… yeah, this is exactly why I actively avoid any software with DRM (to the greatest practical extent that I can). Thankfully, there are OS X developers out there that actually do sell DRM-free software¹, and I support them wholeheartedly.

――――――

¹ — http://sites.fastspring.com/helftone/product/monodraw


Xcode you can download from the developer portal for Apple. It's definitely not exclusive to the AppStore.


Right, edited parent.


I will not use iPreach for exactly this reason. Period. Which is sad, because Keynote is a very nice piece of software.

I had a combination of things happen where I installed an upgrade, and it effectively locked me out of my files. I had to pay for a new Keynote version to get around the problem (I no longer remember all the details ... I think it had something to do with an iLife subscription vs. standalone and auto-upgrading my data file version).

I was REALLY pissed off. And vowed I would never buy software again where I didn't control the physical copy.


Yep I try to use `brew cask` everywhere I can, but sometimes auto updates doesn't work when you haven't installed the app from the mac store. Or for example 1 password can't connect with it's Chrome's extension if it was not installed via AppStore.


That, and the settings syncing and licensing situation which I think is far more inconvenient than a quick removal and reinstall of cask apps.

I love Cask but I'll choose App Store apps over their counterpart until the app devs can improve licensing and settings syncing.


I'm not a Mac user anymore (keep waiting for my "perfect" macbook to jump back in, which is perpetually six months away), but this is genuinely news to me.

Is the Mac App Store really not popular? One of my reasons for wanting to get away from Windows again is that I miss my central package management from linux, which is what I kind of thought the App Store did (besides collecting Apple's cut).


I would say homebrew is closer to give you what you want than Mac AppStore is.


Good to know for the future, thanks.

There's Chocolatey on Windows. The best I can say about it is that.. erm.. their hearts are in the right place.


Oh wow, is that what that was. I had upgraded recently to 10.11 and thought that caused everything. Thankfully, it solved it self a little while after.

So as someone who didn't really know what was going on: It didn't really affect me too much, most apps seemed to still work partially (1Password, etc.). Still it didn't seem annoying because I thought it was the upgrade process.


I keep feeling better about dumping OSX on my iMac. If I didn't need to edit photos, I'd get rid of it on my MBP, too. Debian is faster on the same hardware, and I don't have issues like this.

I still love Apple hardware, but they keep screwing up the software side of things on both OSX and iOS.


I realise people are downvoting you for snark, but you make a good point. I have an old 2007 MacBook stuck on Snow Leopard & no longer getting updates from Apple (and now a bunch of software broken by this App Store bug) - but I also have Windows 10 installed on a second partition via Boot Camp, and it runs really well. Microsoft will apparently keep supporting the machine with security updates through 2025.

Installing a different OS (like Windows 10, or Debian) can be a great way to give older hardware new life & continued productive use.


I did this years ago and haven't looked back.


Can you work around it by right-clicking[1] on the application and selecting "open" from the context menu? In some situations that helps with applications OS X deems "insecure."

[1] Yes, Macs support mice with more than a single button now ;-)


This wouldn't help. The problem was not that the apps were being flagged as insecure, but rather that they were being flagged as not having the right to run it on your computer. Basically, the apps demand proof of purchase (called a "receipt" in App Store terms) before they'll run, and the proof of purchase had expired, so they refused to run. The fix involves convincing the App Store to issue you a new one that isn't expired.


Macs have had support for mice with more than a single button since at least Mac OS 9 (released in 1999).


OS 9? Was it added so PC USB mice would work on the iMac?


From what I can see from this thread¹, it would seem so:

The last versions of OS 9 were pretty good about right mouse button support. Most mice should work fine.

I would test it myself on my iMac G3 (Summer 2001), but unfortunately, I already upgraded it to Mac OS X v10.4.11 Tiger, and it’s getting active use, so I can’t exactly go downgrading it at the moment.

――――――

¹ — https://discussions.apple.com/thread/1824021


Haha, took me a long time to release I could plug a two-button mouse into a Mac to get the second button.


Score one for centralization I guess.


This happened to me a number of times over the last few days. The first time it happened I shrugged and rebooted the computer. When it came back up, it asked me to authentcate with the MAS and those few apps worked. Then, later that night, the same issue happened with a different app. I actually uninstalled and reinstalled the app and that worked.

Hopefully they've actually fixed this now but I was pretty confused about what could be going on. The only other time I've gotten messages like that is when I'm opening an unsigned application Apple doesn't think is good, and the Security settings say to only allow trusted software.


There seems to be a bug in the system where sometimes it reports an app as damaged when it's perfectly capable of downloading a new receipt (this is why a reboot works, because the bug seems to only crop up after some period of usage). When I bought a new iMac and transferred all my stuff from my old computer, I had this exact same issue, all of my MAS apps were reported as damaged. After reinstalling one, I tried rebooting, and that worked; got a password prompt for the next MAS app, and the rest just worked fine at that point.

Hopefully they're aware of what's causing this bug and will fix it in an OS update.

Of course, when the certificate is actually expired, and they haven't replaced it yet, then the "damaged" dialog is reasonable, because the system cannot get a valid replacement receipt. But once they replaced it, OS X should have just started working again. In fact, I'm going to go file a radar right now.


The company I work for is in the process of migrating off of SHA-1 certs, and the amount of due diligince that has to go into this sort of an upgrade is incredible.

It involves analyzing full logs of all supported client enctypes and tracking down the full set of "flavors" of clients that only do SHA-1.

At the end of the day, you're going to break people, and it's all about minimizing how many people that is. Imagine the situation with hardware devices in the field from ten or so years ago. You can't update them and their software rev only supports SHA-1. What do you do?

(You break them.)


Curious about how do the user launches the app store if any app-store app cannot be launched?

Isn't then the app store validated with the same method?


I suspect the App Store comes with the OS, not from the MAS. Same situation as Messages, Calendar, Safari, etc.


Indeed. If you got the App Store from the App Store, that would be a bit of a catch-22.

The expired certificate was part of the receipt that gets generated for an App Store app to indicate that you have the right to use that app on your computer. Stuff that ships with the system doesn't need this and so doesn't have receipts.


> Apple quickly addressed the problem by issuing a new certificate with an expiration date of 2035

2035?

>The new Mac App Store certificate was using the current, strong SHA-2 algorithm. However, some apps were running receipt validation code using very old versions of OpenSSL that don’t support SHA-2.

I sure hope it's not a SHA-1 expiring in 2035...


There's no problem with that. Assume the key material isn't compromised, since you have to assume that.

You imply that Apple is going to keep using the cert until 2035. I can assure you they won't.


> Assume the key material isn't compromised, since you have to assume that.

The nice thing about root certs is the private key is only needed to sign intermediate certs and CRLs. This means they can be kept offline in a secure location, and only accessed once every few months or so to sign new intermediate certs or CRLs. The actual crypto typically happens in a special locked-down piece of hardware, so that the actual private key never touches the memory or disk of the computer being used.

The whole process is called a "key ceremony" and follows strict procedures, with technical staff and outside auditors watching every step.

As far as I know, no CA has ever had its root key compromised. It would require physically breaking into a secure facility, or factoring of public key. Considering there's much lower-hanging fruit for anyone attempting to attack PKI, I'm not too concerned with a 20 year root cert lifetime. (Like you say, they could just remove it from future versions of OSX before then!)


It's also incorrect. The 2035 number is the root certificate. The leaf signer is (as of last night): Not Before: Sep 24 19:09:31 2015 GMT Not After : Oct 23 19:09:31 2017 GMT


I've seen this happen with Yoink! on my machine, I assumed it was a bad update and just kept going... after 24 hours without Yoink, I was so annoyed that I deleted it and redownloaded it, and after a couple of failures starting eventually it worked. Glad to see developers are not at fault!


Kind of surprised nobody thought to look at the certificate before and predicted this would happen.


Craig Hockenberry noted the problems with cert caching two years ago[1].

[1] http://furbo.org/2013/10/21/mac-app-store-receipts-and-maver...


Just check the _MASReceipt/receipt of some apps I downloaded from App Store. The NotAfter field of the receipt certificate is still Nov 11, 2015. Wonder how OSX still allows me to run the app... Any idead?


Nobody is perfect at creating software (and probably not perfect at creating hardware either for that matter).


Everything about this tells you what Apple really thinks about 3rd party devs. Just shameful.


I'm sure someone probably lost their job because of this.


As anyone who's released an app knows, the real problem is Apple's excessively bureaucratic certificate and provisioning processes.


Must be fixed already. I just launched pixelmator (the only app I've purchased through the mac app store) and it started up without a hitch.


git, tar, make, and gcc (or clang/llvm) Probably still work.


Actually no they didn't if you had recently upgraded xcode, because you have to agree to the xcode terms and conditions to use them.


Based on the update to the article that dak1 mentioned¹, I’d say that’s actually incorrect:

Apple issued a new, stronger (SHA-2) Mac App Store certificate in September, before the older (SHA-1) one expired, as planned. The new Mac App Store certificate was using the current, strong SHA-2 algorithm. However, some apps were running receipt validation code using very old versions of OpenSSL that don’t support SHA-2. OpenSSL started supporting SHA-2 in 2005, which is why Apple didn’t foresee this issue.

Since I seriously doubt any of Apple apps would be using the older SHA-1 certificate, this probably only affected third-party apps.

――――――

¹ — https://news.ycombinator.com/item?id=10561748


That's hilarious.


These are not Mac App Store apps.


He's most likely saying that while the MAS is broken, you can still download something via git and build it yourself.


I'll just go compile my own PhotoShop, hang on.


You can compile the gimp.


No reason to downvote someone explaining it, seriously. You can downvote the original poster, if you want, but this just hurts everyone – he/she just wanted to help you out by explaining it.


I think the parent comment was suggesting to git-clone or wget and untar source, make and install.

So, instead of buying overpriced software from the mac store, just building it from source.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: