Code Signing


Peter Hudson
 

All

I finally need to sign an app that has been running for some time. I’m looking at what docs I can find and two questions emerge.

1. Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2. I currently squirrel away the license file for each install in the Contents folder of the bundle.
The license file is a simple text file and is different for each install.
I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter


Alex Zavatone
 

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   





Alex Zavatone
 

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   






Peter Hudson
 

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   







Alex Zavatone
 



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle.
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
   








Peter Hudson
 

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    









Jack Brindle
 

The answer is no. After an app is notarized you may not make any changes to the app bundle without rendering the app useless. That means you cannot store copy anything inside the app bundle after it is notarized.

It is easiest to sign and notarize an app within Xcode. If you cannot do that (perhaps you build from a script), then you will be using the codesign tool on the components of the app (or the app itself) to do the signing. Notarizing actually can help you with this. The process generates a report when it finds any signing issues within the app. Apple has three notes on Notarization that are well worth printing out - they contain lots of good info. 

Hints for signing using the codesign tool: don’t use —deep. If you have any third party components, it will overwrite their signature with yours. Use hardened runtime. Without it, you won’t notarize. Be sure to add Apple’s timestamp. Basically, follow the suggestions for signing that are outlined in the Notarization documents.

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. Learning how to interpret the notarization report is key, especially if your app is complex with lots of libraries and embedded tools (which all must be signed). When you run into problems, just ask. Lots of good resources here who have been through it before.

Jack


On Feb 10, 2021, at 9:53 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    










Peter Hudson
 

Thanks Jack.



On 10 Feb 2021, at 22:53, Jack Brindle via groups.io <jackbrindle@...> wrote:

The answer is no. After an app is notarized you may not make any changes to the app bundle without rendering the app useless. That means you cannot store copy anything inside the app bundle after it is notarized.

It is easiest to sign and notarize an app within Xcode. If you cannot do that (perhaps you build from a script), then you will be using the codesign tool on the components of the app (or the app itself) to do the signing. Notarizing actually can help you with this. The process generates a report when it finds any signing issues within the app. Apple has three notes on Notarization that are well worth printing out - they contain lots of good info. 

Hints for signing using the codesign tool: don’t use —deep. If you have any third party components, it will overwrite their signature with yours. Use hardened runtime. Without it, you won’t notarize. Be sure to add Apple’s timestamp. Basically, follow the suggestions for signing that are outlined in the Notarization documents.

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. Learning how to interpret the notarization report is key, especially if your app is complex with lots of libraries and embedded tools (which all must be signed). When you run into problems, just ask. Lots of good resources here who have been through it before.

Jack


On Feb 10, 2021, at 9:53 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Sorry didn’t explain properly Alex.  It is a macOS app.

The license issue is about whether, for now, I can sign the application with the license file in /Contents in the bundle.
Or, as each license is different, I need to place it outside the bundle. 

I couldn’t determine, from the docs to hand, whether putting the license in the bundle would be a problem in the context of signing.

I’ll share what unfolds !

Atb

Peter

 

On 10 Feb 2021, at 17:21, Alex Zavatone via groups.io <zav@...> wrote:



On Feb 10, 2021, at 10:23 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

Alex

Book suggestion looks good - have got a copy on the way !

Have been looking at the keychain as a home for the license file as part of the reorg for signing.

I’m not sure I understand.  Your license for a purchaser and the code signing should be two different things.  If you grant a license to a purchaser, then simply storing the license value in the keychain should be all you need for that, but you still will need to sort out code signing separately.

You also mentioned notarizing.   The book existed before that process, but the concepts in chapter 4 are foundational to wrap your head around code signing.

It just occurred to me that since you’re notarizing your app you need to code sign a Mac app. not an iOS one.  It’s still really important to understand the guts behind code signing and the book will help.

Here is a brief on Mac app notarizing that may help. 


Note the details about Hardened Runtime.  Is that enabled in your app?

Good luck.  Please share what you find.  

Alex Zavatone

Many thanks

Peter





On 10 Feb 2021, at 16:02, Alex Zavatone via groups.io <zav@...> wrote:

FYI, you should be storing the license in a more secure location such as the keychain.



On Feb 10, 2021, at 9:55 AM, Alex Zavatone via groups.io <zav@...> wrote:

Chapter 4 of Essential Build and Release by Ron Roche is what got me what I needed to learn.


Cheers,
Alex Zavatone




On Feb 10, 2021, at 9:48 AM, Peter Hudson via groups.io <Peter.hudson@...> wrote:

All

I finally need to sign an app that has been running for some time.  I’m looking at what docs I can find and two questions emerge.

1.    Could anybody point me at the best instructions for code signing / notarisation - I have never done it before.
   I’ve looked at the docs in Xcode and they seem to raise more questions than they solve.

2.    I currently squirrel away the license file for each install in the Contents folder of the bundle. 
   The license file is a simple text file and is different for each install.
   I wondered if this is going to cause problems in the context of code signing ?


Many thanks

Peter
   
    











Sak Wathanasin
 



On 10 Feb 2021, at 22:53, Jack Brindle via groups.io <jackbrindle@...> wrote:

There seems to be a steep learning curve, but once you are successful you will ask yourself why it took so long to figure out. 

