App Store rejection

[Ernesto Giannotta]

Hi, 
here's the signature info of libicucore.A.dylib

Mammooth:~ erne$ codesign -d -v /usr/lib/libicucore.A.dylib 
Executable=/usr/lib/libicucore.A.dylib
Identifier=libicucore.A
Format=Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=13061 flags=0x0(none) hashes=648+2 location=embedded
Signature size=4064
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=92

I have extracted the certificates with
Mammooth:~ erne$ codesign -d --extract-certificates /usr/lib/libicucore.A.dylib 

and it is signed with 3 certificates all pertaining to Apple

If we leave this signature MAS will reject the build so it has been suggested to just remove it, but I can't see how to do it.

Anyway just re-signing it seems to work fine, and the correct identifier to use for libs seems to be just the lib's name.
(anyway it worked also with my arbitrary "com.mycompany.myapp.mylib" strings)

Our problem is signing the libvkernel_fat_release.dylib

Now I'm not really sure, but my guess is this:
we have changed the path to libicucore.A.dylib inside the libvkernel_fat_release.dylib to look for the one we've copied inside the bundle, right? 
now this path is longer than the previous one pointing to /usr/lib/ of course and this eats up space in the lib's header…
now there's no room for the signature data and script complains:

> codesign_allocate: can't allocate code signature data for:
> /Developer/Cocoa/Builds/Release/Apimac
> Notepad.app/Contents/vcomponents/libvkernel_fat_release.dylib (for
> architecture i386) because larger updated load commands do not fit (the
> program must be relinked using a larger -headerpad value)

As message suggests the lib should be given a larger headerpad when built, i guess adding -headerpad_max_install_names option in the Other linker flags field in the build options pane of XCode.

I think this is a good option to use when building all vale libs since we're changing several paths in them in the postprocessing scripts.


What do you think?



On 28-gen-2012, at 08:46, Ruslan Zasukhin wrote:

> On 1/28/12 12:14 AM, "jda" <jda at his.com> wrote:
> 
>> 
>>> 
>>> I'm in contact with Apple DTS and I sent them the ICU library as
>>> well as my signed app. I'm working with them to see what the reason
>>> for the rejection is.
>>> 
>>> I'll keep you updated.
>> 
>> The good news is that my Valentina-based app was accepted by the Mac
>> App Store. But of course this was version 4.9. I'm still waiting to
>> hear about how to deal with the ICU library in the package (I think it
>> is already signed by Apple. I tried this in Terminal: codesign -v, and
>> it was accepted without comment, which I think means that the dylib is
>> signed and the signature is valid).
> 
> But should be way to see that signrature
>    com.apple.*
> 
> 
> To see paths of DYLIB we use for this
>  OTOOL -L library
> 
> 
> 
> -- 
> Best regards,
> 
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
> 
> Valentina - Joining Worlds of Information
> http://www.paradigmasoft.com
> 
> [I feel the need: the need for speed]
> 
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina