Thread: [Pyobjc-dev] py2app builds fail leopard codesign integrity checks
Brought to you by:
ronaldoussoren
Menu
▾
▴
pyobjc-dev
|
From: James R E. <ea...@ba...> - 2007-11-18 21:10:55
Attachments:
smime.p7s
|
Hi folks,
It appears that PyObjC applications built with py2app on Leopard fail
the codesign integrity checks. I have an application that uses a
simple ObjC wrapper around the SecKeychain{Add,Find}GenericPassword
methods. When I build and run the application from an XCode project,
the application runs fine, adding and finding passwords on the
keychain. When I build and run the same project using py2app, Leopard
gripes when reading from the Keychain:
"KeychainError - code or signature modified"
At first I thought it might be the stripping phase, since I see the
following warning when building, but the keychain error arises even if
I pass --no-strip to py2app. In my case, it's easy enough to work-
around by using XCode, but is this a known bug in py2app or something
I might be doing wrong. (If it's the latter, I'd be happy to provide
a small demonstration app, if necessary.)
Thanks!
James
% python setup.py py2app
[...]
/usr/bin/strip: changes being made to the file will invalidate the
code signature in: /Users/eaganj/Projects/PyLogin Authenticator/dist/
Login Authenticator.app/Contents/MacOS/LoginAuthenticator (for
architecture ppc7400)
/usr/bin/strip: changes being made to the file will invalidate the
code signature in: /Users/eaganj/Projects/PyLogin Authenticator/dist/
Login Authenticator.app/Contents/MacOS/LoginAuthenticator (for
architecture i386)
/usr/bin/strip: changes being made to the file will invalidate the
code signature in: /Users/eaganj/Projects/PyLogin Authenticator/dist/
Login Authenticator.app/Contents/MacOS/python (for architecture ppc7400)
/usr/bin/strip: changes being made to the file will invalidate the
code signature in: /Users/eaganj/Projects/PyLogin Authenticator/dist/
Login Authenticator.app/Contents/MacOS/python (for architecture i386)
/usr/bin/strip: for architecture ppc64 object: /Users/eaganj/Projects/
PyLogin Authenticator/dist/Login Authenticator.app/Contents/Frameworks/
Python.framework/Versions/2.5/Python malformed object (load command 3
cmdsize not a multiple of 8)
stripping saved 13880 bytes (16642820 / 16656700)
---------
setup.py:
---------
from distutils.core import setup
import py2app
from plistlib import Plist
SHORT_VERSION = '1.0'
BUNDLE_VERSION = '12'
plist = Plist.fromFile('Info-py2app.plist')
plist.update(dict(
CFBundleShortVersionString=SHORT_VERSION,
CFBundleVersion=BUNDLE_VERSION,
))
py2app_options = dict(
# iconfile='Login Authenticator.icns',
plist=plist,
frameworks=['KeychainServices.framework'],
)
setup(
app=['main.py'],
data_files=['MainMenu.nib'],
options=dict(
py2app=py2app_options
)
)
--
There are more of them than us. -- Herb Caen
|
|
From: Bill B. <bb...@ma...> - 2007-11-19 01:22:10
|
On Nov 18, 2007, at 1:10 PM, James R Eagan wrote:
> It appears that PyObjC applications built with py2app on Leopard
> fail the codesign integrity checks. I have an application that uses
> a simple ObjC wrapper around the
> SecKeychain{Add,Find}GenericPassword methods. When I build and run
> the application from an XCode project, the application runs fine,
> adding and finding passwords on the keychain. When I build and run
> the same project using py2app, Leopard gripes when reading from the
> Keychain:
>
> "KeychainError - code or signature modified"
>
> At first I thought it might be the stripping phase, since I see the
> following warning when building, but the keychain error arises even
> if I pass --no-strip to py2app. In my case, it's easy enough to
> work-around by using XCode, but is this a known bug in py2app or
> something I might be doing wrong. (If it's the latter, I'd be happy
> to provide a small demonstration app, if necessary.)
Might it be that py2app is copying, then stripping, the
keychain.framework?
b.bum
|
|
From: James R E. <ea...@ba...> - 2007-11-19 19:39:44
Attachments:
smime.p7s
|
On Nov 18, 2007, at 20:22 , Bill Bumgarner wrote:
> Might it be that py2app is copying, then stripping, the
> keychain.framework?
The Keychain framework is a symptom, not the cause. Upon further
digging, it appears that all py2app applications built under Leopard
have extraneous code signatures, regardless of whether they include a
framework or not. Using another example that does not use any
external frameworks, when I run codesign on it to check its validity,
it again claims to be modified:
% codesign -dvvv CocoaRegexMaker.app
CocoaRegexMaker.app: code or signature modified
When I check the integrity of my application built by Xcode, I get a
different result:
% codesign -dvvv Login\ Authenticator.app
Login Authenticator.app: code object is not signed
(and, for completeness, when checking Login\ Authenticator.app as
built by py2app):
% codesign -dvvv Login\ Authenticator.app
Login Authenticator.app: code or signature modified
It appears that Xcode is never signing the code (which makes sense --
I've never specified my certificate anywhere). Something that py2app
does, however, appears to make Leopard think the resulting application
has been signed. I'm not deeply familiar enough with Leopard's
codesigning, however, to be able to tell where this extraneous
signature is coming from. (I'm assuming that py2app is not implicitly
signing the code somewhere with a hidden certificate, since that would
be pretty whack.)
--------
setup.py (from CocoaRegexMaker)
--------
from distutils.core import setup
import py2app
setup(
app=['CocoaRegexMaker.py'],
data_files=['MainMenu.nib'],
)
--
That's the trouble with computers -- always thinking in black and white.
No aquamarines, no blues, no imagination.
-- The (Fourth) Doctor
|
|
From: Ronald O. <ron...@ma...> - 2007-11-20 18:03:50
Attachments:
smime.p7s
|
On 19 Nov, 2007, at 20:14, James R Eagan wrote: > On Nov 18, 2007, at 20:22 , Bill Bumgarner wrote: > >> Might it be that py2app is copying, then stripping, the >> keychain.framework? > > > The Keychain framework is a symptom, not the cause. Upon further > digging, it appears that all py2app applications built under Leopard > have extraneous code signatures, regardless of whether they include > a framework or not. Using another example that does not use any > external frameworks, when I run codesign on it to check its > validity, it again claims to be modified: > > % codesign -dvvv CocoaRegexMaker.app > CocoaRegexMaker.app: code or signature modified > > When I check the integrity of my application built by Xcode, I get a > different result: > % codesign -dvvv Login\ Authenticator.app > Login Authenticator.app: code object is not signed > > (and, for completeness, when checking Login\ Authenticator.app as > built by py2app): > % codesign -dvvv Login\ Authenticator.app > Login Authenticator.app: code or signature modified > > > It appears that Xcode is never signing the code (which makes sense > -- I've never specified my certificate anywhere). Something that > py2app does, however, appears to make Leopard think the resulting > application has been signed. I'm not deeply familiar enough with > Leopard's codesigning, however, to be able to tell where this > extraneous signature is coming from. (I'm assuming that py2app is > not implicitly signing the code somewhere with a hidden certificate, > since that would be pretty whack.) Py2app isn't signing code. The problem is that the py2app executable stub inside the py2app package is signed by Apple (it isn't signed in the repository). I don't know how to remove that signature, but you can download the stub executable from pyobjc's repository (downloading from https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main might work for that) Ronald > > > -------- > setup.py (from CocoaRegexMaker) > -------- > > from distutils.core import setup > import py2app > > setup( > app=['CocoaRegexMaker.py'], > data_files=['MainMenu.nib'], > ) > > > -- > That's the trouble with computers -- always thinking in black and > white. > No aquamarines, no blues, no imagination. > -- The (Fourth) Doctor > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
|
From: James R E. <ea...@ba...> - 2007-11-20 18:12:02
Attachments:
smime.p7s
|
On Nov 20, 2007, at 13:03 , Ronald Oussoren wrote: > Py2app isn't signing code. The problem is that the py2app executable > stub inside the py2app package is signed by Apple (it isn't signed > in the repository). Thanks Ronald [and Bill], Amusingly enough, I had -just- tracked that down myself and was about to send a followup email to the list. Of course, as I was typing it up, *wildeep!* and there's your mail with the solution. You guys rock! Thanks! James -- One day if I do go to heaven... I'll look around and say, "It ain't bad, but it ain't San Francisco." -- Herb Caen |
|
From: Kevin W. <kw...@co...> - 2007-11-20 18:30:53
|
Ronald Oussoren wrote: > > > Py2app isn't signing code. The problem is that the py2app executable > stub inside the py2app package is signed by Apple (it isn't signed in > the repository). > > I don't know how to remove that signature, but you can download the stub > executable from pyobjc's repository (downloading from > https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main might > work for that) > I don't quite understand the problem here, but do these issues mean it's a Bad Idea to use the Apple-shipped py2app and PyObjC? I was planning on doing this when I upgraded to Leopard. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
|
From: Bill B. <bb...@ma...> - 2007-11-20 18:36:49
|
On Nov 20, 2007, at 10:30 AM, Kevin Walzer wrote: > I don't quite understand the problem here, but do these issues mean > it's a Bad Idea to use the Apple-shipped py2app and PyObjC? I was > planning on doing this when I upgraded to Leopard. Apple-shipped PyObjC is fine unless you need the post 2.0 bugfixes that Ronald has committed. If you are using the Xcode based project templates, this is all a non-issue as they do not use py2app (but you'll have to add a 'copy files' or 'shell script' build phase to add any python specific non-standard resources to your app's resources). It also sounds like the py2app executable stubs should *not* have been signed when Leopard was built. I'll have to look into that. b.bum |
|
From: Ronald O. <ron...@ma...> - 2007-11-20 18:59:05
Attachments:
smime.p7s
|
On 20 Nov, 2007, at 19:30, Kevin Walzer wrote: > Ronald Oussoren wrote: >> Py2app isn't signing code. The problem is that the py2app >> executable stub inside the py2app package is signed by Apple (it >> isn't signed in the repository). >> I don't know how to remove that signature, but you can download the >> stub executable from pyobjc's repository (downloading from https://svn.red-bean.com/pyobjc/branches/pyobjc2/py2app/py2app/apptemplate/prebuilt/main >> might work for that) > > I don't quite understand the problem here, but do these issues mean > it's a Bad Idea to use the Apple-shipped py2app and PyObjC? I was > planning on doing this when I upgraded to Leopard. Apple-shipped PyObjC and py2app are good enough. The issue with py2app is pretty small, and can be worked around by replacing two files in the py2app package. There are also a number of small bugs in the pyobjc-core package, but nothing major. I will provide update packages some time in the future, but I have no idea when that will be. Ronald > > > --Kevin > -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com |
|
From: Jack J. <Jac...@cw...> - 2007-11-21 21:40:21
|
On 20-Nov-2007, at 19:03 , Ronald Oussoren wrote: > Py2app isn't signing code. The problem is that the py2app > executable stub inside the py2app package is signed by Apple (it > isn't signed in the repository). Interesting. The first question that comes to mind is: Should Apple be signing those stubs in the first place? Do they sign other components that are going to be repackaged and redistributed by the end user (such as static libraries)? I'm tempted to say Apple should not sign the stub. And if Apple indeed signed the stub on purpose they should allow for the signature to be removed somehow, -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
|
From: Bill B. <bb...@ma...> - 2007-11-22 01:15:17
|
On Nov 21, 2007, at 1:41 PM, Jack Jansen wrote: > On 20-Nov-2007, at 19:03 , Ronald Oussoren wrote: >> Py2app isn't signing code. The problem is that the py2app >> executable stub inside the py2app package is signed by Apple (it >> isn't signed in the repository). > Interesting. The first question that comes to mind is: Should Apple > be signing those stubs in the first place? Do they sign other > components that are going to be repackaged and redistributed by the > end user (such as static libraries)? I'm tempted to say Apple should > not sign the stub. It was a default that fell through the cracks; the stubs were not added to an exception list *not* to be signed during the mastering process. Bug filed. b.bum |
|
From: Ben A. <be...@ar...> - 2007-11-21 22:13:44
|
> And if Apple indeed signed the stub on purpose they should allow for > the signature to be removed somehow, Well, it can be removed by resigning the bundle with your own secure identity, which you should do anyway. -- <http://artins.org/ben> "It takes a great deal of bravery to stand up to our enemies, but just as much to stand up to our friends" -- Albus Dumbledore |
|
From: James R E. <ea...@ba...> - 2007-11-21 23:39:12
Attachments:
smime.p7s
|
On Nov 21, 2007, at 14:13 , Ben Artin wrote: >> And if Apple indeed signed the stub on purpose they should allow for >> the signature to be removed somehow, > > Well, it can be removed by resigning the bundle with your own secure > identity, which you should do anyway. Thanks, Ben. You are exactly correct, and this is exactly what I was trying to do. The catch is that the normal codesigning procedure will gripe that the code is already signed, so you'll have to force it with the -f option (e.g. codesign -fs <myidentity> <my.app>). James -- Against stupidity the very Gods themselves contend in vain. |
|
From: Ronald O. <ron...@ma...> - 2007-11-22 07:28:51
Attachments:
smime.p7s
|
On 21 Nov, 2007, at 22:41, Jack Jansen wrote: > > On 20-Nov-2007, at 19:03 , Ronald Oussoren wrote: >> Py2app isn't signing code. The problem is that the py2app >> executable stub inside the py2app package is signed by Apple (it >> isn't signed in the repository). > Interesting. The first question that comes to mind is: Should Apple > be signing those stubs in the first place? Do they sign other > components that are going to be repackaged and redistributed by the > end user (such as static libraries)? I'm tempted to say Apple should > not sign the stub. > > And if Apple indeed signed the stub on purpose they should allow for > the signature to be removed somehow, I agree. I've filed a bug for this as radar #5610558. Feel free to do the same to boost the priority of this issue. Ronald > > -- > Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack > If I can't dance I don't want to be part of your revolution -- Emma > Goldman > > |
|
From: Bill B. <bb...@ma...> - 2007-11-22 08:23:51
|
On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote: > I agree. I've filed a bug for this as radar #5610558. Feel free to > do the same to boost the priority of this issue. No need -- I filed the bug directly earlier today, including a description of the severity. I'll follow up with the appropriate folks on Monday. If you have specific notes about failure modes or severity that you want added to the discussion, send them to me directly and I'll add 'em to the bug. rdar://5610412 is the master bug, in this case, if anyone needs to ask ADC for current status. b.bum |
|
From: Nathan <nat...@gm...> - 2007-11-26 00:02:51
|
On Nov 22, 2007 1:23 AM, Bill Bumgarner <bb...@ma...> wrote: > On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote: > I agree. I've filed a bug for this as radar #5610558. Feel free to do the > same to boost the priority of this issue. > No need -- I filed the bug directly earlier today, including a description FYI, I've been _repeatedly_ told by Apple engineers that duplicate bugs are very helpful. In particular, each duplicate is counted as a vote for fixing the bug, and that's one of the primary ways they prioritize which bugs to work on. So if you really want your bug fixed, you should encourage _everyone_ to file a bug about it. ~ Nathan |
|
From: Bill B. <bb...@ma...> - 2007-11-26 01:14:07
|
On Nov 25, 2007, at 4:02 PM, Nathan wrote: > On Nov 22, 2007 1:23 AM, Bill Bumgarner <bb...@ma...> wrote: >> On Nov 21, 2007, at 11:28 PM, Ronald Oussoren wrote: >> I agree. I've filed a bug for this as radar #5610558. Feel free to >> do the >> same to boost the priority of this issue. >> No need -- I filed the bug directly earlier today, including a >> description > > FYI, I've been _repeatedly_ told by Apple engineers that duplicate > bugs are very helpful. In particular, each duplicate is counted as a > vote for fixing the bug, and that's one of the primary ways they > prioritize which bugs to work on. > > So if you really want your bug fixed, you should encourage _everyone_ > to file a bug about it. I completely agree. However, there is an exception. If an Apple engineer pipes up and says "no need for dupes", then it is because there really isn't a need for dupes -- the priority, etc, has already been set and isn't going to change. In most cases, this means that the bug is on the fast track to be fixed. b.bum |
Thanks for helping keep SourceForge clean.
X