Good morning, I guess, still. I am Perry 'the Cynic'. I invented Gatekeeper, and so I'm here to tell you about it. We have a lot of ground to cover, so let's get started. I'm going to tell you what Gatekeeper is and how it works. I'm going to tell you how to use it to control what can be installed and run on your Macintosh.

I'll tell you how to use Developer ID to sign programs so other people will let them install and run on their Macintosh. I'll tell you a little bit about how to debug problems you may have. And because a lot of what I'm going to tell you won't make any sense to you without it, I'm going to start with a code signing refresher. We haven't had a session on code signing for a while because it hasn't changed. It's a fairly mature technology at this point. So chances are you've never actually heard about it.

So this is a general code signing primer. This is not specific to Gatekeeper, and it's just enough to get you going. There is a lot more. There's a lot more documentation on this. Don't be afraid to read that. Code signing is an identification technology. It's about looking at a piece of code, an app, a tool, a library, and say, "What is that?" How can I identify it? How can I recognize it? Code signing itself is not necessarily about defeating or prohibiting anything.

That's not its job. Its job is to recognize. Now, its job is to reliably recognize. So if somebody changes the code after you sign it, we notice. So we put a cryptographic seal around this code thing. You don't need to know how that's done, unless you want to.

But yes, we can tell if it's got changed after signing. If this is an app or a framework with bundle resources, we are sealing the bundle resources, so we can tell if the bundle resources got changed. This is important because there's things in there like nibs that are basically free-strite code.

And since anybody can sign code, it's a public API and a perfectly useful command line tool, we need a little bit more than just checking that it changed. We also need to have something that tells us who signed this. So we are applying a digital signature. that relies on a secret that only the particular developer has, whether it's Apple or you, doesn't matter.

Now, one thing that code signing does very well is you can tell that code got changed. That's cool. But it also can tell that you changed it, that the developer changed the code, and even though the bytes are all different, it's meant to be the same program. So that's baked into that logic of code signing. I'll tell you a little bit about how that works.

This is all about identity, about what a piece of code is supposed to be. Is it supposed to be Apple's mail program? Is it supposed to be your utility? Is it supposed to be a library or plug-in that you built? That's identification. This is the one takeaway from this. And then, last but not least, this is supposed to work at runtime and fast enough that you generally don't notice. That's actually a really good trick, and there's a lot of code just to do that.

Yeah, yeah, picture, 1,000 words, let's try that. So your code, your final code, you've done everything to it that you can possibly do. You've stuck in all the localizations, you've polished all the resources, you did all the NM editing and symbol removing and localization fixes, and you added all the helpers. It's done. You're not going to change it again. This is what you feed to the code signing machinery. Now, typically, Xcode does this for you, but you can run the command line tool if you want to.

And we said we need secret, so here is a cryptographic identity. It sits in your keychain. You may have gotten it from Apple through a developer program, but you could also have gotten it from a third-party vendor that sold it to you for good money, or you can make it yourself. The machinery doesn't care. A signing identity is a signing identity, and it'll work.

So, it will sputter a little bit, and then it'll put out a modified version of your program, and it's signed. This is the thing you don't change anymore, because now we can tell. This is how you ship to the end user, through the Mac App Store, or through a website, or you mail it to them, or you hand them a USB dongle, we don't care. The important point is that it doesn't change. For all we care, you can use binary patch update mechanisms with really smart internals. It doesn't matter as long as what you end up with on the end user system is the same bytes.

And at some point, that program gets interesting. It tries to run in a Gatekeeper environment. It asks for access to a keychain while it's already running. It wants to be a debugger. There's more and more scenarios every year. In any case, whoever controls that resource is feeding your program to the codesigning verifying machine.

And that checks that the cryptographic seal hasn't changed, that nobody has messed with it since it got signed. But remember, just checking for integrity isn't enough, because a bad guy can take your program, strip off your signature, change it, put on their signature. Now it's their signature, but it's still intact.

So we need something else that actually checks that this is the program as you signed it, not as somebody else signed it. So we have this thing called a code requirement, which is essentially a simple rule. Things to check for. Typically, it checks for what's signed with you. It checks for what's signed with your cryptographic identity.

Now where do we get these code requirements from? Often, surprisingly enough, you get them from the program you're looking at, because most of the time, you actually don't care who made this program during verification. You care that it's the same program you saw before. Think about the keychain as an example. When a program creates a keychain item, the system creates an access control list that says who has access to that item. And the default value is the application that made it.

The keychain doesn't care who you are. The keychain doesn't care what program that is. All it cares is that the program that comes along tomorrow and says, "I want that keychain item," is the same one that made it. And remember I said we tolerate intentional changes. So if the program comes along in two weeks, it's your new, updated, improved version of the same program, and it'll still work. That's the magic.

