Apple revoked longtime Mac developer's code signing certificate with no warning
twitter.com
twitter.com
Well, yes, if it's true, which it wasn't.
* apple actually did communicate to them, but it was via carrier pigeon or something and it got lost
* apple is under gag order
* the developer is actually a long time repeat offender and is trying to evade via sockpuppet accounts
None of them seem plausible to me. Also, unlike with the apple 30% refund fiasco, we know for sure this is happening, because other users are tweeting that they're receiving error messages when trying to install his software.
* No email in my spam box. * My contact address is still working and have received notifications about them approving my updates for the App Store yesterday (so saying that they have no way of contacting me is not true). * No known breach of account. * No accidental revocation (I was sleeping while this happened). * The certificates are revoked as you can verify via command line.
* apple actually did communicate to them, but it went to the developer's spam box.
* apple actually did communicate to them, but sent it to an old email address that the developer never updated.
* apple actually did communicate to them, but it was via a developer dashboard that the developer rarely checks.
* apple didn't revoke it. something else is going on.
Isn't "check your spam box" the same thing you're going to do if you're looking for an email that you're expecting?
>* apple actually did communicate to them, but sent it to an old email address that the developer never updated.
plausible, but seems unlikely that'd be the case, considering that this is a semi-important account that you won't use a throwaway account for. Also, isn't your itunes connect (app store) login based on your apple id, which is based on your email?
>* apple actually did communicate to them, but it was via a developer dashboard that the developer rarely checks.
His tweet said that his account was suspended, so he probably found that out while trying to log in, or got an email.
Why are so many people assuming that Apple would only email a developer about revoking their certificate, a drastic action that suddenly kills all of the developer's apps? Apple has the phone number of every member of their developer program. Anything less than an immediate phone call from Apple in this situation would be gross negligence.
> apple didn't revoke it. something else is going on.
It's revoked. Any Mac user can verify this with "codesign --verify" on any of the apps on the developer's website that are still available for download.
- Developer accidentally clicked "revoke my cert" (no idea if that's a real button, but that's not the point).
- A national security agency sent one of those scary letters preventing Apple from speaking but requiring the action.
- Developer had a mental breakdown and has lost grip on reality.
- Developer realized app was infected with malware and ...
Truth is stranger than fiction, so it's actually really hard to think of all the possible strange explanations. Which is why it seems imminently reasonable to take a wait and see approach at least for a reasonable period of time.
If that's the case why wasn't that communicated to him?
>- Developer accidentally clicked "revoke my cert" (no idea if that's a real button, but that's not the point).
>- Developer had a mental breakdown and has lost grip on reality.
While these are possible, they seem very unlikely. Compare the numerous cases of Big Tech silently revoking people's account with no notice or appeal, to the number of times that someone made a public announcement, and then went "nvm it was me lol".
Also, whenever you suggest something is "very unlikely," keep in mind that this likelihood is one instance in the context of 20 million developers. Are you suggesting it's like a 1 out of 100 chance, or a 1 out of 20 million chance?
I think many people ask themselves that just before they grab the pitchforks.
Of course, you'd expect a notification from Apple saying they'd done that and why; and plenty of safety measures to prevent mistaken revocations.
That's not to say I support mandatory code signing - merely that if you're going to have code signing, you also need to revoke stolen certs.
EDIT: To be clear, it's not the certificate revocation that's bad, it's that the certificate is required to distribute code and can only be acquired from a single organization.
I wouldn't want it any other way if I have to use non-open source code that I can't inspect. But the basis of all my core software is going to be open source.
The cost issue is separate from the revocation issue, and my point was about certain revocation--it's an absolutely great feature for any code signing situation where you are trusting others to compile code for you and others can't confirm that a certain set of binaries came from a certain set of source files. (Reproducible builds could help, of course!)
For security... sure... actually not even my grandmother would believe it.
And writing drivers for hardware has often been impossible or effectively so due to poor documentation and/or signing. Do you not remember the era when most WiFi cards didn’t work with Linux, or when graphics cards required closed source binary blobs to even work?
I get you don’t like it on principle, so maybe you shouldn’t buy a Mac, but the idea that we’re going down a slippery slope is very much [citation needed]
Windows also introduced software signing for drivers and user software, so yes, prevalence does increase while no benefits are provided. What is the advantage of an nvidia binary blob for Linux if it is signed or not. Was downloading from a trusted source a problem? We had hashes if you really wanted them.
With signing you make yourself dependent on the manufacturer of the OS.
The console argument was a hint that the application gained traction as a DRM utility, not for user security. Because signing here included properties of the medium the software was deployed on, so you couldn't just copy it to another CD/DVD.
Yes it has, that’s the point of this whole discussion. Desktop apps now need to be signed and I’d be willing to bet you couldn’t find a signed torrent client.
*replaced pronouns and specified
$ codesign --verify ~/Downloads/Eon_977.dmg
CSSMERR_TP_CERT_REVOKED
iPhone is a generic pocket computer, and it has outgrown Apple's desire to maintain a fiefdom.
Congress and the EU should force Apple to allow 3rd party marketplaces and installs. Apple is free to charge 30% for the App Store, but they can't be the only way to get code onto an iPhone. Nor should they be the only first class way of doing it.
Edit: I frequently get downvotes because of this. Who really wants everything going through Apple 100% of the time? I don't understand this perspective at all. Do you like not having control of your devices?
Nevermind the fact that this was the platform that pioneered race to the bottom prices with the expectation of free updates for life.
The app store is so incredibly toxic and harmful.
> Notarization is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.
Perhaps the software connected to a website that was flagged as malicious by Apple. That’s one way I could see it getting flagged.
I don't think it's related to it being a "YouTube downloader" app either. There are many apps with this functionality and, so far as I can tell, none of the others are blocked.
Their US site (www.opinel-usa.com) is not blocked, however, nor are the many online retailers which sell their knives.
I've seen a number of times where a compromised web site will have a bit of javascript inserted into it that only shows the malicious payload to certain people from certain geographies or browsing history or operating systems, etc... It might be there, but not showing it to you.
> Ever wished you could save a video from the Internet? Search no more, Downie is what you're looking for. Easily download videos from thousands of different sites.
Nope. Creating a tool perceived by those with enough lawyers to be a “copy protection circumvention device” however does run afoul of the DMCA.
Reminds me of YouTube blocking Blender videos... had other reasons though, don't remember exactly, but it had to do with them not monetizing their videos and really, really bad support.
https://news.ycombinator.com/item?id=17347560
Basically they needed to enable monetization since [I assume] Google was taking a non-negligible loss by hosting all of their content for free.
It's not necessarily the law, either. Panicky industry heavyweights may lobby to make it a law, or try to confuse a given tech with copyright infringement, but "downloading videos" is not against the law.
The dev's website includes a screenshot of it downloading a bunch of Disney material. That is not a wasp nest I want to shake.
If it breaks actual encryption (a la DeCSS) then yes, it oversteps.
But TV content stakeholders don't have much pull with convincing VCR manufacturers/distributors to stop supplying VCRs. Apple does clearly have the ability to affect the signing of software.
I'd counter that if the audio and video get to your eyes and ears, then the content provider has already provided you a decrypted copy of the media and/or the instructions for how to decrypt.
If you had an arms' length valid agreement with the company where you agree not to retain the media, then that's different issue.
Don't some jurisdictions have provisions that allow for technical workarounds in order to make backups?
It's actually computers that allow you to do this. I think this is why there's a war (of sorts) against general purpose computers: they enable you, the user, to do all sorts of things publishers didn't envision or want.
* a lawyer sends a DMCA request to Youtube
* a Youtube bot looks at the offending request and finds a user agent
* Kicks off automated warning to Apple bot
* Apple bot shuts down developer account
All that's really needed here is a bot to post these things to Twitter and HackerNews and then an API for the service bots to read the complaints and undo the action with a phony apology post
"The following restrictions apply to your use of the Service. You are not allowed to:
access, reproduce, download, distribute, transmit, broadcast, display, sell, license, alter, modify or otherwise use any part of the Service or any Content except: (a) as expressly authorized by the Service; or (b) with prior written permission from YouTube and, if applicable, the respective rights holders;"
Is the Transmission torrent client next because it could be used to download copyrighted content?
5.2.3 Audio/Video Downloading: Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third-party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources. Streaming of audio/video content may also violate Terms of Use, so be sure to check before your app accesses those services. Documentation must be provided upon request.
https://developer.apple.com/app-store/review/guidelines/#int...
As to the why, because Apple could be sued by third parties for allowing this behavior for apps that Apple has vetted.
though if it was that you'd think they would just pull the app and ask him to rename it...
In any AppStore app, everything is literally Apple's business, considering they get a cut of any money that changes hands and can reject your app for "looking at them wrong".
That's why the whole model is (rightly) controversial.
But the true controversy is not a curated store, the controversy is that the curated store is the only way for people to load native code onto the device without compiling it themselves on a separate laptop.
>The developer's website (software.charliemonroe.net) is blocked by my ISP (Vodafone UK)'s adult content filter. This is strange as it does not appear to contain any adult content.
would explain a lot. In order to download from a pr0n website you need to hardcode that websites domain name inside the program = pr0n filters pick it up = Apple bans it.
A CRL / OSCP makes sense, more or less, for websites as they can simply abandon a cert.
If the cert leaks, is the remedy really to completely blacklist the certificate? Because that means that anyone who is able to steal the cert can effectively blackmail an author.
I'd definitely want to revoke it, but if there's a set of valid releases, it seems like you'd want to do a partial revocation, e.g. "valid until YYMMDD." Or have a blacklist / whitelist and mark known good releases.
I can't imagine how they don't have a separation of concerns given that app certificates must expire.
[1]: https://developer.apple.com/support/certificates/
[2]: https://help.apple.com/developer-account/#/dev138c9fac7
[3]: https://developer.apple.com/library/archive/documentation/Se...
Yes, this is definitely possible, and why Developer ID signing has a secure timestamp, as specified by the --timestamp flag to the /usr/bin/codesign tool.
When Panic's code signing cert was stolen, they revoked it after a certain date, but old versions of their apps continued to be valid and pass Gatekeeper.
> "Hello everyone, today I woke up to my developer account being suspended without a single letter why which is why the apps are crashing. Please bear with me while I try to get this fixed with Apple. Thank you for understanding."
Not being a Mac developer, the wording about revoking the certificate makes it sound a little more unusual than just their account being banned. Although not nice, I assume that's something that happens a lot.
Their customers can work around this by disabling the requirement for signed binaries, but of course that's not desirable and in corporate environments might not be allowed.
I wonder if these things are related?
I know YouTube downloading services have struggled in the past to stay operational.
See Apple TV
I suspect this will bring about conflicts in the company between content creation and the hardware/software divisions.
Apple thinks different now.
After you have the market, you want to close the gates so no one else can have it.
The hypocrisy is real and why I no longer buy apple products.
It sound's as orwellian as Apples certificate shenanigans.
This is a voluntary industry code of practice, not a legal requirement. For some time there was talk of making it law, enabled by a clause in the Digital Economy Act 2017, but this was abandoned in 2019.
https://en.wikipedia.org/wiki/Web_blocking_in_the_United_Kin...
"after almost 24 hours after 10PM, I got my account re-instated. Apple has called and apologized for the complications. The issue was caused by my account being erroneously flagged by automated processes as malicious and was put on hold."
Presumably, there's a known problem and something isn't working, even if it looks like it is.
Arguably, it'd be nice to have a facility (assuming it doesn't already exist) to override the revocation list, but designing that it isn't bypassed by social engineering is tough.
“MPlayerX hasn’t been working for almost a year now. Also they still offer my apps on the App Store, they revoked my (direct) distribution certificate...”
https://twitter.com/charliemonroe/status/1290629792430280704...
So this could be justified
> Non-notarized versions will not work well on newer systems (https://appleinsider.com/articles/19/12/23/apple-will-enforc...) and mainly I can't currently even compile the application.
I like that more developers just reject software certification processes. There is zero benefit aside from lock in.
The argument that they could be better therefore they are worth nothing, is a clear fallacy.
I’m claiming that the App Store solution as it stands is better for most users than just freely installing apps from the web.
It’s not at all clear that the safety of just installing software without vendor lock in is getting better for most users.
In fact it seems to be getting worse.
You could still have trust mechanisms while downloading from sites where the author, not the walled garden, has the control.
Wouldn’t it be better to have the user have the control?
The walled garden does have problems, but I generally don’t see anyone adding any value to our understanding of how to replace it with something better.
It would, but the user has no control of the walled garden either. It's a situation where both the user and the author have little to no control, as well as poor feedback.
I'm not sure walled gardens, with their arbitrary rules, and opaque audit and review processes (which include not knowing how detailed their reviews are), are really a trusty safeguard against malicious authors. Whether you believe walled gardens protect you from malware depends on your definition of "malware".
It's not true that without the App Store there's a world of dangers out there. Author reputation goes a long way.
History certainly proves otherwise, as do the number of attempts at putting malware into app stores.
I’d go as far as to say that you are certainly wrong about this and you can trivially verify this by even the most cursory examination of software threat models.
Author reputation goes almost nowhere these days. It’s quite obvious why. There are a huge number of authors producing software.
It’s impossible for more than a few authors to develop a reputation, and even those that do face impersonation.
As to you not being sure how much protection ‘walled gardens’ give. They aren’t perfect, but they clearly work, and you can trivially verify that.
If you think the author or the user can solve these problems without an intermediary, it bears some explanation as to how exactly this could work.
Can you explain?
You haven't explained how the user has more control with walled gardens, a bold and unsupported assertion (I believe we both agree the author has less control with walled garden, at least).
> It’s impossible for more than a few authors to develop a reputation, and even those that do face impersonation.
The first part is a matter of opinion (and I disagree with you). As for the latter: do you really believe the only technical solution to author impersonation is a walled garden? No other form of establishing trust is possible to you? Interesting.
> I’d go as far as to say that you are certainly wrong about this and you can trivially verify this by even the most cursory examination of software threat models.
That isn't an argument. That's just you saying "I'm right and you're wrong".
In fact I have consistently agreed about the problems levied against the walled garden model.
I haven’t asserted that the user has more control with a walled garden, although I think they do in practice have more control with an App Store than with nothing.
I’d be curious how you came to the impression that I did - can you explain where I made that claim?
My claim is that walled gardens do introduce problems, but that they currently solve much greater problems for both users and developers than the ones they introduce.
The claim that it’s just safe for people to install software because it’s not dangerous out there is obviously false.
You can say this is just me saying ‘I’m right and you are wrong’, or you can do the most basic research on the amount of cybercrime and plain old scams and how much of it involves malware or impersonation of one kind or another.
If you think this problem doen’t exist, it would make sense that you don’t see the benefit of App stores, however to deny that it exists in this way is quite surprising, to say the very least.
The issue of reputation isn’t a matter of opinion. It’s a fact. How can I say that? All industries with a significant number of creators and a significant number of consumers have intermediaries. Only the most famous independent producers are independent.
If you can find a counterexample, I would be interested to know about it.
As for believing that the only solution to the issue of impersonation is a walled garden - I don’t know the answer to that.
Maybe some kind of distributed reputation and trust system that doesn’t involve a powerful intermediary is possible.
Perhaps some kind of blockchain or web of trust can be developed.
I’m not at all sure that this is possible - Apple’s attestation mechanism uses hardware keys to to create signatures that join a device, a particular user and an app binary.
Without the ability to link all three of these it’s hard to see how a software only solution would work.
But even if an alternative is technically possible, it quite obviously doesn’t exist today. If it did, you’d have just linked to it, and I’d have probably ordered whatever device would allow me to participate.
If you want to continue claim that App stores solve no real problems or that the problems are trivial, there are no dangers out there etc, then be my guest. I can’t change that belief in you.
If on the other hand, we have good solutions to those problems that don’t require an App Store, then I would love to know about them and if it’s true, I’ll happily concede that I’m wrong.
There are severe disadvantages though:
https://medium.com/vchaincodenotary/developers-unite-against...
Additionally, the most predatory kind of app milks your wallet and these come in signed and unsigned forms.
Also, quite a few companies with long time certs have leaked them pretty quickly. Primarily, it is a lock in mechanism with questionable security benefits. Predatory apps can be signed which would have been classified as malware 15 years ago.
Maybe those benefits don’t outweigh the downsides, but to say there is no user or developer benefit is objectively false in both cases IMO.
And of course there are benefits beyond lock-in.
Do you know about the attestation service Apple has introduced?
How would you build such a thing on your own?
Outrage based on the facts is definitely something Apple should face.
However outrage based on lies is simply another evil.
People who are engaging in it are not doing any kind of public service - they are just adding more harm.
1. A standard format and tools for code signing.
1b. Actively validating or rejecting code on the end user machine.
2. Purchasing and delivery of software.
3. Trust of code blobs.
They just don't need to be all handled by your OS vendor.
Additionally this is a Mac app and you can sideload apps on Macs
Now we can skip the part where somebody says that you can't have a monopoly on your own product and then I point out that monopolies always look like that because their product is the only one in the market, and the reason that android app stores and iOS app stores are different markets is that you can't install Android apps on iOS devices or vice versa.
Walmart doesn't have a monopoly on SAE 5w30 motor oil. You can't make it look like a monopoly when it isn't one, because when it isn't you can identify competitors who sell substitute products to the same customers.
> In the end both mobile platforms have practically the same popular apps.
The market they have a monopoly on is iOS app stores, not individual apps.
It's very straight forward. For Google Play to be in the same market you would have to be able to use it to install apps on your Apple iPhone. Since you can't, it isn't, and since there is only one app store that can, it's a monopoly.
Notice that it has nothing to do with the fact that Apple also makes the phones, outside of control over the phone being used to enforce the app store monopoly by locking out competitors. If Amazon for some reason had the only app store for Apple iOS devices, they would be the one with a monopoly in that market.
A phone is a natural monopoly.
This would be more akin to buying a Ford and then discovering you could only buy parts, motor oil, etc. by visiting your Ford dealer.
> Now we can skip the part where somebody says that you
> can't have a monopoly on your own product
> monopolies always look like that because their product is the only one in the market, and the reason that android app stores and iOS app stores are different markets is that you can't install Android apps on iOS devices or vice versa.
You being tired of it doesn't change anything. ¯\_(ツ)_/¯
As a developer I want a store where someone is investing in the safety and security of the ecosystem.
If I want Apple to be able to be able to remove malware from the store, I obviously have to accept that if I make malware, then they may remove it.
The arguments about what they are somehow holding back are completely without merit.
It’s not expensive to buy an Android phone.
Android phone allow both sideloaded apps and alternate stores.
Where are the amazing Android apps that are only possible through side-loading?
Most people here are from Silicon Valley and Apple is the biggest employer over there.
Try to badmouth Samsung in a Korean sub and you get the same treatment.
At the time, the App Store (iOS) was new, and I was working on porting our SSH-based encrypted remote access tool[1] from Mac to iPhone. I had been doing mainly Mac OS X development for almost 10 years.
I had the proof-of-concept port from Mac to iOS working, but the amount of insane hoops I had to jump through (because it used "strong encryption" (we forked PuTTY SSH)) seemed, initially, like a trip the DMV. It gradually started feeling more like the movie Brazil.
I remember going directly from WWDC to the local office of (searches old files) the "Bureau of Industry and Security" (wat) and talking to some guy who had NO idea what I was talking about when I told him my company was trying to make an iPhone app that used encryption and that Apple had told me I needed to get his agency's approval. (Nice guy, though.)
Ultimately, working through the Apple documentation, I learned I had to do a bunch of weird stuff, like sign up for antique government systems that only worked on Windows XP, and provide personal info, and make a PIN, and submit an application to SNAP-R, and submit a "BIS-748P supporting document: how the Product meets the criteria of the Cryptography Note as mass market encryption software" along with a "BIS-748P supporting document: additional information to supplement our application for review and commodity classification request, in accordance with Supplement No. 6 to Part 742 of the EAR" along with "BIS-748P supporting document: sample marketing copy and brochure text" and a "BIS-748P supporting document: illustrations depicting the software in operation" and then finally a "BIS-748P supporting document: source code listings for all encryption-related source code used in the product"... that last was a ridiculous 500-page or so hard copy printout of the source code to PuTTY with the few dozen places we'd changed it (to make it multithreaded to fit better with our app architecture, haha, because I was young and dumb then).
And, while I forget a lot of the details (I've just copy-pasted those now, after finding the relevant old files), I remember vividly the moment, sitting there in a Tokyo hotel business center assembling this heavy paper package to FedEx to BIS and just suddenly thinking... wait though — maybe this isn't a game I want to play. We didn't have to do any of this to ship a Mac app — any risk of legal noncompliance was ours, of course, but in reality there was no actual risk. This was all for Apple to cover their ass.
If some government bureaucrat didn't like my application, my app wouldn't ship and the past year of work would be for nothing. And somehow that made me acutely aware that the same thing would be true if Apple for some reason didn't like my app. Like... what if they were planning to roll out similar rich, Mac-centric remote access features in the next OS update. Or, even if they approved it, but later just didn't want to deal some issue that arose around it — they could just revoke my app any time they pleased.
(As seems to be the case with the app in this thread.)
I thought about this for a couple more weeks, and then I took a corporate job doing internal systems development. The app was never finished.
The lack of my app obviously didn't hurt Apple. But looking back, I do feel like the lack of having to deal Apple — and that whole weird power imbalance, of being a peasant plowing fields owned by Apple, hoping to receive some part of the fruits of my labor — probably helped me live a more serene, untroubled life.
[1]: iGet Touch (phone apps were still called "blah blah Touch" then, just like many Mac apps from the early 2000s were idiotically prefixed with "i" (^_^); back then) was never finished — but it was basically a native iOS version of the Mac version, long dead but still archived here: http://nakahara-informatics.com/iget