ACX, as requested...

[shakaote]

As requested, here's some of what I know about acx files.

acx is a zip, unzip it and looks just like waf (maybe with more hooks into amazon's system than I've seen in waf examples. Of course, waf is pretty much html5 with extra js apis for amazon.

The signature looks like xmlsec, which I'm just getting into. Once I've got that work out, I can play for real. I suspect a nice thing to do for ourselves is to just sign index.html with a link to an unsigned js file, then in the js file load whatever else you want and don't bother with the signing anymore (at least for hacking) - I don't think there's anyway for the system to know that's happening, but we'll see.

There used to (5.1) be a reader_plugins.xml where you could I suppose add your own, but it's gone. So I'm going to hijack another plugin and go from there (don't need wikipedia lookups, for instance).

Gotta go. Will post more as I find it.

PS Anyone who's already fiddled with signing xml or even acx, pls hop in. It's not really the fun part... but it's needed to get things working.

[shakaote]

Errr, no. Forgot about the little point of confusion there.

acx as in reader plugins, /opt/amazon/acw/*.acx.

Someone named eureka asked at the end of jbpatch discussion to dump what I'd got so far.

[eureka]

Thanks for response. I really appreciate it. Documentation about ACX (which stands for Active Content Extensions) could really improve developing experience, as they are much easier to poke with than reader's Java code.

BTW, ACX are in fact W3C Widgets (there is also doc on signing at the linked page).

reader_plugins.xml is embedded in /opt/amazon/ebook/lib/ReaderSDK-impl.jar in new firmwares.

UPD: another doc about Widget's signing. Amazon's keys are stored in /opt/amazon/ebook/security/keystore_mesquite.xml. I guess, you should add your own key to that file to be able to sign widgets.

UPD2: another one doc

[knc1]

OH, boy - a another kind of "Dev. Certs" - -

Let it be a test of our readers on how well they are keeping up with changes.

[shakaote]

Originally Posted by knc1

OH, boy - a another kind of "Dev. Certs" - -

Let it be a test of our readers on how well they are keeping up with changes.

That's what I'm poking at. Or hoping to get time to. Most of what I've dug up about xmlsec1 is informative, but not terribly helpful for getting started. It might be possible to use keys stored in pubdevkeys.pem, or whatever it's called.

Incidentally, where are the private keys for that? Is the password "password"? It's what I would choose :-)

[eureka]

I know something about signing Kindle_Touch_ACX.

But wait (a day or two), howto is missing ATM, I'm just teasing...

[shakaote]

Oh, very cool!

This will make my kindle much more fun!

[eureka]

Wiki page had been updated.

[twobob]

if I knew a more awesome word than awesome I would use that one...

Awesomer!!!

[ixtab]

Originally Posted by eureka

Wiki page had been updated.

eureka, you seriously ROCK!

Fantastic work!!!

Unfortunately, I probably won't have the time to look into this in the near future. But I'll still post this request:

Please make available one "standard" signing keypair, and encourage everyone to use it from the start.

It's exactly the same fundamental problem as with the jailbreak or the Kindlet developer keys. We have to settle on (ideally) a single keypair which everybody can use to develop, and which users can install to run (any) custom software published here.

If every developer creates his own keypair instead of using the common one, we'll be in the same configuration hell that we've previously been in with the Kindlets.

IMHO, now -- i.e., before people actually start developing -- is the only chance to "standardize" ACX development and deployment (at least in terms of the required certificates/keys), so please do it.

[twobob]

I will happily embed the keys in kual-system for all to use. cheers

[aditya3098]

I smell google translate....

[eureka]

Originally Posted by twobob

if I knew a more awesome word than awesome I would use that one...

Awesomer!!!

Originally Posted by ixtab

eureka, you seriously ROCK!

Fantastic work!!!

Thanks, guys.

Originally Posted by ixtab

IMHO, now -- i.e., before people actually start developing -- is the only chance to "standardize" ACX development and deployment (at least in terms of the required certificates/keys), so please do it.

I will not post my test key. But, I think, shakaote will post his key, because it will be requirement for using his ACX. So, I guess, his key will become standard, because it will be the first posted key.

But I'd like to add some recommendations:

• please, set name parameter in PKCS#12 file generation to "HomebrewActiveContentExtensions" -- on a par with "AmazonActiveContentExtensions". Also use this name in XML Signature snippet (it set by default in Python script).
• don't set any encryption (i.e. passwords) on private key and PKCS#12 file. Just for convenience.

[twobob]

Originally Posted by aditya3098

I smell google translate....

Help, don't chelp

It is a WIKI after all :P

[PoP]

Originally Posted by eureka

Thanks, guys.


I will not post my test key. But, I think, shakaote will post his key, because it will be requirement for using his ACX. So, I guess, his key will become standard, because it will be the first posted key.

But I'd like to add some recommendations:

• please, set name parameter in PKCS#12 file generation to "HomebrewActiveContentExtensions" -- on a par with "AmazonActiveContentExtensions". Also use this name in XML Signature snippet (it set by default in Python script).
• don't set any encryption (i.e. passwords) on private key and PKCS#12 file. Just for convenience.

Seconded! And maybe advertise in a sticky thread similar to Merged Developer Keystore with a big fat colorful notice.
I don't know about PKCS#12, but FWIW I needed to use "password" for the java keystore, some Unix tools would refuse to work when the password is null.