Now, that code requirement gets stored somewhere so that it can be remembered later. In the case of the keychain, it's in the keychain itself, the access control list. Other subsystems have a database in the system, Gatekeeper does. Sometimes it's just a hard-coded rule, you know, must be made by Apple.

This particular mechanism of pulling a code requirement from a program and remembering it is so frequent and so fundamental that we've given it a name. We call it the designated requirement of your program. It's essentially a code requirement that says, "How shall I recognize you again?" You know, "What should I check an imposter to see if it's you?" Now, normally, the designated requirement gets magically produced by just looking at your code signature, the code signature of your program, and deciding what a good match means.

But sometimes that's not good enough. Sometimes you actually need to cook one yourself. So when you sign a program optionally, you can explicitly say, this is the designated requirement I want my program to have. And this is important for some of you because this is what you do when you transition from one signing identity to another. So keep that in mind, designated requirements.

So we have the cryptographic identity, the secret that you have that proves that you're you because you're not stupid enough to give it to someone else. And we have code requirements that are used to essentially match this identity. They go together, like key and lock. Sometimes it's hard to tell which one's which.

So code requirements. These are actually the most important non-obvious part of this entire machinery. So let me just give you a couple of examples of what that looks like. There's a text representation for these and a binary. Mail.app, the mail program that you all use on your Mac. This is its designated requirement.

Basically it says it was signed by Apple and its name is com.apple.mail. That's all there is to it. Now, if you made your own If you're signing an identity, like with Keychain Access, you can, it's free, then you would end up with a code requirement that looks something like this. There's no "anchor apple" because you're not Apple. Instead, it's "anchor some hash," which is basically the hash of the certificate that you made yourself.

But otherwise, structurally, it's the same. This is the identifier you gave it. It's typically your bundle identifier. And it was signed by this identifier. We don't really know who you are. We don't really need to know who you are. But we can recognize that particular cryptographic certificate, and we know that you're holding the key to it and nobody else does. That's good enough.

Here's another code requirement, just to give you an idea that we can do things here that aren't just identifying individual programs. This one says it's signed by Apple, and it has an info.p list with a particular key called application group, and the value is .-mac. That's weird, you know. How did we come up with this? Long time ago, there was this thing called .mac before me.com. Long time ago.

And that's around the time that code signing was invented. And one of the early requests was, can't we just have something in keychain items that says anything that Apple says in the future has access to your me.com password, your .mac password. It'll just work. We don't have to keep adding it to a list. So that's how it works. Whenever Apple ships another app that it wants to have access to this password, it just gives it an info.p list entry. Like this. Key application group, value.mac. And poof, access. Great. Anything coming out of the Mac App Store looks something like this.

Anchor Apple generic means it draws to the Apple anchor. And there is this identifier, which is what you'd expect, the bundle ID. And then there is this totally opaque, weird certificate leaf thing that basically says, this is how Apple, the Mac App Store, signs stuff. You don't really need to understand. It's just some binary pattern inside of particular certificates. But this is basically how this machinery works. You just match things in the certificates that sign the program, and you tack the name on. You're pretty much done.

Just to jump a little bit ahead, Developer ID looks like this. And you can tell it's even more complicated. But the machinery is the same. You just take these little tests, you and and or them together with parentheses and negations, and there you are. If you pass this test, you pass the code requirement. And if you don't, you don't. And that's all. You can settle down. That's code signing.

So, Developer ID. You'll know about the Mac Developer Program. Well, you develop for the Macintosh, you are signed up as a Mac Developer, you pay your dues, and you get your development certificates and your distribution certificates. You use the distribution certificates to send stuff to the App Store, you develop with your development certificates, and you've all signed little electronic pieces of paper that say that you won't actually use those certificates for shipment outside of the Mac App Store. You're prohibited from doing this. I know some of you do, but you shouldn't.

So what's Developer ID? What's new? It is not actually a new developer program. It's part of your Mac Developer Program. If you signed up for the Mac Developer Program, you already can get Developer ID certificates. It's part of the deal. You already signed the paperwork. There's nothing new to sign. You just have it.

You get new certificates through Developer ID, separate from the ones that you used to get for working with the Mac App Store. We call them Developer ID certificates. It's not very creative, but, well, then it's a break. And those are there explicitly for distributing your stuff outside of the Mac App Store.

So it's complementary. We're not doing away with the Mac App certificates or the Mac App Store Developer Program. But now, for the first time, you've got a way to take your program and sell it through the Mac App Store using the old method or selling it anywhere else through Developer ID. And it's all done with Apple certificates. No more, you know, buying stuff from third parties, making your own stuff, wondering whether you did it right. Because, you know, we make it easy. That's our job. We're trying to make it easy to make cool stuff. Let's compare them.

If you go the App Store route, you distribute through the App Store. It's not your problem. Apple puts them on a server and deals with the users. If you distribute through Developer ID, it is your problem. Apple won't do it for you. You put it on your website and people download it.

