To validate Xcode: "in sealed resource is missing or invalid"

I'm guessing the command line validation is predicated on a Mac App Store download/install. Meaning, your test is safely errant.

Excuse me but I am a novice and I do not speak your language should I use Google Translate to write. I have not figured out if I made a mistake in the test or verisione is invalid. Excuse my English by caveman

No i test on Terminal

It just did it to me. I don't remember exactly where I got my version of Xcode from, but I'm 99% sure it's the GM seed right from the Apple website. Not only does spctl give me the same result, but running codesign --verify on my Xcode also returns the verbiage about "a sealed resource is missing or invalid." This is getting really creepy…how could this have gotten compromised?

I don't think your install is compromised.

I think the test is _only_ for straight up, non-GM, mac app store binaries. Maybe Apple will clear this up soon?

I think the test is for when you install from the Mac App Store only. Can you try that (and maybe delete the Xcode 7 you have now,) and then check again?

But the article said the following:

and for a version downloaded from the Apple Developer web site, the result should read either
/Applications/Xcode.app: accepted
source=Apple

or

/Applications/Xcode.app: accepted
source=Apple System

But mine isn't doing either of these. The fact that it's mentioned means that Xcode versions downloaded from the developer site (which, I should add, are beta and GM versions) means that they shouldbe passing the validation check. But yeah, I agree with you that it's extremely unlikely that someone could have hacked the Apple website to inject a malicious version of Xcode. I'm considering emailing the developer support to ask which versions were known to be compromised—that's really important here.

>But the article said the following

Yeah, that is true. All I know is I skipped the GM window and went from 6.4 to 7.0 via the store.

I'll wait for the other shoe to drop, I guess.

Ken

-=-

The final release version (7A220—straight from the Mac App Store) fails spctl too.

I figured out why the codesign verification on the GM (7A218) was failing—I had accidentally added a newline to a framework header file 😕. Removed it; now codesign is happy. But spctl still fails for both versions. I emailed Apple and asked them if they'd be willing to share what they knew about which versions got compromised—hopefully that will help us out.

Here's an unhappy thought: if people were able to counterfeit Xcode and use it to inject malware, might they have been able to gain unauthorized access to developers' signing assets? That could be really bad… I sure hope Apple will actively pursue this instead of just telling us about it and leaving us to fend for ourselves when possibly the entire Xcode/App Store system has been breached.

Does anyone know how to get spctl to tell you _which_ resource is missing or invalid? I'm already invoking with --verbose. Is there a --super_verbose?

The man page for spctl has nothing—in fact, the notice about the invalid resource is shown regardless of the verbosity setting. Even an internet search for "spctl" mostly just redirects to more websites that show the exact same man page. 😕 It appears there's literally no extra information available on how to make spctl give us the information we want.

Your guess is as good as mine—welcome to the club!

I don't think "the entire Xcode/App Store system has been breached." If the developers with compromised Xcode installations had their developer keys stolen somehow as well, then they'd just have to revoke their certificate and generate a new one with a new key. Same as any other malware / spyware on their Mac. It would only affect the individual developers involved, since all developers have their own keys / certificates.

Maybe it‘s because gatekeeper's settings, like this:(Mac App Store and identified developers)

I get the same validation error.

This is really annoying. I work at a decent-sized company and we share Xcode dmg from developer portal over the network drive - would be great if I could verify that what is on the network drive did in fact come from the developer portal.

Anyone familiar with another way to verify the binary?