ArchiveOrangemail archive

Apple's implementation of CDSA. (Common Data Security Architecture)


apple-cdsa.lists.apple.com
(List home) (Recent threads) (100 other Apple lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 765 messages, beginning Oct 2009
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Sign for Gatekeeper using command-line (codesign)

Ad
Jerry Krinock 1339763685Fri, 15 Jun 2012 12:34:45 +0000 (UTC)
I have an app built with Xcode 3, which is signed in my shipping script, using the 'code sign' command-line tool to sign all executable components, as explained in the Code Signing Guide.  I have been using a self-signed certificate.  The app is distributed in a .zip or .dmg and does not have an installer.

Now, of course, I want my app to pass Gatekeeper by default.  I think that all I need to do is (1) get the appropriate certificate(s) into my Keychain using Xcode 4, and (2) change my script to use one of them.  Is it that simple, I hope?

So I ran Xcode 4, followed the instructions in the Tools Workflow Guide for Mac.  Things did not work quite as outlined in the Guide, possibly because I did it first a few days ago with Xcode 4.2.  But anyhow I now have three candidate certificates in my Mac OS X Keychain:

[1]  3rd Party Mac Developer Installer: Jerry Krincok    expires 2013 Jun 12
[2]  3rd Party Mac Developer Application: Jerry Krinock  expires 2012 Sep 13
[3]  Mac Developer: Jerry Krinock (XXXXXXXXXX)           expires 2013 Jun 12

Which one should I use?

[1] appears to be for an Installer, so that's not the one I want.
[2] looks like what I want, "Developer Application", however from the expiration date it appears to be something that I generated in September 2011, when I was toying around with a Mac App Store App that I never shipped.
[3] is maybe the one that I should use.  Is that correct?

Thanks,

Jerry Krinock
Thomas Tempelmann 1339764969Fri, 15 Jun 2012 12:56:09 +0000 (UTC)
(Once more, including the list this time)> I now have three candidate certificates in my Mac OS X Keychain:
>
> [1]  3rd Party Mac Developer Installer: Jerry Krincok    expires 2013 Jun 12
> [2]  3rd Party Mac Developer Application: Jerry Krinock  expires 2012 Sep 13
> [3]  Mac Developer: Jerry Krinock (XXXXXXXXXX)           expires 2013 Jun 12
>
> Which one should I use?You are missing the correct one. You need the one reading "Developer
ID Application".

Forget Xcode 4. Go to Apple's website for certs and
do it there. You should find the prompt for creating this as an option
there, along with also creating a similar one called "Developer
ID Installer" which you probably won't need later. Then download the
cert(s) and open them in Keychain Access.

Your command for signing for GateKeeper would then look like this:

codesign -f -s "Developer ID Application" "Appname.app"-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Garth Cummings 1339770609Fri, 15 Jun 2012 14:30:09 +0000 (UTC)
Developer ID signing is supported by Xcode 4.3 and later. It will sign with the correct designated requirement which signing by hand or with earlier Xcode versions won't by default. 

--gc

Sent from my iPhoneOn Jun 15, 2012, at 5:55 AM, Thomas Tempelmann  wrote:

> (Once more, including the list this time)
> 
>> I now have three candidate certificates in my Mac OS X Keychain:
>> 
>> [1]  3rd Party Mac Developer Installer: Jerry Krincok    expires 2013 Jun 12
>> [2]  3rd Party Mac Developer Application: Jerry Krinock  expires 2012 Sep 13
>> [3]  Mac Developer: Jerry Krinock (XXXXXXXXXX)           expires 2013 Jun 12
>> 
>> Which one should I use?
> 
> You are missing the correct one. You need the one reading "Developer
> ID Application".
> 
> Forget Xcode 4. Go to Apple's website for certs and
> do it there. You should find the prompt for creating this as an option
> there, along with also creating a similar one called "Developer
> ID Installer" which you probably won't need later. Then download the
> cert(s) and open them in Keychain Access.
> 
> Your command for signing for GateKeeper would then look like this:
> 
> codesign -f -s "Developer ID Application" "Appname.app"
> 
> -- 
> Thomas Tempelmann, http://www.tempel.org/
> Follow me on Twitter: http://twitter.com/#!/tempelorg
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Apple-cdsa mailing list      
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/apple...
> 
> This email sent to 
Jerry Krinock 1339787884Fri, 15 Jun 2012 19:18:04 +0000 (UTC)
On 2012 Jun 15, at 07:24, Garth Cummings wrote:

> Developer ID signing is supported by Xcode 4.3 and later. It will sign with the correct designated requirement which signing by hand or with earlier Xcode versions won't by default.Hello Garth,

I sure hope I don't have to try and build this big old app with Xcode 4.

I presume, as Rustam explained, that Xcode 4 is using the codesign tool under the hood, and therefore since Xcode can do it, my script can do it … not "by default" as you say, but given the proper certificate and other parameters.  Correct?

Can the "designated requirement" you refer to be simply stated as a parameter to codesign? 

Thanks,

Jerry

(In the meantime, following the others' advice, I found that Developer Certificate Utility on developer.apple.com fails to create either of the Developer ID certificates for me, so I am working through that issue with DTS.)
jonathan1339791311Fri, 15 Jun 2012 20:15:11 +0000 (UTC)
On 15 Jun 2012, at 20:17, Jerry Krinock wrote:

> 
> On 2012 Jun 15, at 07:24, Garth Cummings wrote:
> 
>> Developer ID signing is supported by Xcode 4.3 and later. It will sign with the correct designated requirement which signing by hand or with earlier Xcode versions won't by default.
> 
> Hello Garth,
> 
> I sure hope I don't have to try and build this big old app with Xcode 4.Even if you don't build the app with Xcode 4 you could install the ID certs on a machine with Xcode 4 installed.
Then build and sign a dummy app and excise the code sign transcript.
This is a shot in the dark though.> 
> I presume, as Rustam explained, that Xcode 4 is using the codesign tool under the hood, and therefore since Xcode can do it, my script can do it … not "by default" as you say, but given the proper certificate and other parameters.  Correct?Yes.> 
> Can the "designated requirement" you refer to be simply stated as a parameter to codesign? 
>Yes. See the man page.

If it helps my Xcode 4.3 codesign build transcript looks something like this:

CodeSign /Users/Jonathan/Library/Developer/Xcode/DerivedData/KosmicTask-aptfipjecquvxddhdzrqjrkmssgc/Build/Products/Release/KosmicTaskServer
    cd /Users/Jonathan/Documents/Computing/source/KosmicTask/KosmicTask/KosmicTask/source
    setenv CODESIGN_ALLOCATE /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate
    /usr/bin/codesign --force --sign 0246b266ea2cae9d908f15acc6770a543bd1377a --requirements "=designated => anchor apple generic  and identifier \"com.mugginsoft.kosmictaskserver\" and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or ( certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists  and certificate leaf[subject.OU] = \"CB447UP272\" ))" /Users/Jonathan/Library/Developer/Xcode/DerivedData/KosmicTask-aptfipjecquvxddhdzrqjrkmssgc/Build/Products/Release/KosmicTaskServer


Regards

Jonathan Mitchell
Mugginsoft LLP
Garth Cummings 1339791349Fri, 15 Jun 2012 20:15:49 +0000 (UTC)
Hi Jerry,

You can see the DR that Xcode 4.3 generates and pass that to codesign. But it's not officially supported.

--gc

Sent from my iPhoneOn Jun 15, 2012, at 12:17 PM, Jerry Krinock  wrote:

> 
> On 2012 Jun 15, at 07:24, Garth Cummings wrote:
> 
>> Developer ID signing is supported by Xcode 4.3 and later. It will sign with the correct designated requirement which signing by hand or with earlier Xcode versions won't by default.
> 
> Hello Garth,
> 
> I sure hope I don't have to try and build this big old app with Xcode 4.
> 
> I presume, as Rustam explained, that Xcode 4 is using the codesign tool under the hood, and therefore since Xcode can do it, my script can do it … not "by default" as you say, but given the proper certificate and other parameters.  Correct?
> 
> Can the "designated requirement" you refer to be simply stated as a parameter to codesign? 
> 
> Thanks,
> 
> Jerry
> 
> (In the meantime, following the others' advice, I found that Developer Certificate Utility on developer.apple.com fails to create either of the Developer ID certificates for me, so I am working through that issue with DTS.)
>
Jerry Krinock 1339850865Sat, 16 Jun 2012 12:47:45 +0000 (UTC)
On 2012 Jun 15, at 13:13, Garth Cummings wrote:

> You can see the DR that Xcode 4.3 generates and pass that to code sign.I was thinking Build Transcript ("BT").  What is "DR"?On 2012 Jun 15, at 12:55, Stephane Sudre wrote:

> Previous cases why it failed on my side…Thanks, Stephane.  Probably these cases don't apply to me because I'm a one-person shop.  We'll see what DTS says, though.

This project is on hold until next week.  Waiting for DTS to figure out why Developer Certificate Utility won't generate the two Developer ID certs for me.
jonathan1339854587Sat, 16 Jun 2012 13:49:47 +0000 (UTC)
On 16 Jun 2012, at 13:47, Jerry Krinock wrote:

> 
> On 2012 Jun 15, at 13:13, Garth Cummings wrote:
> 
>> You can see the DR that Xcode 4.3 generates and pass that to code sign.
> 
> I was thinking Build Transcript ("BT").  What is "DR"?designated requirement as passed to code sign, e.g (taken from BT):

"=designated => anchor apple generic  and identifier \"com.mugginsoft.kosmictaskserver\" and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or ( certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists  and certificate leaf[subject.OU] = \"CB447UP272\" ))"


Regards

Jonathan Mitchell
Mugginsoft LLP
Jerry Krinock 1340218298Wed, 20 Jun 2012 18:51:38 +0000 (UTC)
On 2012 Jun 16, at 06:42,  wrote:

> On 16 Jun 2012, at 13:47, Jerry Krinock wrote:
> 
>> What is "DR"?
> designated requirement as passed to code sign, e.g (taken from BT):
> 
> "=designated => anchor apple generic  and identifier \"com.mugginsoft.kosmictaskserver\" and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or ( certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists  and certificate leaf[subject.OU] = \"CB447UP272\" ))"Oh, that's what I call "the hard part".  Thank you, Jonathan.

Still waiting for DTS to figure out why their online Developer Certificate Utility won't generate Developer ID certificates for me :(
Perry The Cynic 1340225871Wed, 20 Jun 2012 20:57:51 +0000 (UTC)
On Jun 16, 2012, at 6:42 AM,  wrote:

> 
> On 16 Jun 2012, at 13:47, Jerry Krinock wrote:
> 
>> 
>> On 2012 Jun 15, at 13:13, Garth Cummings wrote:
>> 
>>> You can see the DR that Xcode 4.3 generates and pass that to code sign.
>> 
>> I was thinking Build Transcript ("BT").  What is "DR"?
> designated requirement as passed to code sign, e.g (taken from BT):
> 
> "=designated => anchor apple generic  and identifier \"com.mugginsoft.kosmictaskserver\" and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or ( certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists  and certificate leaf[subject.OU] = \"CB447UP272\" ))"By the way, those of you revolted by all that quoting and unquoting - you can put that formula (without the leading '=') into a file and give the name of the file as the command-line argument. You can even reformat the formula - that might make it somewhat less inscrutable. :-)

designated =>
anchor apple generic	/* signed by Apple anchor certificate */
	and identifier com.mugginsoft.kosmictaskserver
	and (
		cert leaf[field.1.2.840.113635.100.6.1.9] exists	/* from the Mac App Store */
		or
		(certificate 1[field.1.2.840.113635.100.6.2.6] exists	/* from a Developer ID authority */
			and certificate leaf[field.1.2.840.113635.100.6.1.13] exists /* a Developer ID certificate */
			and certificate leaf[subject.OU] = CB447UP272)	/* developer's TEAMID */
		)

... or whatever sense of whitespace, indentation and commenting most appeals to you. Of course, that beauty is only skin-deep:

$ csreq -r drfile -t
designated => anchor apple generic and identifier "com.mugginsoft.kosmictaskserver" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = CB447UP272)

Cheers
  -- perry> 
> 
> Regards
> 
> Jonathan Mitchell
> Mugginsoft LLP
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Apple-cdsa mailing list      
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/apple...
> 
> This email sent to ---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
Jerry Krinock 1343227773Wed, 25 Jul 2012 14:49:33 +0000 (UTC)
Finally wrangled my Developer ID out of DTS. [1]

After re-reading all of your posts and documentation, and fighting with Xcode 3/4 and Keychain Access for a couple hours, it seems to have worked, except I'm not sure because an old self-signed version of my app, although rejected by spctl, launches in 10.8 too. [2]

I added something to the codesign incantation which Xcode does not do.  One of the designated requirements (DR) generated by Xcode 4 is that the code signature's identifier be the app's bundle identifier.  From Jonathan's DR,

>  identifier com.mugginsoft.kosmictaskserver

However, Xcode 4 does not pass an --identifier argument to codesign.  According to man codesign, in this case, codesign will get one "derived from … Info.plist or …".  "Derive from" apparently means "the CFBundleIdentifier", but especially with my nested bundles, I was worried about relying on this undocumented behavior.  It seems to me that the bundle identifier which I put in the --requirement argument should also be passed as the --identifier argument.  Then they would be guaranteed to match.  So that's what I did, adding an --identifier argument to my codesign invocation.

Note that this means that *all* 15 signable code objects in my app's package, including binaries, frameworks, a helper app bundle, and an NPAPI plugin bundle, are all signed with the same identifier, the bundle identifier of the main app.  Is this correct?  (The documentation is kind of vague on that too.)

Anyhow, thanks again for the help.  If anyone wants to offer any advice on [2] below, that would be great!

Jerry Krinock

[1] The 34-day delay was how long it took DTS to figure out why I couldn't create my Developer ID certificate.  I had to threaten to ride my bike over to 1 Infinite Loop and not leave until I had a Developer ID certificate.  The solution: Developer Certificate Utility seems to have started working after a DTS level-2 tech in Ohio suggested that I "reset" Safari.

[2] https://devforums.apple.com/thread/160879?tst...
Perry The Cynic 1343241610Wed, 25 Jul 2012 18:40:10 +0000 (UTC)
On Jul 25, 2012, at 7:49 AM, Jerry Krinock wrote:

> Note that this means that *all* 15 signable code objects in my app's package, including binaries, frameworks, a helper app bundle, and an NPAPI plugin bundle, are all signed with the same identifier, the bundle identifier of the main app.  Is this correct?  (The documentation is kind of vague on that too.)Do NOT do this. It is WRONG.

Every distinct piece of code you send out MUST have a distinct signing identifier. This is what keeps the system from thinking all those codes are the same. This is not a good thing. Properly distinguishing pieces of code is important, particularly as code signing gets woven deeper and deeper into the fabric of the system.

Give every piece of code you vend a distinct signing identifier. If you believe that the current documentation is kind of vague about this, please file a radar - it is meant to be crystal clear about it, and I'll be happy to add some BOLD CAPITAL LETTER WORDS to the documentation to make sure it is.

Yes, this means your hand-knitted DRs must be distinct for each piece of code. We may make this more convenient down the road, but that's the state of play today.

Cheers
  -- perry
---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.---------------------------------------------------------------------------
Stephane Sudre 1343246048Wed, 25 Jul 2012 19:54:08 +0000 (UTC)
On Wed, Jul 25, 2012 at 11:16 AM, Perry The Cynic  wrote:
> On Jul 25, 2012, at 7:49 AM, Jerry Krinock wrote:
>
>> Note that this means that *all* 15 signable code objects in my app's package, including binaries, frameworks, a helper app bundle, and an NPAPI plugin bundle, are all signed with the same identifier, the bundle identifier of the main app.  Is this correct?  (The documentation is kind of vague on that too.)
>
> Do NOT do this. It is WRONG.
>
> Every distinct piece of code you send out MUST have a distinct signing identifier. This is what keeps the system from thinking all those codes are the same. This is not a good thing. Properly distinguishing pieces of code is important, particularly as code signing gets woven deeper and deeper into the fabric of the system.
>
> Give every piece of code you vend a distinct signing identifier. If you believe that the current documentation is kind of vague about this, please file a radar - it is meant to be crystal clear about it, and I'll be happy to add some BOLD CAPITAL LETTER WORDS to the documentation to make sure it is.
>
> Yes, this means your hand-knitted DRs must be distinct for each piece of code. We may make this more convenient down the road, but that's the state of play today.What are the recommendations/way to proceed for command line tools to
make them distinguishable then (and keep a 10.5 or later compatibility
ideally)?  (as they don't have identifiers by default).
Perry The Cynic 1343249679Wed, 25 Jul 2012 20:54:39 +0000 (UTC)
On Jul 25, 2012, at 12:53 PM, Stephane Sudre wrote:

> What are the recommendations/way to proceed for command line tools to
> make them distinguishable then (and keep a 10.5 or later compatibility
> ideally)?  (as they don't have identifiers by default).They do. Every signed piece of code has a signing identifier; they're not optional.

The *default* signing identifier for a something without an Info.plist (and thus without a bundle identifier to default it to) is the plain filename, possibly modified by the --prefix option; and this is the generally recommended usage:

	codesign --sign mykey --prefix com.mycompany. /foo/bar/baz

will pick com.mycompany.baz as the signing identifier. All of that has been in place since the beginning (10.5). It doesn't matter how you arrive at your signing identifier; once in the signature it's just a string. The --prefix option is a convenience for signing scads of tools and dylibs without having to manually pick an identifier for each one. (At least as long as you don't have two with the same filename. :-)

Again, this is laid out in some detail in the code signing web pages, as well as the codesign(1) manpage. If you find it obscure or misleading, please file documentation radars explaining your confusion.

Cheers
  -- perry
---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.---------------------------------------------------------------------------
Thomas Tempelmann 1343255024Wed, 25 Jul 2012 22:23:44 +0000 (UTC)
Perry,

My apps (made with Real Studio) contain a lot of dylibs.
Does that mean that each of these dylibs I have to codesign with a
separate identity?

Currently, I do this:

   codesign -f -s "Developer ID Application" *.dylib

Would it be safe to change it to:

   codesign -f -s "Developer ID Application" --prefix com.myname. *.dylib

If so, this is quite surprising to me (and others, it appears). When I
did read about doing manual codesigning at the time the Mac App Store
was introduced, those web pages did certainly not mention this
explicitly. Maybe they do now.

And even if "man codesign" contains this info somewhere in it, the
issue for us is always that unless are TOLD what we NEED to do, we
can't figure this out from reading man pages that list a lot of
options -- because these only help when one already knows that one
needs said options. In my experience, man pages are practically never
helpful when it comes to understanding how to use such tools. Many
tools writers to not even bother to include examples, let alone
explain how they're to be used.

Most man pages, and codesign's is no different, are only explaining
what the tool does, not how it's to be used. I wonder if the same
programmers who write these docs also document their code like this
(or rather not at all - "the code is obvious", after all (-> Ed Post)
;)  (Hint: good code docs explain what the outcome of the code shall
be, not what it actually does)

Sorry, stopping my general Unix rant now :)

Note, for instance, that while the man page explains that "--prefix"
is useful for signing single-file executables, or makes no mentioning
of signing libs that way. If libs need to be signed with their own
identifier, then please make this more clear in the man page,
referring to best using it with the prefix modifier.

I don't expect "man codesign" to be more verbose, really, but it only
can act as a reference, not as a guide. We need a more comprehensive
guide for code signing. And Perry being on this list is a start -
thanks!-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Perry The Cynic 1343259895Wed, 25 Jul 2012 23:44:55 +0000 (UTC)
On Jul 25, 2012, at 3:22 PM, Thomas Tempelmann wrote:

> Perry,
> 
> My apps (made with Real Studio) contain a lot of dylibs.
> Does that mean that each of these dylibs I have to codesign with a
> separate identity?Yes. And you usually accomplish that by giving each a different *identifier*.> Currently, I do this:
> 
>   codesign -f -s "Developer ID Application" *.dylibThat works, but results in plain identifiers (no dots).> Would it be safe to change it to:
> 
>   codesign -f -s "Developer ID Application" --prefix com.myname. *.dylibIt would be safe (assuming that's *your* company name :-), and it would suggest it.

Before everyone panics, here's the fundamental point: Every piece of code shipped or used by anyone on any Mac anywhere should have a distinct, unique code identity. (I'm talking about different libraries, of course - different *versions* of the same library have, and should have, the same code identity.) As you've probably all figured out by now, the basic logic of a code signing identity is, from 30000 feet, "signed by this guy and he says the identifier is that." In other words, the *combination* of signing identity and identifier needs to be unique.

Assuming you sign all your stuff with the same signing identity, you are responsible for uniqueness of identifiers across all *your* stuff. That's why we pick bundle identifiers as the default identifier whenever possible (because other stuff will already break if you reuse those on multiple programs of yours :-). The --prefix argument makes it easy to extend the naming conventions to non-bundle code. You're *encouraged* but not *required* to use it; your responsibility is to ensure uniqueness, and if you prefer to do that differently, that's okay.

Incidentally, now would be a splendid time to decide on the signing identifiers used on all your libraries, plug-ins, and frameworks. Changing the identifier on shipping code changes the code identity of the code. This does not currently matter on libraries and plug-ins. Yet.

Cheers
  -- perry
---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.---------------------------------------------------------------------------
Chris Suter 1343264063Thu, 26 Jul 2012 00:54:23 +0000 (UTC)
Hi Perry,On Thu, Jul 26, 2012 at 9:39 AM, Perry The Cynic  wrote:

Before everyone panics, here's the fundamental point: Every piece of code
> shipped or used by anyone on any Mac anywhere should have a distinct,
> unique code identity. (I'm talking about different libraries, of course -
> different *versions* of the same library have, and should have, the same
> code identity.) As you've probably all figured out by now, the basic logic
> of a code signing identity is, from 30000 feet, "signed by this guy and he
> says the identifier is that." In other words, the *combination* of signing
> identity and identifier needs to be unique.
>In that case, there ought to be some kind of support for shared identities
(if there isn't already) when it comes to things like the Keychain. For
example, let's say you a have demonstration or lite version of an
application where the user might access something in the Keychain. Should
they upgrade to the full version or pro version, you don't want them to be
prompted for permission to access the same Keychain item again.

Kind regards,

Chris
Perry The Cynic 1343265761Thu, 26 Jul 2012 01:22:41 +0000 (UTC)
On Jul 25, 2012, at 5:52 PM, Chris Suter wrote:

> Hi Perry,
> 
> On Thu, Jul 26, 2012 at 9:39 AM, Perry The Cynic  wrote:
> 
> Before everyone panics, here's the fundamental point: Every piece of code shipped or used by anyone on any Mac anywhere should have a distinct, unique code identity. (I'm talking about different libraries, of course - different *versions* of the same library have, and should have, the same code identity.) As you've probably all figured out by now, the basic logic of a code signing identity is, from 30000 feet, "signed by this guy and he says the identifier is that." In other words, the *combination* of signing identity and identifier needs to be unique.
> 
> In that case, there ought to be some kind of support for shared identities (if there isn't already) when it comes to things like the Keychain. For example, let's say you a have demonstration or lite version of an application where the user might access something in the Keychain. Should they upgrade to the full version or pro version, you don't want them to be prompted for permission to access the same Keychain item again.Of course there is. It's called "Keychain ACLs," where you may specify any number of code identities that should have access to the item you're creating.

Cheers
  -- perry---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
Thomas Tempelmann 1343293929Thu, 26 Jul 2012 09:12:09 +0000 (UTC)
Perry,>> Would it be safe to change it to:
>>   codesign -f -s "Developer ID Application" --prefix com.myname. *.dylib
>
> It would be safe (assuming that's *your* company name :-), and it would suggest it.Okay, that brings me to another formality: These dylibs are not part
of my own written code but of someone who provided these libs to me.
Ideally, they should be signed by him then, shouldn't they?

Now, he sure can't hand me his certificates, or I could do "bad
things", right? Which means he has to deliver them already signed to
me. Which may currently not be possible with Real Studio, I'm afraid,
because RS recreates these files from a container, whereby the signing
_might_ be lost.

In the long run, if I sign 3rd party pre-built libs with my own
certificate, and other programs use the very same libs in their app
bundles, with a different signature (their own), that should never be
a problem, should it? I mean, OSX won't try to match these dylibs in
their separate places and then complain about mismatched signatures,
right?-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Thomas Tempelmann 1343295228Thu, 26 Jul 2012 09:33:48 +0000 (UTC)
Uh, one more thing:

The DR (Dev Request?) keep getting mentioned. There was a thread a
while ago which mentioned and tried to explain it but I never really
understood what it's for. So far, my code signing went well (or
appeared so) without bothering with DR.

So, could someone please tell me if I _need_ to deal with DRs
explicitly? Do I need to take extra steps when signing my app with its
frameworks and dylibs in a bundle? If I don't need to, _when_ does on
need to bother with them?-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Jerry Krinock 1343322154Thu, 26 Jul 2012 17:02:34 +0000 (UTC)
On 2012 Jul 26, at 02:33, Thomas Tempelmann  wrote:

> The DR (Dev Request?) keep getting mentioned.DR = designated requirement.  More explicitly, it is the 'designated' section of the 'requirements' in the code signature.

> So, could someone please tell me if I _need_ to deal with DRs explicitly?

Supposedly not if you are using Xcode 4 to build and sign, because Xcode never makes a mistake :)  But if you are using the codesign tool "manually" then you need to deal with them.

> Do I need to take extra steps when signing my app with its frameworks and dylibs in a bundle?

Ditto.

You've got some reading to do.
Thomas Tempelmann 1343296667Thu, 26 Jul 2012 09:57:47 +0000 (UTC)
On Thu, Jul 26, 2012 at 11:10 AM, Thomas Tempelmann
 wrote:
> Perry,
>
> Okay, that brings me to another formality: These dylibs are not part
> of my own written code but of someone who provided these libs to me.
> Ideally, they should be signed by him then, shouldn't they?Which is a problem in itself with the App Store, I just learned: When
submitting to the App Store, apps supposedly get rejected if not all
included parts are signed by the submitter. Which makes sense, because
Apple wants to put all the responsibility on the submitter.

I wonder why isn't it possible that a lib contains _two_ signatures -
the one by the maker and the one by the submitter? Wouldn't that be a
good solution to keep both MAS happy and retain the origins of the
code?-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Perry The Cynic 1343325909Thu, 26 Jul 2012 18:05:09 +0000 (UTC)
On Jul 26, 2012, at 2:10 AM, Thomas Tempelmann wrote:

> Perry,
> 
>>> Would it be safe to change it to:
>>>  codesign -f -s "Developer ID Application" --prefix com.myname. *.dylib
>> 
>> It would be safe (assuming that's *your* company name :-), and it would suggest it.
> 
> Okay, that brings me to another formality: These dylibs are not part
> of my own written code but of someone who provided these libs to me.
> Ideally, they should be signed by him then, shouldn't they?The cardinal rule is that whoever makes the binary should sign it. If that someone shipped you binary dylibs, they should come with their signature. If they ship you source, you sign them.> Now, he sure can't hand me his certificates, or I could do "bad
> things", right? Which means he has to deliver them already signed to
> me. Which may currently not be possible with Real Studio, I'm afraid,
> because RS recreates these files from a container, whereby the signing
> _might_ be lost.I don't know what that means. Generally, any attempt to create Franken-code by assembling bits of pieces into a new whole are a bad idea these days. If you have to take your bone saw and scissors and assemble new code from old, you'll have to resign the result to give it a meaningful identity. At which point that's *your* identity, because you did the surgery, and we can't really blame the guy who made the pieces for the (possible) mess you made of it, can we?> In the long run, if I sign 3rd party pre-built libs with my own
> certificate, and other programs use the very same libs in their app
> bundles, with a different signature (their own), that should never be
> a problem, should it? I mean, OSX won't try to match these dylibs in
> their separate places and then complain about mismatched signatures,
> right?If you and some other developer sign the same (binary image) dylib with your respective signing identities, you will create distinct code identities for them. This means those two dylibs will not substitute for each other even if they're physically the same. If that doesn't bother you (or them, or the maker of the dylib), then there's no problem.

In a fairly fundamental sense, those signing arrangements should track your business arrangements. If your library vendors thinks they sell you finished product, then they should sign it. If they send you bits and pieces you assemble into a working part, then you should.

Cheers
  -- perry
---------------------------------------------------------------------------
Perry The Cynic                                             
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.---------------------------------------------------------------------------
Thomas Tempelmann 1343406710Fri, 27 Jul 2012 16:31:50 +0000 (UTC)
On Thu, Jul 26, 2012 at 7:57 PM, Perry The Cynic  wrote:
> On Jul 26, 2012, at 2:10 AM, Thomas Tempelmann wrote:
>> Now, he sure can't hand me his certificates, or I could do "bad
>> things", right? Which means he has to deliver them already signed to
>> me. Which may currently not be possible with Real Studio, I'm afraid,
>> because RS recreates these files from a container, whereby the signing
>> _might_ be lost.
>
> I don't know what that means. Generally, any attempt to create Franken-code by assembling bits of pieces into a new whole are a bad idea these days.Clarification: I was wrong. Real Studion does not mess with the
plugins and at least one Plugin vendor (MBS) is already signing his
plugins and they end up signed in my built app.-- 
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Jerry Krinock 1343327735Thu, 26 Jul 2012 18:35:35 +0000 (UTC)
On 2012 Jul 25, at 11:16, Perry The Cynic  wrote:

> On Jul 25, 2012, at 7:49 AM, Jerry Krinock wrote:
> 
>> Note that this means that *all* 15 signable code objects in my app's package, including binaries, frameworks, a helper app bundle, and an NPAPI plugin bundle, are all signed with the same identifier, the bundle identifier of the main app.

> Do NOT do this. It is WRONG.
> 
> If you believe that the current documentation is kind of vague about this, please file a radar - it is meant to be crystal clear about itActually the documentation is clear about that, and this is the way my script did it until two days ago.  But because DTS waited until the last day to get Developer Certificate Utility working for me, I decided to follow exactly the inscrutable procedure others had succeeded with, which did not take account of my 15 signable code objects.  In other words, I needed to get something out the door quick, and when it worked, I shipped.

To verify that Xcode is using unique identifiers as you say, I did a further experiment.  I created a more complicated Dummy app, this one containing a DummyHelperApp and a command-line DummyHelperTool.  Upon building it in Xcode 4, I find that, as now expected, in the Build Transcript, the designated requirement (DR) in each of the 3 codesign invocations specifies a different identifier…

… identifier \"DumbHelperTool\" …
…
… identifier \"com.sheepsystems.DumbHelperApp\" …
…
… identifier \"com.sheepsystems.Dummy\" …

But I note that in none of those three cases did Xcode prefix the company ID.  For the command-line tool, it uses the name of the tool, and for the helper app and the main app, their bundle identifiers, which have the company ID already prefixed.  Indeed, I think there is no need to prefix the company ID, because that is implied by the signing identity, and it is the (identity, identifier) pair which must be unique.

Regarding the --prefix "convenience".  I paste in here the documentation on that, straight from man codesign.  Take a deep breath…

"--prefix string.  If no explicit unique identifier is specified (using the -i option), and if the implicitly generated identifier does not contain any dot (.) characters, then the given string is prefixed to the identifier before use. If the implicit identifier contains a dot, it is used as-is. Typically, this is used to deal with command tools without Info.plists, whose default identifier is simply the command's filename; the conventional prefix used is com.domain. (note that the final dot needs to be explicit)." 

Whew!  As Hollywood script writers sometimes say about real life, "You can't make this stuff up!"  :))

After reading that, I decided to *not* use the --prefix.  Seriously, it would be fine as long as I didn't care what the identifier was.  But since the identifier needs to match exactly the 'identifier' passed into the DR, I pass them both as the same script variable, i.e., $identifier.  Then they're guaranteed to be the same.

> Yes, this means your hand-knitted DRs must be distinct for each piece of code. We may make this more convenient down the road, but that's the state of play today.

No problem.  Since I was rushed, I'd left the @identifiers array in my Perl script that traverses the bundle.  I just patched it back in.  From my new script stdout…

List of code signing identifiers used...
   com.sheepsystems.BookMacster
   AuthorizedTaskHelperToolInstaller
   AuthorizedTaskHelperTool_Typicapp
   BookMacster-Quatch
   BookMacster-Thomas
   BookMacster-Worker
   FileAliasWorker
   com.sheepsystems.BookMacster-UrlHandler
   Bkmxwork.framework
   Breadcrumb.framework
   RBSplitView(Leo).framework
   SSYAuthorizedTaskmaster.framework
   SSYLocalize.framework
   Sparkle.framework
   SheepSystemsNPAPIPlugin.plugin

So I just emailed the new app to myself on Mountain Lion, and it is "accepted" by spctl and Gatekeeper allows it to launch.  I think I'm done.

Perry, I started out this thread as a Blind Optimist, sank to the depths of Pessimistic Realist, but have been so encouraged by your tireless efforts toward making the codesign world a better place, I feel I'm heading toward Optimistic Realist.  Thank you very much.

Jerry
jonathan1339771231Fri, 15 Jun 2012 14:40:31 +0000 (UTC)
On 15 Jun 2012, at 13:55, Thomas Tempelmann wrote:

> 
> Your command for signing for GateKeeper would then look like this:
> 
> codesign -f -s "Developer ID Application" "Appname.app"
>Building with the developer ID certificate installed may fail with CSSMERR_TP_NOT_TRUSTED.
In this case down load and install the Developer ID Intermediate Certficate from https://developer.apple.com/certificationauth....

Regards

Jonathan Mitchell
Mugginsoft LLP
Rustam Muginov 1339774978Fri, 15 Jun 2012 15:42:58 +0000 (UTC)
How i solved this out:

1) Created sining identities with Apple developer portal (not Xcode 4) under my 10.6.8 system
2) Exported private keys and transferred them to the 10.7 system where Xcode 4.3 is installed
3) Build sample app with Developer ID signing, copied the "build transcript" of codesign phase.
4) Called codesign with similar command line under 10.6.8/Xcode 3.2.5