It's your website or you lease it from someone. You can sell it to a third party. For all we care, you can put it on USB dongles and mail them through snail mail. Its distribution is totally up to you. Apple won't help you. We won't advertise. We won't bill for you. Your deal.

Rules-wise, you all know, you all should know, what the rules are for the Mac App Store program. You've got the program licensing agreement, you've got various appendices and attachments, and then you've got store review. Everybody here has some scars from store review. Developer ID doesn't have any store review because it doesn't have a store. It's direct. You sign your stuff, you give it to the user, the user's happy or he isn't. There is nobody at Apple who looks at your program and says you shouldn't do that.

If you do something you absolutely, positively shouldn't do, we'll let you know, but it's an after-the-fact thing. We'll find out. People will complain about you. But there is no pre-filtering. This is a big, big difference. I mean, that's good and bad. I mean, good, it means that if you've got stuff that the App Store rules don't allow, The Developer ID will let you sell it. It also means that the responsibility is totally up to you. If you screw up and you ship something that erases somebody's hard drive, there's nobody testing it for you. Don't do that.

Different certificates. I already talked about that. And yeah, App Sandbox. For those of you who were in the previous session and the rest of you, why weren't you? The App Store now requires that you use the App Sandbox. And that's good for the users. In many cases, it's good for you, but it means that some of the programs that you can usefully sell can't go into the Mac App Store.

If you have a disk formater, well, it's not going to go in the Sandbox. Developer ID can be used without App Sandboxing. Now, please don't misunderstand this. You should App Sandbox your programs, even if you sell them through Developer ID, because the App Sandbox is useful. It's useful for you. It's useful for your users.

Think of it as a parachute, an emergency brake, a way to land more softly when the excrement hits the rotating conveyance. And if you sell the same program in and out of the App Sandbox, it's going to be a lot easier to sell. Developer ID can be used without App Sandbox.

If you sell the same program in and out of the App Store, then it is really, really a good idea to use App Sandboxing on the Developer ID leg, because your program will behave differently if you don't App Sandbox. And you will end up with users complaining that your program doesn't behave right, because, you know, the guy over there uses it from the store, and the guy over here uses Developer ID. Don't get yourself in that situation if you can possibly avoid it.

Okay? And there's a little Benny that we threw in because we can. If you do sell your program both through the Mac App Store and outside with developer ID, and you follow the rules and you do what we tell you, these two programs, through the magic of designated requirements and code signing, will look the same to the system. They will be the same program.

They'll be signed differently. One will be developer ID signed. One will be store signed. But we did enough magic to make these programs look the same to the system. They can get the same keychain items. They'll be sitting in the same sandbox, container. They'll just be... They will have the same code identity.

All right. Graphics. So I talked about different certificates. This is the old way. This is the store way. You take your app and you sign it with your distribution certificate. And you send it off to App Store review. And the App Store reviews it. And when they like it, they re-sign it with a special certificate that only Apple has, that you don't have, and that specifically says, this came from the App Store.

It wasn't just sent to the App Store by some developer. It actually came through and out of the App Store and into the user system. So it's a two-step. There's Apple in the middle. Developer ID. Same thing, but you sign with your Developer ID certificate, you put it on your website. There's no Apple in here. Again, direct. It's good and bad. You directly go to your users, and you are totally responsible for how that works.

Well, rule number one, use Xcode 4.3 or later. We mean this. This isn't just use our greatest tools because they've got different windows and we're really proud of how they blinkle. There is special stuff in Xcode 4.3 and later that makes Developer ID work right in a number of circumstances. If you use an older Xcode, this will not come out right, and it'll look like it almost works. But not quite. And that would be unhappy for you and would be unhappy for your users. So Xcode 4.3.

In Xcode, there's a new section in the Archive panel that lets you archive to Developer ID, and it just does the whole job for you. It takes care of getting your Developer ID certificates through the portal. It refreshes them as they expire. It signs the right way. It puts the right designated requirement in that gets that magic identity between the store and out of the store.

You can use an old Xcode or you can use your favorite Makefile or Shell script invoking code signed directly, but you lose all of that Xcode magic and you have to reproduce it somehow or it won't come out right. I'm not going to tell you how to do that. Go check the developer forums where there's a lot of discussion of, you know, I hurt my big toe trying this. It can be done, but it's significant extra work to get this right, so try to avoid it if you possibly can.

All right. Really, really short demo, just to show you how this looks. This is a Cocoa App template straight out of Xcode with no changes except that I put some text in the dialogue. And you should all be familiar with the Archives section, which basically builds your program.

In a really short time. And then you get the option to distribute it. And normally you would be doing something like, you know, I want to export it as an application. And let's just leave the development signature in there that I have. And let's put it out there. So, you know, good old Xcode. And the same workflow, except exporting to a Developer ID signed application.

