3

If you start any Python process on OS X 10.11 (10.11.0 or 10.11.1) El Capitan, and run the OS built-in tool 'codesign' to verify the process, you will receive an error saying "code object is not signed at all".

Here's an example:

  1. Open Terminal.app. Type "python". This will start a normal Python REPL console.
  2. Open another terminal window. Run "ps | grep python" to find the process id of the Python REPL process. Let's say it's 555.
  3. Run command "codesign -v 555". codesign will report "555: code object is not signed at all"

However, if you run the following commands, it seems the python executable is properly signed:

$ which python
/usr/bin/python

$ codesign -dvv `which python`
Executable=/usr/bin/python
Identifier=com.apple.pythonw
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=226 flags=0x0(none) hashes=6+2 location=embedded
Signature size=4105
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=68

If you use codesign to verify any Perl or Ruby process, they are all fine. Also, in Yosemite, every Python process can be correctly verified by codesign.

What happened?

  • Dunno. Same here on my El-Capitan. Apple stock python has this behaviour. But the python from homebrew checks out fine. – StackzOfZtuff Oct 26 '15 at 19:20
1

The executable located at /usr/bin/python does little more than spawn the application /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app. That application bundle doesn't have its own signature, but presumably it piggybacks on the signature of the parent binary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.