--
Sincerely,
Rustam MuginovOn Jun 15, 2012, at 5:34 AM, Jerry Krinock wrote:

> I have an app built with Xcode 3, which is signed in my shipping script, using the 'code sign' command-line tool to sign all executable components, as explained in the Code Signing Guide.  I have been using a self-signed certificate.  The app is distributed in a .zip or .dmg and does not have an installer.
> 
> Now, of course, I want my app to pass Gatekeeper by default.  I think that all I need to do is (1) get the appropriate certificate(s) into my Keychain using Xcode 4, and (2) change my script to use one of them.  Is it that simple, I hope?
> 
> So I ran Xcode 4, followed the instructions in the Tools Workflow Guide for Mac.  Things did not work quite as outlined in the Guide, possibly because I did it first a few days ago with Xcode 4.2.  But anyhow I now have three candidate certificates in my Mac OS X Keychain:
> 
> [1]  3rd Party Mac Developer Installer: Jerry Krincok    expires 2013 Jun 12
> [2]  3rd Party Mac Developer Application: Jerry Krinock  expires 2012 Sep 13
> [3]  Mac Developer: Jerry Krinock (XXXXXXXXXX)           expires 2013 Jun 12
> 
> Which one should I use?
> 
> [1] appears to be for an Installer, so that's not the one I want.
> [2] looks like what I want, "Developer Application", however from the expiration date it appears to be something that I generated in September 2011, when I was toying around with a Mac App Store App that I never shipped.
> [3] is maybe the one that I should use.  Is that correct?
> 
> Thanks,
> 
> Jerry Krinock
> 
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Apple-cdsa mailing list      
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/apple...
> 
> This email sent to --
Sincerely,
Rustam Muginov