You get your choices of what Developer ID certificates you have. If you have multiple ones, you get to pick it here, and this one will basically take you on an exploratory trip to the Developer Portal to see what you can do there. Other than that, totally the same experience. Let's give it a different name.

I've just Developer ID signed. That's all to it. So if you use the Xcode workflow, there's really very little change. I used the same project. I used the same targets. I didn't change a single setting on this Xcode project. All you do is archive to Developer ID, you get the right signatures, you get the right everything. It'll just work. Good for you. Okay.

This isn't technically all specific to Developer ID, but let me tell you anyway. Cryptographic keys. The first time you sign up for "give me my Developer ID certificate," the system will make a set of cryptographic keys on your computer, because that's part of how this crypto machinery works.

It's made right there on your computer, whichever one it is that you are asking for Developer ID. And that's the only place where it is. These keys are your secret. They're supposed to be your secret. And Apple doesn't have them. Nobody else has them. That's the point. But this means that you better back them up. Because if you lose them, nobody can get them back to you. There is no way to get them back. They were your secret. If you lose all of your copies, they're gone.

That's not good because, well, you can't prove that you're you anymore as far as code signing is concerned. You can't make updates for this program anymore, at least not easily. So don't lose them. Xcode will actually pop up a panel that says, you know, now would be a good time to make a backup and archive this, so please do it. And make sure you actually have an off-site backup of this. There's a password in it. It's perfectly safe. Thank you.

This may not be totally obvious. Developer ID certificates belong to your team, your account, to whatever it is that you think of yourself as you're signing up for the Developer Program. You do not get one Developer ID certificate per developer or per group or per division. Or per project, you get one. Actually, a pair, but, well, the Actus one.

Apple will give you a few to help you with certain edge situations, but you are explicitly not supposed to use those for using different signing identities for your different applications. This won't work because after a couple, two, three, four will cut you off and then you'll be sad, so single. If you're a large company where these kinds of responsibilities are important, access to your Developer ID key will probably be controlled by some department, and you'll send them the code and they'll sign it for you.

And for those of you who work open source or just don't think about this, secret means secret. It means don't check those into some open source repository. It's against the rules, and it'll get your keys revoked. And then where would you be? And if you lose control of your key, "Oh my God, I had it on this laptop and I lost it in a coffee shop," or "I had it on this USB dongle and I don't know where I put it and maybe it isn't in my house," if you think you lost control of your key, talk to Apple. Because if somebody else gets a hold of that key, they can be you. And if they ship an application that erases everybody's hard drives, it'll be your fault. It'll be your good name that gets dragged through the mud.

You don't want this to happen. So there's an email address, [email protected]. You send them an email. You send them an email if you even think it's possible you could have lost your key. Because the consequences of not talking to Apple, it just happening to you, means that you're in an even worse situation when it comes out.

Well, if you've got a new program, it's obvious. Sign with Developer ID, you're done, happy. If you're currently shipping unsigned code, what the hell is wrong with you? But it's easy to get out of that. Sign with Developer ID. It'll be a different program, of course, since before it didn't have any identity, but now it has an identity, and it's a good one. It's one that Apple gave you, so you're good.

If you're currently shipping through the Mac App Store, use Developer ID to ship the same thing outside. It'll just work. You don't need a new project, you don't need a new target. It's better not to have a separate target. Keep them together. Use Archive to Developer ID. You're done.

If you currently use a code signature that didn't come from Apple, whether you bought it from some certificate authority or whether you made it yourself, you probably want to transition to Developer ID. I'm not saying you must. You can keep on shipping your program with the signature you got, but, well, we'll get to Gatekeeper and what he will do to that program.

If you want to transition to developer ID, there is a couple of approaches. There's cold turkey. Let's just switch, tell the users, and off we go. That's easy for you. It'll maybe not be so easy for your users. Or there is an actual transition process that I'm not going to explain to you because it's kind of lengthy. Check the developer forums where there's a FAQ for it. Check the documentation on designated requirements because that's what you use to do that. And if you're so confused, come to the labs, talk to me. I'll give you some hints.

That's Developer ID. Everything with Apple certificates. Isn't that great? It's not even extra money. Now, why did we bother? Well, okay, it's nice to have a way for you to get all of your certificates for your consigning needs from Apple. That's neat, you know, single-source shopping. But of course, there's more to it.

We've always worried about programs that get downloaded from the internet, because it's so easy to download stuff from the internet, and God knows what they'll do to you once you install them and run them. And over the years, we've come up with ways to mitigate the risk a little bit. One of them is called Download Quarantine. Let me tell you about it in case you don't know what it is. It's essentially a tag that gets attached to a file. We call it a quarantine flag.

That tag gets applied by the downloaders. When you download something through Safari, unbeknownst to you, maybe, it puts a tag on the file saying, "This came from this URL. It was downloaded at this date." But the most important thing is that the tag's on there. It says, "It came from the Internet.

Let's pay special attention to it because God knows what it'll do to your computer." When you take a quarantine file, a file that has a quarantine tag on it, and you copy it with the Finder or your favorite copy tool, the quarantine gets copied along because everything's been modified long ago to do that. If you expand an archive that has quarantine on it, everything that comes out of the archive is quarantined. You cannot shake that flag just with a normal set of operations.

If you have a quarantine disk image and you mount it, everything in there looks quarantined. So the point is that this tag sort of follows the data along once it's attached, so that at the point where you're actually trying to do something serious with it, like run an app inside of this disk image, we still know that it came from the Internet.

And then we do things to the program because it came from the Internet. And the classic thing is, "Hey, you meant to do that?" It's just, you know, click OK, it's fine, it's just a little speed bump in case that, you know, some website downloaded that for you and is now asking you to open it to do bad things to you.

Now, quarantine gets attached when stuff gets downloaded from the internet. If you make something locally, it doesn't get quarantined. If you have a file on there that you downloaded two years ago and you've worked with it, it doesn't have quarantine on it. That got stripped off when you answered that dialogue.

Quarantine does not usually apply to remote file systems either, so if your AFP or SMB mounts something from your file server, there's no quarantine involved here. Quarantine is for downloading from that big bad internet in the sky. Okay, so that's quarantine. That's basically, this came from the internet, let's pay attention to it.

Of course, once we know it came from the internet, there's a couple of things that we want to do, and one of them is the classic malware check that we all know about. You know, it's like, we know there are some things that are bad for you. They are signatures, patterns that we can look for. So we do.

And those get applied when Launch Services is asked to open something that has quarantine on it. So that's how these two fit together. And the pattern lists actually get updated potentially once a day. There's a little preference checkbox that's on by default. Basically, it says, let's just get an update every day to make sure that if bad viruses are trying to take over the internet, we know what they are.

And because a match on these quarantine flags is clearly a bad sign, we have a rather nastier dialogue that says, "This is bad for you. Please throw it away." You may notice there is no "Open Anyway" button here, because, no, really, you don't know better. If it actually fits our malware list, it's bad for you, and you should throw it away.

So that together forms what I might call the traditional way of dealing with possibly bad things coming from the Internet. We have these lists of known bad applications, and if something that you're trying to open or install matches those, we yell at you. Otherwise, it's probably OK. What do we know? The problem, of course, is evasion. If you're the guy who makes the bad app that tries to erase your hard drive, all you need to do is escape the pattern matcher. You look at the pattern, you change your program so it still erases your hard drive, but it looks different.

And, you know, then a couple hundred or a thousand more people get their hard drives erased, then the daily update comes out matching that pattern, and we keep playing until they run out of energy. which is not really a great way of doing it, so we're proposing to turn this upside down.

Instead of working with lists of things we think are bad, we're working with lists of things that we think are good. This of course means that if you're not on the good list, you're not supposed to be bad. You're just, you know, we don't know about you. You're not signed in a way that gives us the warm fuzzies, so you're not on the good list.

The problem here, of course, is that we all hope there's a heck of a lot more good programs in the universe than bad programs. And for this machinery to make any sense, it has to catch substantially all the good ones. That's the hard part. That's why Gatekeeper isn't, you know, 10 lines of code.

Gatekeeper is built into the operating system. It's a system facility. It's always running. You can't, like, you know, excise it. It's not an option. Its behavior is driven by a set of rules, configurable rules. So this is not a bunch of code that knows what it means to be a good program. It's configurable.

And, you know, it probably won't surprise you very much to hear that the matching is done through code signatures and code requirements. That's why I, you know, told you about this stuff earlier. Essentially, each rule says if it is code signed and the code signature looks like this, then it's okay. And of course, if no rule matches, then, well, we don't know. No.

Because it's rule-driven, it's highly configurable. That's important, but we all know that 90% of all systems never change their configuration. And just like the malware checks, it's driven by quarantine. So right now, Gatekeeper only looks at a file if it has been downloaded from the internet and has been quarantined.

This should make you relax a little bit. It means that the programs on your hard drive that you've been using for years are not suddenly going to be viciously attacked by Gatekeeper. And stuff that you build with Xcode, Gatekeeper isn't going to look at it and say, "This is a foreign body on my system. I'm going to..." Remember we built this thing just 15 minutes ago? And I put it into this directory, mysteriously called "sites." Let me just compress this.

So this is testy, which was signed with is a normal non-Developer ID certificate. And here is TestD Dev ID, which we signed. Well, why is it called Sites? Because I am going to use Safari to download these archives I just made, because downloading is the easiest way to actually attach Quarantine to it. I just turned on the web server on that system. So let's download that. And let's download that.

