Comments on: Development Phase Code Signing Mac & Technology Writings by Daniel Jalkut Sun, 16 Mar 2014 19:39:31 +0000 hourly 1 By: Ilgaz Mon, 07 Jul 2008 02:47:20 +0000 I think if your application has server capabilities (so Leopard prompts), you should tell the user not to apply “clean languages” (can contact Monolingual team to add it to ‘black list’ too, or even edit source it is OSS) or change its icon, remove architectures etc.
As a person always cleaned up languages, I resist doing it on Leopard. I liked the scheme and the fact that it is not a commercial trap (self signed is equal) like Windows one and unless the application modifies its own .app dir, it really works flawlessly.
Another approach to prevent people from cleaning(!) languages is not to include them. 1 Password (Agile) current version says “We removed languages from download” but they promise a way to let users have their languages included in future in updates.
Or Omni’s approach, their actual stable versions always have “English only” and “International” versions. Note that they had that scheme for years, long before Leopard.
Another thing to note which I noticed as a end user is, Leopard HFS+ handles lots of directories, files in a way that older OS X could never do. The B-Tree fragmentation etc. are way lower. That is another reason not to bother with “language cleaning”. For cleaning languages, my reason was to keep the boot disk as simple as possible. Apple somehow does way better directory handling so I really don’t care.

By: Daniel Jalkut Wed, 02 Jul 2008 15:16:08 +0000 Regarding compiled xibs and their alleged “unopenability,” this is a default setting in Xcode for compiling nibs, but can be overridden. I am using some xibs in my projects, and have them set to generate normal, openable nibs.

By: dc Wed, 02 Jul 2008 06:26:57 +0000 @dave, @jean-daniel:
“I don’t think user-editable nibs is a use case most developers are keen to support.”
“Try to compile a xib file and then to open it for example.”

This is the thing that pisses me off most about .xibs. I can understand the utility of space saving on the iPhone, but on the desktop making .nibs write-only is super annoying. Nib hacking is one of my favorite OS X pastimes. (Especially since there’s no good technical reason why IB shouldn’t be able to open compiled .xibs.)

By: Jean-Daniel Tue, 01 Jul 2008 10:58:32 +0000 @dave:
Modern nibs are no longer editable, and code signing has nothing to do with it. Removing informations required to edit the nib significantly reduce the distributed file size. Try to compile a xib file and then to open it for example.

@Perry The Cynic
Thank you for this very interesting comment and for your answers. I understand the need to specify which version you want to sign in a Framework, but it prevent usage of one single script to sign all bundles :-(
I Hope the Xcode 3.1 integration will solve this issues.

By: Felix Schwarz Tue, 01 Jul 2008 10:04:57 +0000 One unfortunate side effect to the use of code signing under Leopard is that, if

1) you write an application with an embedded server

2) the user needs to add an exception rule for it in Leopard’s firewall in System Preferences

3) the application bundle then gets modified by the user (by any of various third party apps that promise to “save disk space”, make an application “dockless” or otherwise modifying your application’s bundle)

the user will end up with this (at least up to 10.5.3 – I haven’t tried with 10.5.4, yet):

1) The firewall rule is still displayed in System Preferences

2) But as the code signing of your app’s bundle is now broken, Leopard ignores that rule. All incoming connections will be blocked by the firewall.

3) Removing and re-adding that rule will not change that. Your application’s copy is now permanently unable to receive incoming connections until the user either reinstalls your application (so that code signing is intact again) or deactivates the firewall altogether.

I hope Apple will handle such cases more gracefully in the future, i.e. by indicating broken code signing in the preferences, so users have a chance to identify the issue rather.


By: Perry The Cynic Tue, 01 Jul 2008 05:46:01 +0000 Daniel:
Thanks for giving it a try. Code Signing really is pretty painless.
Apple does not recommend that you publish with a self-signed identity. You can, but it removes a lot of flexibility from the system. At least, make yourself a CA and issue one signing identity from it. (Five minutes in Certificate Assistant.) That preserves all the flexibility of the X.509 certificate system and lets you expand your CA later without invalidating existing signatures. For testing, of course, a self-signed identity works just fine.

Note that for keychain use, there is no advantage to getting a paid-for identity from a commercial CA. The keychain does not care whether your signing identity is system-trusted or not; it only cares whether it remains stable. A home-made CA works just as well for this. (That is also true for Parental Controls.)

Don’t let all the options in codesign(1) scare you – most of them are for special cases and unusual situations.

A frequest question is how you can separate test-signing from “real” (release) signing. Commonly, people use two different CAs (or a CA and a self-signed cert). That means, of course, that the system doesn’t believe that a test-signed program is the same as a release-signed one. Depending on your situation, that may or may not be a problem. If it is, there’s keychain ACL tricks to make it work (at the price of a bit of complication, of course).

Right now, Apple provides developer code signing identities only for the iPhone (and Touch). Those happen to also work for signing Mac OS X code, though they’re not really meant for that purpose.
If you expect Apple to run a free CA for its developers, don’t hold your breath. It costs quite a bit to run the infrastructure (and keep the lawyers happy). If you want free, make your own CA. It’s not that hard (using Certificate Assistant).