On Jun 15, 2012, at 5:34 AM, Jerry Krinock wrote:

> I have an app built with Xcode 3, which is signed in my shipping script, using the 'code sign' command-line tool to sign all executable components, as explained in the Code Signing Guide.  I have been using a self-signed certificate.  The app is distributed in a .zip or .dmg and does not have an installer.
> 
> Now, of course, I want my app to pass Gatekeeper by default.  I think that all I need to do is (1) get the appropriate certificate(s) into my Keychain using Xcode 4, and (2) change my script to use one of them.  Is it that simple, I hope?
> 
> So I ran Xcode 4, followed the instructions in the Tools Workflow Guide for Mac.  Things did not work quite as outlined in the Guide, possibly because I did it first a few days ago with Xcode 4.2.  But anyhow I now have three candidate certificates in my Mac OS X Keychain:
> 
> [1]  3rd Party Mac Developer Installer: Jerry Krincok    expires 2013 Jun 12
> [2]  3rd Party Mac Developer Application: Jerry Krinock  expires 2012 Sep 13
> [3]  Mac Developer: Jerry Krinock (XXXXXXXXXX)           expires 2013 Jun 12
> 
> Which one should I use?
> 
> [1] appears to be for an Installer, so that's not the one I want.
> [2] looks like what I want, "Developer Application", however from the expiration date it appears to be something that I generated in September 2011, when I was toying around with a Mac App Store App that I never shipped.
> [3] is maybe the one that I should use.  Is that correct?
> 
> Thanks,
> 
> Jerry Krinock
> 
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Apple-cdsa mailing list      
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/apple...
> 
> This email sent to 
Ad
Home | About | Privacy