And here it goes into Downloads. Okay, so we have downloaded this. You can't tell from looking at it in the Finder that it has quarantine on it, because quarantine is supposed to be this internal thing that you don't need to worry about. And, well, let's see what happens. Oh, oh, no, it can't be opened because it's from an unidentified developer.

Notice it doesn't say it's from an evil developer. It doesn't say it's from a developer we don't trust. It doesn't say it's from a developer who didn't pay. It just means we don't know who that is. So we're not being judgmental here. But remember, the idea of Gatekeeper is if it's not on a good list, then no. That's the price we're paying here. Everybody who wants to be on that system needs to be on a good list. Let me show you the UI really quickly so you know what gets switched around here.

in the Security and Privacy section of Klaus. In the General section, here is a new part that says... Allow applications downloaded from -- if you've played with the developer releases, you've already seen this. And you get -- at the macro level outside, you get these three settings. The normal one is Mac App Store and Identified Developers. And any time the system talks about identified developers or identified programs, I want you to understand this means that there's a rule in Gatekeeper that says it's okay. That's what identified means.

It doesn't really mean just developer ID because the rules can be changed. By default, it means. And of course, we'll accept anything from the Mac App Store because if you can't trust the Mac App Store, who can you trust? If you are -- if you, the user, this is not for you, the developer, to switch around. This is for the administrator of that system.

If you don't trust those developer ID things, because God knows what they'll do, after all, you could erase your hard drive if they happen to be a disk formatting tool, you can switch to Mac App Store only and that disallows developer ID. It makes developer ID useless on that system in a sense. But we don't expect that to happen. It doesn't expect that to happen a lot. And then, of course, there is Anywhere, which essentially turns Gatekeeper off with very few exceptions. If a system is in the Anywhere state, it behaves just as if Gatekeeper wasn't there.

That's not a good thing, because we think Gatekeeper is useful and helpful to the user. So we would appreciate it if you didn't tell your customers to immediately switch off Gatekeeper because your program, you know, can't be bothered to be Developer ID signed. And yes, you get this little lecture here if you try to turn off Gatekeeper that says you shouldn't do that.

Alright, well, that was Unidentified Developer. Here's the Developer ID signed version. You still get a dialogue, and if you've ever used a Macintosh before with anything downloaded, you know that dialogue. This came from the internet. You haven't opened it before. You're sure you want to do this. This dialogue doesn't go away. Gatekeeper is sitting in there as an additional security layer. This dialogue is fairly harmless, assuming you actually meant to download this program and run it.

All right. Let me show you one more dialog you can run into. Because you'd think that this is bad. It tells the user, We don't want to run this here. We don't know where this came from. But this is not the bad dialogue. This is the relatively harmless dialogue. Let's go into that bundle and make a change to the program. It doesn't really matter what we change, because the entire info.p list is, of course, sealed down by the code signature. Let's save that. So basically, I hacked your program.

Oh, look. Now it's damaged and can't be opened, and you are in the bad case. Ooh, don't touch this program. Throw it away. So this is the bad dialogue. If your users see that dialogue about one of your programs, it means you screwed up the code signing, or somebody hacked it after you shipped it. Maybe your distributor, maybe an evil hacker. Who knows? So this is the dialogue you don't ever want your users to see. All right.

So what does Gatekeeper apply to? Well, obviously code, applications, not just applications, tools. In addition, Gatekeeper applies to installer packages, because installer packages have their own security things. I mean, yes, they install applications that you can process as applications later, but they also have things like pre-install and post-install scripts that can do unspeakable things to your system, particularly if you enter your admin password, because then they can do it to the entire system. So installers are dangerous, too. So we apply Gatekeeper and we apply signatures to installer packages, too.

There's two kinds of installer packages: flat ones, which is a single file, and bundled ones. You can't actually sign bundled installers, which means that you'll have to use flat installers to Developer ID sign your installers. If that confuses you, talk to the installer people or the Xcode people. I'll tell you later where to find them.

Gatekeeper also applies to certain classes of documents that the system thinks are dangerous. Shell scripts, you know. Certain things that you may not think are dangerous, but that we know better about, like Safari archives, because they have code in them. So, Gatekeeper can also apply to documents, and you get the same dialogue that says, you know, not from a recognized developer, and the same ways of processing that.

But of course, you know, sometimes you want to ship a bunch of documents. You can't really code sign those. That's the problem with them, because they're documents, they're not code. So, if you want to ship a bunch of dangerous documents to your users for some reason, and they understand this, and they want those dangerous documents, we invented a new archive format. It's a very straightforward, simple one. We call them chip files.

XIP is the extension. Just like flat installer archives, those can be signed. And if you put a Developer ID signature on a chip archive, then all of the stuff inside is marked OK. So, this is the way you take dangerous files, if you absolutely have to ship them to your users, and get them through Gatekeeper.

What I just said. So, Gatekeeper is driven by rules. And what Gatekeeper accepts and what it doesn't accept is entirely a function of what rules it has. Read the man pages. I'll tell you what they are for details. It can be fairly complicated. These rules are very flexible. They're meant to do a lot of things. One thing to understand is that there's different rules for execution and installation.

So if you look at a particular Gatekeeper rule and you stare at it and you go, "From everything he's told me, this should apply to my program," but it doesn't. It totally ignores it. It probably is an installation rule and you're trying to whitelist a program, or it's an application rule and you're trying to whitelist an installer. Different types, totally separate.

The outcome of Gatekeeper evaluations is cached because these evaluations, you know, you basically go through all of these rules, you test them one by one. You've got a lot of rules. This can get kind of slow. So we cache the outcome, which is a good thing, and you don't need to worry about it usually because, you know, we flush the cache at the right times.

If you start playing around with this by copying files around and, gee, I wonder what happens if I do this, then sometimes you need to remember that there's a cache and, you know, If you go behind the back of the mechanism by messing around with files directly, the cache may still hold old data. So keep that in mind.

Let's go back to that picture for code signing, but this time let's talk about how this specifically works with Developer ID and with code signing. So here's your final code. It's the same final code. Same project, same targets, everything. You haven't changed a thing. You feed it to Xcode, and did I mention Xcode 4.3 or later? Very good for you.

And when you do the archive to Developer ID part, behind your back Xcode is starting to codesign. It actually takes the build output from the archive step and it re-signs it with your Developer ID signature, which of course it gets from your keychain from where it has fetched it through the Developer Portal from Apple.

All done by Xcode. You don't do a thing. This just works. You get the output of the archive step, and that's where you come into play. You put it on your website, you send it over to your distributor, or you burn it on a DVD if you really want to be Stone Age.

And it ends up on the end user system, and because we assume for the sake of argument that this got downloaded through a web server, it is now quarantined. See how the pieces start fitting together? So you've got a quarantined installer archive or application, depending on how you shipped it.

And if you're trying to install that installer archive or first launch this application, because it's quarantined, Gatekeeper gets invoked. Launch Services does that. So now Gatekeeper is looking at this program and feeds it to the code signing verification machinery. And it has a database. It's var db system policy, in case you care.

That's where all the rules sit. It basically just runs through the rules, and each of the rules has a code requirement, and it just matches them up one by one in a particular priority order. So that's where the code requirements come from in the Gatekeeper case. They come out of the rules.

We run through, and the first rule that matches has an outcome. Usually it's, "This one's okay." You can actually make a rule that says, "This one is so not okay, I don't want to ever see it again." That's how code signing works in the case of Developer ID working with Gatekeeper.

Okay, so we talked about these rules, and if you're happy with the default, you don't do anything about them. They're just there, they work, you know? Good. Sometimes you want to change them because it's your Macintosh and you want it to accept something that isn't Developer ID signed, but you want it anyway. The default, anything coming with the system, of course, is okay. Anything from the Mac App Store is okay. Anything signed with Developer ID is okay.

You can make individual exceptions. There's UI for that. You may have noticed, those of you with the eagle eyes, when you try to turn off Gatekeeper in the system preferences, it actually tells you, "Don't turn me off. Do that instead." That's your first hint. Now, if you happen to be using OS X Server or you are really good with a binary editor, you can make configuration profiles that actually push Gatekeeper rules. This is new in Mountain Lion.

So if you have a bunch of systems whose people trust you, so they will actually double-click on configuration profiles that you send them, you can just package up a rule that says, you know, my programs are fine or this program is fine. Send it to them, say, please double-click that. And if they do, it adds a rule and they're fine.

Also, if you want to be more formal about this and you're using Workgroup Manager, it has learned in Mountain Lion to push Gatekeeper rules out to all of the managed clients. That's a really nice formal way of controlling which programs are allowed to be installed on systems that are part of your workgroup.

And if everything else fails and you know exactly what you want and you don't mind using Terminal, there's a new command called spctl, the System Policy Control Program, and it lets you edit those rules directly and explicitly and with a lot of detail. So if you're the tinkering kind, this is your new buddy.

So, it's built into Mountain Lion. It's part of Mountain Lion. It's on in Mountain Lion. The default value when you install a new Mountain Lion system is Mac App Store or Developer ID. So, this is going to hit you and your programs as Mountain Lion deploys. It's also been backported to a large extent into Lion, but in Lion it's currently dormant.

The code's there, but the UI, the major master UI that lets you turn it on or off is hidden, and it's off by default. So you don't notice it, the users don't notice it, but it's there in case you want to test with it and you don't have a Mountain Lion system handy.

You can actually get instructions from the developer website. There's a defaults write that makes the UI appear, and then you can turn the feature on and play around with it. No Mountain Lion required. This also means that users who know what they're doing and they care may turn this on on you. So it's possible that you will get complaints from users on Lion saying your program doesn't install here because you didn't get with the Developer ID program. Don't let that happen to you.