This is a very common misconception. You do not have to “trust” any certificate for the system to recognize a signature made with it, unless the verifying agent explicitly requires that. Neither the keychain nor Parental Controls do this. Whether the CA (anchor) is trusted on the end-user system is completely irrelevant to these subsystems, and neither you nor your users can tell the difference.

You see no protection in a developer being able to say, “I really made this program, and it hasn’t been hacked since it left my computer”? This isn’t about Apple saying anything about code. It’s about giving developers a reliable way of asserting the identity of their code, and giving you a reliable way of asserting policy on your system about who you want to trust. The software just connects the two of you and referees your interactions.

Frameworks are “versioned bundles”. You need to sign (and verify) the particular version (usually …/Foo.framework/Versions/A). Yes, that could be clearer, and more fool-proof.

@Justin M.:
Self-modifying programs were always broken by Apple’s standards. The golden rule has always been that if it writes into your bundle, it’s a bad idea. (What if you’re running off a read-only file server, or (shudder) a CD-ROM? Yes, schools still do that.) Code signing just doesn’t let programmers get away with it anymore.

@Peter Maurer:
Sorry about the little Scrubber. I can’t think of a way to keep it going without adding a feature to the Mac OS that would make it redundant…

Code signing does not prevent the end-user from modifying code. It only prevents the end-user from changing code and then pretending that it hasn’t changed. If you want to take responsibility for your changes, make them and then re-sign the code with your own identity. (Yes, you can.) Of course, then you’re the one vouching for the code with your own identity and taking responsibility for tracking updates and all that jazz. But that’s as it should be.

@Smokey Ardisson:
When an application’s signature breaks (or it invalidates for a dynamic reason), it stops having an identity at all. That doesn’t (by default) kill it, but it keeps it from trading on that identity to get stuff, including keychain items. That means it needs to fall back on other means, such as user dialogs.
Leopard as delivered has a switch thrown “on” that suppresses keychain dialogs for signed applications whose signature is broken. That’s a UI decision that was made on “user confusion” grounds, and it’s certainly debatable. If you disagree with it, remove the -i flag from /System/Library/LaunchDaemons/ (and reboot), and you’ll get a nice dialog telling you that the application has a broken signature, and do you want to allow access anyway (this time)? You can’t “Always Allow”, of course, since there’s no reliable identity to record for the future.

— perry

By: Smokey Ardisson Tue, 01 Jul 2008 05:15:57 +0000 I’ve seen very conflicting reports about the case Martin Pilkington describes just above (when code suddenly fails to match the signature).

On the one hand, there’s that quote from Apple (which really addresses only the application running, not the application’s access to code-signature-gated services in the OS), where all is well, or as it was pre-code-signing, in the case of a failure to match.

On the other hand, there were the reports of applications (e.g. Safari) being completely unable to access data in the Keychain after they had done something to the application to make it fail to match the signature.

I’ve not tried any such modifications myself to see what happens, but given the number of reports and utility applications which changed their behavior after 10.5 shipped, I tend to believe the scenario in the latter hand. Further, if the former scenario really is the case, then there’s not much user protection from maliciously tampered code in the Keychain and Firewall using signatures; until the day when all code is signed and granting Keychain access only happens once per app, many users will simply think a maliciously tampered app is just prompting for access “again,” “as usual.” There go those passwords.

Ideally these types of modifications (plist tweaks, nib changes, delocalizations, etc.) are discouraged, but up to now they’ve generally been harmless and users still expect the modifications to 1) be functional and 2) not screw up apps’ access to the Keychain. There’s tension to be resolved here, and I think a certain segment of the Mac user community will be unhappy with the side that will emerge on top.

By: Rich Tue, 01 Jul 2008 04:44:15 +0000 Will deleting unused languages result in an app being considered tampered with?

By: Martin Pilkington Tue, 01 Jul 2008 00:14:11 +0000 There is a very key point to be made here. When a code sign fails, all that happens is OS X reverts to the old way of doing things. An app doesn’t break if you modify something, it will still run. To quote Apple:

“It is not a digital rights management (DRM) or copy protection technology. Although the system could determine that a copy of your program had not been properly signed by you, or that its copy protection had been hacked, thus making the signature invalid, there is nothing to prevent the user from running the program anyway.”

By: Damien Sorresso Tue, 01 Jul 2008 00:06:44 +0000 @Julik: Your arguments might be valid if Mac OS X (a) would only allow you to trust certificates signed by a CA such as Thawte or VeriSign, (b) didn’t allow you to create your own signing authority or (c) didn’t allow you to trust whichever CA or self-signed root certificate you wanted.

Since none of those things is true, you’re just being paranoid. Yes, Apple engineers have stated that Mac OS X will move to an all-signed environment eventually, but Mac OS X and iPhone are not the same thing. In the Brave New World, having a CA-signed certificate may confer certain advantages (such as the user not being prompted to explicitly trust your code), but I doubt the user will be prevented from running code that’s not signed by a trusted anchor.

As to users editing their nibs, after making the edits, they can re-sign the app themselves, with their own root certificate, if they really want. For anyone mucking around with nib files, this shouldn’t be too much of a problem.