Asset validation failed (90035) Invalid Signature ...

[gaHowell]

Hello, I am having a failure loading an ipa upto to TestFlight. I get Asset validation failed (90035) Invalid Signature .... I have have narrowed the issue down to my ANE. If I use the ANE I built in Feb this year the ipa uploads fine, however, if I rebuild the ANE now using the exact same files then I get this failure. Examining the two ANE files the only difference I have found so far is that the Feb ANE signatures.xml indicates SHA1 whilst the current ANE build shows SHA256. I am currently using Air SDK 51.1.2 and the Feb ANE was built using SDK 50.x.x version. I have tried reverting back to 50.2.3 as well as 50.1.1 and building a new ANE with the older SDKs but I get the same failure.

Does anyone have any pointers as to where my issue might be?

[ajwfrost]

Hi

Just to clarify: the difference is just in the version of the AIR SDK that you had used to build the ANE? But each time, you're packaging the IPA with the same version of AIR SDK?

Are you using the same certificate or have you had to update it since February?

The signatures.xml file is something that should just be internal to AIR, as is the fact we updated the ADT codesigning (of .air and .ane files) to use SHA-256. So I would have hoped that this is a red herring, if I'm understanding you right in that both times you can create an IPA file successfully, but cannot successfully upload the IPA that's using the rebuilt ANE file.

Are you able to install the IPA file onto a phone at all, to see if there's any better error message that this might give? And/or if you unzip the IPA file and do a codesign -d -vvv Payload/appname.app command on the unzipped package, this might give some further ideas (and if your ANE included frameworks it may also be necessary to try codesign -d -vvv Payload/appname.app/Frameworks/name.framework etc).

thanks

[gaHowell]

Hi Andrew, In the scenario that works I build a release IPA in Intellij using the ANE that I built back in February and using the latest Air SDK 51.1.2. If I then use the exact same files as used to package the February ANE and package a new ANE using the ADT from the latest Air SDK 51.1.2 and then build a release IPA this one produces the failure when trying to upload to Testflight.

Yes my certificate expired so I am using a new certificate and provisioning profile to build the IPA. Also the time source I was using for the ADT ANE packing script (TSA) is no longer available so I have used both the Apple time source (-tsa http://timestamp.apple.com/ts01) and Digicert (-tsa http://timestamp.digicert.com).

Regards – am I able to install and run the IPA on a device directly - I am not aware of how you can side load a release IPA onto a device so I have nor tried that. But I am able to install and run a development version using the ANE that fails to upload to Testflight.

I had unzipped the failing IPA and ran codesign -d -vvv Payload/main.app it returned: Payload/main.app: satisfies its designated requirement.

I do not have any Frameworks.

I should probably have mentioned that I am using a Windows machine to develop and build the IPA and then use a Mac to upload to Testflight.

Gord

From: Andrew Frost @.> Sent: October 26, 2024 3:52 PM To: airsdk/Adobe-Runtime-Support @.> Cc: Gord Howell @.>; Author @.> Subject: Re: [airsdk/Adobe-Runtime-Support] Asset validation failed (90035) Invalid Signature ... (Issue #3542)

EXTERNAL: Do not click links or open attachments if you do not recognize the sender.

Hi

Just to clarify: the difference is just in the version of the AIR SDK that you had used to build the ANE? But each time, you're packaging the IPA with the same version of AIR SDK?

Are you using the same certificate or have you had to update it since February?

The signatures.xml file is something that should just be internal to AIR, as is the fact we updated the ADT codesigning (of .air and .ane files) to use SHA-256. So I would have hoped that this is a red herring, if I'm understanding you right in that both times you can create an IPA file successfully, but cannot successfully upload the IPA that's using the rebuilt ANE file.

Are you able to install the IPA file onto a phone at all, to see if there's any better error message that this might give? And/or if you unzip the IPA file and do a codesign -d -vvv Payload/appname.app command on the unzipped package, this might give some further ideas (and if your ANE included frameworks it may also be necessary to try codesign -d -vvv Payload/appname.app/Frameworks/name.framework etc).

thanks

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/airsdk/Adobe-Runtime-Support/issues/3542*issuecomment-2439747129__;Iw!!I_DbfM1H!B_ImaBnBKrFpzEPO6fUO-OwiI8k_aV-rUotHrMsX8Hpi0JphR3iYExd-VDxkJRjThPWrmOat4SyUU2hovax0ayCFjBCswQ$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AQOD2RHETOQDVH5BURXPXULZ5QFJTAVCNFSM6AAAAABQT74B4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZZG42DOMJSHE__;!!I_DbfM1H!B_ImaBnBKrFpzEPO6fUO-OwiI8k_aV-rUotHrMsX8Hpi0JphR3iYExd-VDxkJRjThPWrmOat4SyUU2hovax0ayDV1PzcAQ$. You are receiving this because you authored the thread.Message ID: @.***>

[ajwfrost]

Okay thanks - so this sounds like an odd one, maybe a code signing thing or potentially a linker issue. Is it possible for us to get hold of the files that you're using here so that we could dive into their structures to see what's happening and what the differences might be?

Upload link for this: https://transfer.harman.com/requests/4tQoAcKH7xhbbrzFTm3dSv

thanks

[ajwfrost]

Thanks for the files. The failing IPA had an additional file in the ANE, platform.xml, and the ANE extension descriptor had a different namespace (51.1) rather than the older 50.0. But the other thing it had is a ._.DS_Store file in the root of the app.

The platform.xml and namespace shouldn't cause any issues for Apple i.e. TestFlight/validation etc, but the ._.DS_Store I think could be a problem, because we are including that in the package and in the code signature. I think Apple may ignore those in the code signatures (oddly, it's not the normal name that crops up of .DS_Store .. not sure of the difference here)

Tellingly, the 'new' ANE also has that hidden file, so I think: a) can you try checking on your filesystem where you package the new ANE, check for hidden files and delete the ._.DS_Store file; then hopefully the repackaging would work b) we can also look to patch ADT so that it ignores those files when it packages up an ANE file (and an IPA file)

thanks

[gaHowell]

OMG – The .DS_Store file was the issue. The weird thing is I have looked back through my backups to 2023 and the .DS_Store file has always been in my ANE build folder. Thank you so much for your help Andrew – really I should have thought to delete this file.

Gord

From: Andrew Frost @.> Sent: October 28, 2024 5:14 AM To: airsdk/Adobe-Runtime-Support @.> Cc: Gord Howell @.>; Author @.> Subject: Re: [airsdk/Adobe-Runtime-Support] Asset validation failed (90035) Invalid Signature ... (Issue #3542)

EXTERNAL: Do not click links or open attachments if you do not recognize the sender.

Thanks for the files. The failing IPA had an additional file in the ANE, platform.xml, and the ANE extension descriptor had a different namespace (51.1) rather than the older 50.0. But the other thing it had is a ._.DS_Store file in the root of the app.

The platform.xml and namespace shouldn't cause any issues for Apple i.e. TestFlight/validation etc, but the ._.DS_Store I think could be a problem, because we are including that in the package and in the code signature. I think Apple may ignore those in the code signatures (oddly, it's not the normal name that crops up of .DS_Store .. not sure of the difference here)

Tellingly, the 'new' ANE also has that hidden file, so I think: a) can you try checking on your filesystem where you package the new ANE, check for hidden files and delete the ._.DS_Store file; then hopefully the repackaging would work b) we can also look to patch ADT so that it ignores those files when it packages up an ANE file (and an IPA file)

thanks

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/airsdk/Adobe-Runtime-Support/issues/3542*issuecomment-2441293385__;Iw!!I_DbfM1H!E0c_BYAdN-oKceMhodHhd_NOslxwZxT7ZTQg6a6BEjLZUcKZSp0Hc0AfayVyfkNzNvTt__ejAqtum3oP5mStScgsP988Hw$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AQOD2RDANNAZRFEJVWFQKALZ5YE7XAVCNFSM6AAAAABQT74B4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBRGI4TGMZYGU__;!!I_DbfM1H!E0c_BYAdN-oKceMhodHhd_NOslxwZxT7ZTQg6a6BEjLZUcKZSp0Hc0AfayVyfkNzNvTt__ejAqtum3oP5mStSchlvyUItg$. You are receiving this because you authored the thread.Message ID: @.***>

[ajwfrost]

The interesting thing we just found is that if you do this on a Mac - where these files originate - AIR just ignores the file completely, and it doesn't get packaged into the ANE in the first place. It's only when you have moved things over to Windows where it seems to cause a problem.

We're going to look for and remove this file when packaging up via ADT - you're very much not the first person to come across this!!

thanks