I’ve now created a valid java keystore in /var/local/java/developer.keystore. Clicking on my ktest app in the menu now says "The title is not signed by a registered developer".
All righty, so getting closer!
I’ve not bothered to sign my ktest jar at all yet. Looking at the build.xml here, it looks like that author is signing his jars twice:
<signjar jar="${file.output}"
alias="${dev.kindlet.alias}"
keystore="${dir.keystore}/${kindlet.keystore}"
storepass="${developer.keystore.storepass}" />
<signjar jar="${file.output}"
alias="${dev.interaction.alias}"
keystore="${dir.keystore}/${kindlet.keystore}"
storepass="${developer.keystore.storepass}" />
That’s once for the kindlet itself, and once for the "interaction". Hmm, I wonder how it knows which key maps to which?
Aha, it seems opt/amazon/ebook/security/ is where the rest of the security configuration lurks. There are a few security policy files there (ooh, I assume you could define your own things in external.policy to add new permissions to kindlets). However, its the keystores that are most of interest just now:
* kcrt-public.keystore contains one entry: "kindlecertificatesupport".
* kindlet.keystore contains four: amazonclassloadingkindlet, kindlet, kindletinteractionsupport, kindletnetworksupport
There must be a key-signing chain mechanism: developers sign their kindlets with their three keys (dev-kindlet, dev-kindletinteractionsupport, dev-kindletnetworksupport) depending on what permissions they want.
UPDATE the developer keys proved not to be signed, so this section is wrong/unnecessary:
However, I’d bet those dev- keys are also signed with amazon’s keys, which we have the public part of in kindlet.keystore. This prevents anyone loading an unsigned app, but also means amazon enforce which signatures are allowed.
Hmm, if this is the case, then we can simply replace the contents of kindlet.keystore with our own keys and sign with those instead. OR: I wonder if we can just hack the policy files about to allow a second set of keys?
ENDUPDATE
adq 