How do you test it? Well, it's pretty obvious by now. You sign your program with Developer ID. You put it on a web server. You download it. You can mail it to yourself, too, if your mail server actually accepts attachments big enough. You just need to get quarantine attached to it somehow.

And then you double-click it on the Finder and you watch what happens. I showed you. Either it'll launch, you're successful, everything's cool, or you get this unidentified developer dialogue that's not so cool. It means that you thought you were Developer ID signing, but you really didn't and something's wrong. Or you get this dialogue that says, your program is broken and please throw it away, which means you totally messed up the signing. If you run into trouble, well, it's time to break out good old terminal.

There is the new SPCTL command. It is the Swiss Army knife of Gatekeeper rules. It also lets you enable and disable Gatekeeper from the command line. In particular, there is a --ss option that lets you directly ask Gatekeeper, what do you think of that file? That doesn't require a quarantine.

It's a direct call. Basically, "Hey, Gatekeeper, what do you think?" He just looks at it and goes, "Okay," or, you know, "I'm not going to allow this." This calls the same API as Launch Services does when you're going through the double-click path. So you're directly asking the same oracle.

And that's spctl -add, which actually lets you add a rule. So this is what you tinker with if you want to tell Gatekeeper that stuff like that is okay on my system. And of course, there's a remove and lots of other things. All right, there's the good old code sign command with you since about 2005.

It's there so you can sign code, but Xcode does that for you, and you will just use Xcode 4.3 or later, and you will be happy. It will call it for you. But you can also ask Xcode Sign to verify code signature, and that's kind of handy, because if you give it enough levels of verbosity, it will actually tell you, in many cases, what's wrong with the code signature.

In particular, it will tell you if you stealthily tried to add or remove files, resources after you signed, which is something that sometimes happens, but it shouldn't. So it'll just say, this file there, you shouldn't have added that. There's also Code Sign Display, which basically tells you everything that's in a code signature.

That's kind of handy sometimes, and in particular, it tells you what certificates a piece of code was signed with. That's a really easy way of seeing if you're actually looking at a developer ID signed program, because the word developer ID is right in there. And if it isn't, then you didn't, and you just signed with the wrong thing.

There is a very obscure program called CSREC that I'm just mentioning here for the first time ever. This is a little editor for code requirements. If you play around or mess around with code requirements, take a look. To sign installer archives, we are telling you to use the product sign command. The product sign command is known to do okay with Developer ID signatures.

There is a surprising number of different programs that can sign installer packages, and some of them do better than others. So we're telling you to use the product sign command. And of course there is the shiny new chip command which exists solely for the purpose of making chip archives that you can sign in the process of making them, and then you can send them out to get those dangerous commands through Gatekeeper.

And that's it. Paul Dambold is the evangelist who is always so sad that none of you give him a call. So he is your first point of official contact if you have any questions, complaints, or other contact requests. There is an entirely new section in the developer documentation on Developer ID, which really should be read like Developer ID and Gatekeeper. It contains a tutorial, it contains some background information, some technical information. Think of it as sort of your jumping off point on this entire thing. It's there. If you haven't read that, don't complain. Read first.

There's also a dedicated forum in the Apple Developer Forums on Developer ID and Gatekeeper where, you know, you know how the Developer Forums work. You are talking to each other and then Apple says, "No, that's wrong." But there's already some really useful information there. So really, before you start making up theories on how this stuff should work for you, read the developer forums on Developer ID because it's useful stuff. And contribute. You know, like, you too can say, "This did not work for me." It's perfectly all right.

Related sessions. Well, I keep telling you to use Xcode, so there is a session on building, archiving, and submitting your app. This is the session that talks about Xcode and how you use it to bundle up your stuff and get it ready for sending it off, both to the App Store and through Developer ID.

They will actually show you the Developer ID path and they will talk about it in a little bit of detail. So if you're having questions about the Xcode side of this, this is the session you want to go to. You missed the sandbox session just before this one, but we made you a repeat on Friday. So if you missed sandbox, you got another chance.

Summary. What have I told you? This, Gatekeeper is about helping the owner of a Mac control what goes there. This isn't about some people telling other people what they can do with their Mac. This is about controlling your own Mac's destiny. Gatekeeper is a tool for that. It happens to have a preset as it comes out of the box that says, by default, it's OK to install stuff from the Mac App Store and stuff that's signed with this developer ID thing. So that's what developer ID is, primarily. It's your way of getting your stuff through Gatekeeper on default configurations.

Gatekeeper is real, and when Mountain Lion ships, it'll be right there in your face. It won't yell at you if you don't install anything that isn't Developer ID signed. And yes, you are going to run into Lion systems that have it on too, so be prepared for that. That's all.