Certificate in a separate keychain file

[Vachik]

Hi

I am on macOS and my signing certificate is in a separate keychain file.

I though if the external keychain shows up in Keychain Access app then the certificate is accessible to pyinstaller for use.

I build one file self extract option and the only way to sign the files in the archive/executable is to specify the certificate in pyinstaller command line arguments.

However this approach does not work because pyinstaller is not able to access the certificate in the external keychain.

Any advice? there is no option/argument for keychain file even though codesign have it!

[bwoodsend]

Do you know what flags codesign needs to sign with an external keychain?

[Vachik]

yes here is the command line we use to sign with external keychain

argument is --keychain

/usr/bin/codesign --timestamp --entitlements ./scripts/entitlements.plist --force --keychain /path/to/Keychain --sign 'Developer ID Application:' build/ar/libEpCommonPyWrapper.dylib

Are you going to add the option to specify keychain in pyinstaller?

Thank you I'd would greatly appreciate it!

it would be good if you follow Xcode signing flags approach. They do have the mandatory arguments like certificate name and additional specifiers which are grouped under the single argument.

 /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -project ./path/to/projectxcodeproj -scheme SCHEME_NAME -destination "generic/platform=macOS,name=Any Mac" -configuration Release "CODE_SIGN_IDENTITY=Developer ID Application: " "OTHER_CODE_SIGN_FLAGS=--keychain \"/PATH/TO/Keychain" --timestamp" CONFIGURATION_BUILD_DIR=./macosx/release.dynamic.64

As you can see there are 2 options in OTHER_CODE_SIGN_FLAGS ---keychain and --timestamp

We also sometimes use --force and other flags and this approach give the felixibility specifying different flags for different builds.

It can cover Windows signing options  and less coding for devs.

[bwoodsend]

You’re welcome to request it if it’s that important to you. It would most likely be a spec only list of arguments option to avoid expanding the already overgrown list of CLI options and the nested quotes unpacking. (To be honest, this is one of the main reasons we avoid adding integration with other tools – we then have to dream up ways of exposing every option that the tool has.)

That said, macOS and onefile mode hate each other (macOS does an expensive security scan on an application’s first run and onefile mode makes the application appear new every time it runs) so if I were you I’d go back to onedir then codesign the it yourself.

​

[Chris Barker]

On Fri, Dec 19, 2025 at 5:06 PM bwoodsend <bwoo...@gmail.com> wrote:

That said, macOS and onefile mode hate each other (macOS does an expensive security scan on an application’s first run and onefile mode makes the application appear new every time it runs) so if I were you I’d go back to onedir then codesign the it yourself.

Note on this -- the Mac ".app bundle" is the standard way to deliver apps anyway. On disk, it's a directory, but that's hidden from the user, so it looks like a single file app.

So there's no real reason to use onefile on the Mac anyway.

-CHB

 

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Vachik]

Thank you, I will file a request later I think for now ad-hoc signing is working for us. Thanks for looking into this.

We use.bundled apps for any new development. 

These one-file outputs are legacy code and there are many dependencies on them throughout the very large system. 

Eventually they will be replaced but now