ucf.jar gotchas

/usr/libexec/java_home -V

export JAVA_HOME=`/usr/libexec/java_home -v 1.7.0_80`

Lately I made some automated build setup for an Extension to one of the apps in the Adobe Creative Cloud, and I decided to use ucf.jar for signing (see https://www.adobeexchange.com/resources/7).

In the process, I bumped into some gotchas and interesting tidbits.

I suspect the info below could be old news to many people, or ‘duh’-level stuff that is spelled out in the documentation, but just in case it is not, it’s documented here.

I’ll document my findings here, in the hope they come in handy for someone struggling through a similar ordeal.

Funny side story: it’s already happened multiple times to me that I go out on a Google hunt to resolve some weird issue, and eventually bump into some info I wrote up somewhere, and then forgot about (in the most recent time it happened to me was on the Adobe forums – https://forums.adobe.com/thread/959112).

So, really, this article about ucf.jar is mostly about allowing Google to supplement my own memory. In a few years time I’ll no doubt will be struggling with ucf.jar and will end up on this page. Hi, Kris from the future!

.debug in ZXP, yes we can

First thingy: ucf.jar normally strips out .debug files. This was something I never checked or verified before now, but it looks like ucf.jar does The Right Thing, and strips out .debug

That is a good thing: you don’t want to deploy a ZXP that has a .debug file in it: it opens up a potential back door and some malicious person might try to break in via one of the open ports.

However, my extension was exhibiting different behavior after being packed up into a ZXP, so I really, really wanted to get a ZXP with a .debug file included.

After some poking I found it is possible to force the .debug file to come across by explicitly listing it on the command line.

Something akin to:

 java -jar ./signingtoolkit/ucf.jar  -package -storetype PKCS12 -keystore "$certfile" -storepass "$certpassword" -tsa http://timestamp.digicert.com com.rorohiko.harebrained.zxp -C ../build/dist/com.rorohiko.harebrained . -e ../build/dist/com.rorohiko.harebrained/.debug .debug

seems to do the trick ($certfile and $certpassword are bash environment variables). The trick is to explicitly add in the .debug file.

After that, Anastasiy’s Extension Manager (http://install.anastasiy.com/) happily installs the ZXP with the .debug file included.

Kill cfprefsd

My next head-scratcher came when I was mucking around on my Mac with PlayerDebugMode and LogLevel and the changes I made did not ‘take’.

Turns out there is some caching of preferences going on on Mac OS X, and you need to force the cache to be cleared.

The simplest method I found is to kill cfprefsd.

I now use a few simple double-clickable command-line bash scripts on my Mac to enable and disable the debug mode.

This is my ‘enable PlayerDebugMode’ script. Store it in a command-line script whose file name ends in ‘.command’ and it will be double-clickable from the Finder. Don’t forget to chmod +x !

defaults write com.adobe.CSXS.7.plist PlayerDebugMode 1
defaults write com.adobe.CSXS.7.plist LogLevel 5
killall -u `whoami` cfprefsd

And this is my ‘disable PlayerDebugMode’ script. Same deal.

defaults write com.adobe.CSXS.7.plist PlayerDebugMode 0
defaults write com.adobe.CSXS.7.plist LogLevel 0
killall -u `whoami` cfprefsd

PlayerDebugMode could be something else

The next thing that I figured out is that PlayerDebugMode seemed to only affect the signature verification of the ZXP, at least for the app I was working with.

My incorrect assumption was that PlayerDebugMode would also be turning on or off the debug mode.

That seems not to be the case: as far as I could tell I could leave PlayerDebugMode set to 0, and was still be able to debug the (signed and installed) ZXP, as long as it contains a .debug file.

I have not checked whether this is true for all Creative Cloud applications, but it sure was for the one I was working with.

ucf.jar don’t like no spaces

At some point in time, my fresh ZXPs failed to install due to signature issues.

As it turns out, that was because one of the files in my ZXP had a file name with a space in it.

That throws ucf.jar. I suspect it accounts for the file in the signature, but fails to include the file into the ZXP.

Unlike ucf.jar, ZxpSignCmd does not seem to have this issue.

Once I changed that file name all was well again.

Hope this helps!