Creative Developer Tools (CRDT) is taking shape!
The ExtendScript version (CRDT_ES) is now quite functional and usable.
I’ve used one of my old ‘free’ ExtendScripts (SizeLabels) as a real-life test, and wrapped it up as a CRDT package, using a lot of the code-signing, encryption, licensing, trialware, installer… features of CRDT to make it into a ‘real’ project that could start generating some revenue.
A more in-depth developer perspective on how I used CRDT to repackage SizeLabels in this YouTube video:
CEP Extensions: Packaging/Code Signing/Encrypting in CRDT
The next subproject I’ll be tackling in CRDT are CEP extensions.
All the CRDT for ExtendScript features are already available in CEP extensions – so the monetization and other features offered by CRDT can already be integrated and used.
But there is more work to do.
The next goal is to reduce the friction related to code signing, packaging and encrypting CEP extensions
If all goes according to plan, PluginInstaller will handle both the packaging (by the developer) and installing (by the end-user) of CEP extensions.
It will transparently handle both the ‘mock’ code signing (CEP code signing) enforced by Adobe as part of its security theater, and will add a layer of ‘real’ code signing on top of that (CRDT code signing).
And of course, CRDT will provide a developer with the features they need to monetize their work.
CEP Code Signing – ucf.jar
PluginInstaller needs to handle the CEP code signing, so I’ve been doing some research, and I’ve discovered that the good old ucf.jar in the crusty old Adobe signingtoolkit can be made to work and can jpackage-d with a recent Java JDK.
I’ve got it working on my M2 Mac, and will now integrate it into PluginInstaller.
I am hopeful this will allow me to enhance PluginInstaller to transparently manage CEP code signing
PluginInstaller will then automatically create the self-signed key and sign your extension, making the creation of a package just a little bit easier.
CEP Extensions: Packaging/Code Signing/Encrypting
The aim is for PluginInstaller to transparently handle two types of code-signing, and a layer of encryption.
- on one hand handle the Adobe-enforced CEP code signing
- additionally, and independently, it will handle CRDT code signing, which depends on a registry of public keys to keep track of developers and their signatures.
- it will also handle CRDT code encryption which is an AES-256-based encryption meant to replace JSXBIN.
CEP Code Signing
The whole bother with Adobe enforcing developers to sign CEP extensions is nothing but security theater. By making PluginInstaller handle this, I can remove another hurdle for CEP extension developers.
These signing keys are not verified in any which way by the Creative Cloud apps, so anyone can create their own key and sign anything and the Creative Cloud software will accept it, sight unseen.
Any hacker can claim to be anyone else, and create a self-signed key to ‘prove’ it to the Creative Cloud apps, and the Creative Cloud apps will happily take them at their word.
Nothing stops a malicious hacker from unzipping someone’s genuine .zxp, adding some malware to it, and re-package it with their own self-signed key.
CRDT Code Signing
CRDT code signing requires developers register their identity in a registry, so the PluginInstaller can verify their signature.
When a developer creates a developer account in PluginInstaller, a public/private key pair is automatically generated and the public key is published in the registry.
Developers retain their own private key locally, and PluginInstaller will use the private key to code-sign their scripts and data files when it packages the software.
CRDT Code Encryption
Additionally, CRDT also implements CRDT code encryption. This allows developers to protect their code from prying eyes. This is a replacement for JSXBIN as provided by ExtendScript.
What’s ahead
There is still a lot of work to be done on CRDT. Important things that are on my to-do list:
- integrate payment processors like PayPal and Stripe. At the moment, payments are still handled manually.
- handle packaging and installing of UXP plugins the same way ExtendScript and CEP Extensions are handled, so PluginInstaller can be a one-stop shop both for packaging (developerland) and installing (userland)