Highlighted

Adobe Air iOS Apps signed with "a relatively old structure"

Explorer ,
Apr 19, 2017

Copy link to clipboard

Copied

Citrix wrote on its blog that it is not possible to use their technology with Adobe Air for iOS because "It is signed with a relatively old structure and does not leave any space to store an updated signature structure.". See XenMobile MDX Service Deep Dive | Citrix Blogs

Will Adobe work on this?

Looking forward for some response.

Kind regards

Chris

TOPICS
Development

Views

275

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Adobe Air iOS Apps signed with "a relatively old structure"

Explorer ,
Apr 19, 2017

Copy link to clipboard

Copied

Citrix wrote on its blog that it is not possible to use their technology with Adobe Air for iOS because "It is signed with a relatively old structure and does not leave any space to store an updated signature structure.". See XenMobile MDX Service Deep Dive | Citrix Blogs

Will Adobe work on this?

Looking forward for some response.

Kind regards

Chris

TOPICS
Development

Views

276

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Apr 19, 2017 0
Enthusiast ,
Apr 19, 2017

Copy link to clipboard

Copied

so let's quote them

We also cannot sign an app that does not have enough space to store the newly signed structure. Adobe AIR iOS app is an example of this. It is signed with a relatively old structure and does not leave any space to store an updated signature structure. Unfortunately, at this moment, we need to fail the wrap process for these apps.

it's kind of vague ... imho either they got it wrong or did not try hard enough

under macOS (but also otherOS) wether you sign desktop app or mobile app

you have all the tools within Adobe AIR toolchain (ADT) to sign, resign, migrate signatures, etc.

see Signing AIR applications


the doc is pretty extensive and the ADT tool reuse what is on the system: keychain, java keystores, etc.

what people could call "industry standards"

"old structure" may refer to something like that: Technical Q&A QA1940

eg.

... a security hardening change that was introduced with iOS 10, macOS Sierra, watchOS 3, and tvOS 10.

Code signing no longer allows any file in an app bundle to have an extended attribute containing a resource fork or Finder info

so yeah if you use codesign to sign a desktop AIR app, you will get the error

"resource fork, Finder information, or similar detritus not allowed."

because when ADT sign the AIR app it add some ressources into the Mach-O
eg.

$ xattr -lr bin-deploy/foobar.app

you can see

bin-deploy/foobar.app/Contents/Info.plist: com.apple.FinderInfo:

00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

bin-deploy/foobar.app/Contents/Info.plist: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A

bin-deploy/foobar.app/Contents/MacOS: com.apple.FinderInfo:

00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

bin-deploy/foobar.app/Contents/MacOS: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A

bin-deploy/foobar.app/Contents/PkgInfo: com.apple.FinderInfo:

00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

bin-deploy/foobar.app/Contents/PkgInfo: com.apple.quarantine: 0081;55dd2ab1;Google\x20Chrome.app;8414EC98-9FF9-463F-ACD5-305B18828E7A

bin-deploy/foobar.app/Contents: com.apple.FinderInfo:

00000000  00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00  |................|

00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

00000020

in short, it create what is called a resource fork and new rules in macOS now quarantine those
(see: macOS Code Signing In Depth "Moving Away From Custom Resource Rules")

but nothing that can not be updated with a

$ xattr -cr bin-deploy/foobar.app

which fix the problem.

Now specifically for iOS, Adobe AIR apps are cross-compiled to native binaries

(almost the same as if you would compile Obj-C code)
so I really don't see what kind of problems Citrix encountered there

the part "does not leave any space to store an updated signature structure" is kind of false
you can take an IPA generated by ADT, "unzip" it and change "things" (eg. update/change certificates) like any other IPA

Really, among all the targets Adobe AIR can publish to, the iOS one is the exception that is like native

my guess is that Citrix overlooked something, better ask them the details about their vague comments.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Apr 19, 2017 0