Well, one reason is that it seems to me that the whole notarization process is unnecessarily complicated. For example, when there is some issue, you get back an email with a UUID that you then have to use with xcrun altool to get the URL for the error page. Hells bells! Couldn't they have put the URL into the notification email?

And why does the "stapling" have to be a separate step? The Notarization servrice knows whether it's worked or not, and can staple it (or not). Surely Apple must be aware that people use Bamboo/Hudson/Jenkins/whatever for CI builds, not just XCode Server?

I, for one, resent the amount of time and energy I had to spend tweaking our build scripts. I'll put some Bach on now and calm down...

Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


Leo
 

I agree totally regarding the notarization.

It's a cumbersome, archaic, convoluted, ridiculous process unbecoming of Apple at all.

It was concocted by people who clearly didn't care about developers who'd have to implement it. 

The documentation was useless at best - and misleading at worst. It was written by people who just LOVE talking about notarization on and on and on in absurd lengths as it apparently turns them on. It wasn't written with a goal to clearly and concisely explain it to developers who are unfamiliar with the process.

It took absolutely enormous time to implement this bizarre process. Not to mention the extra time it now takes to post any new update.

What we had to get instead is a single command line tool that would do everything notarization is supposed to do, whatever it is, in one take - and return a clear result (success or otherwise). This tool would take care of polling the results on Apple's server and deal properly with zip, dmg, app and whatever else would be fed to it. Developers really shouldn't be intimately involved in every minutia of the notarization process. 

At least that's my take on it.


Cheers,
Leo


Shane Stanley
 

On 11 Feb 2021, at 9:53 am, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

If you have any third party components, it will overwrite their signature with yours.
Which is what you generally want. The code in the bundle should all be signed with the same identity.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Jon Gotow
 

Agreed - as I wait for 28 separate disk images to notarize (they're TTS Voice installers for a client).

Take a look at this tool for a all-in-one command line:

https://github.com/Mortennn/Notarize/releases/tag/1.0.0

So far it's worked pretty well for me. My only issue is that for the current project I'm doing, a full release involves 28 notarizations, and doing them serially with this tool takes an hour or two. So I'm back to having to roll my own scripts so that I can submit all of their installers at once.

- Jon

On Feb 11, 2021, at 8:56 PM, Leo <leo.r@rogers.com> wrote:

What we had to get instead is a single command line tool that would do everything notarization is supposed to do, whatever it is, in one take - and return a clear result (success or otherwise). This tool would take care of polling the results on Apple's server and deal properly with zip, dmg, app and whatever else would be fed to it. Developers really shouldn't be intimately involved in every minutia of the notarization process.


Jack Brindle
 

I would disagree. There are very specific circumstances where the embedded code must be signed by the original developer. Anything that is shared falls into this category. If you re-sign a shared third-party dext or sext you won’t get the behavior you want, and you will break other vendors applications. Another way to think of it - do you really want to be responsible for someone else’s code? In some cases you would be breaking the agreement you made to use that framework, bundle, tool, or other piece of code.

In general, if it comes signed, leave it that way and don’t overwrite it with another signature. You just might be breaking it. Worse, lawyers just might get involved...

Jack

On Feb 11, 2021, at 8:01 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Feb 2021, at 9:53 am, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

If you have any third party components, it will overwrite their signature with yours.
Which is what you generally want. The code in the bundle should all be signed with the same identity.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>






Shane Stanley
 

On 12 Feb 2021, at 3:07 pm, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

Another way to think of it - do you really want to be responsible for someone else’s code?
If I'm bundling it in my app, I already am.

--
Shane Stanley <sstanley@myriad-com.com.au>
<www.macosxautomation.com/applescript/apps/>, <latenightsw.com>


Leo
 

On Thu, Feb 11, 2021 at 08:06 PM, Jon Gotow wrote:
Take a look at this tool for a all-in-one command line:
Thanks, good to know someone made such a tool.

I do have my own utilities that automate the entire process as I release updates often (albeit not 28 in one day!)


Leo


Alex Zavatone
 

On Feb 11, 2021, at 10:06 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Agreed - as I wait for 28 separate disk images to notarize (they're TTS Voice installers for a client).

Take a look at this tool for a all-in-one command line:

https://github.com/Mortennn/Notarize/releases/tag/1.0.0

So far it's worked pretty well for me. My only issue is that for the current project I'm doing, a full release involves 28 notarizations, and doing them serially with this tool takes an hour or two. So I'm back to having to roll my own scripts so that I can submit all of their installers at once.

- Jon
Must they all happen serially, or can you parallelize this?


Jon Gotow
 

I can parallelize it - I just have to rewrite my scripts to do so and haven't gotten to it yet.

- Jon

On Feb 12, 2021, at 12:01 AM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:



On Feb 11, 2021, at 10:06 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Agreed - as I wait for 28 separate disk images to notarize (they're TTS Voice installers for a client).

Take a look at this tool for a all-in-one command line:

https://github.com/Mortennn/Notarize/releases/tag/1.0.0

So far it's worked pretty well for me. My only issue is that for the current project I'm doing, a full release involves 28 notarizations, and doing them serially with this tool takes an hour or two. So I'm back to having to roll my own scripts so that I can submit all of their installers at once.

- Jon
Must they all happen serially, or can you parallelize this?