Question

I wanted to do a couple of things and am wondering if they re possible, and if so, how to do them.

I was going to make a Virtual Machine to run code-signing in. That way if my computer dies I can hopefully minimize downtime by simply running the VM in a new system. I know the code keys are tied to the machine they re run on. If anyone has done code signing in a VM and switched the VM to another physical machine please let me know if the keys continued to work or not.

I also wanted to run more than one JDE in the VM to sign code for different OSes. From what I understand the code signing uses a code signing app located in each JDE s directory. Is it possible to run multiple JDE s on the same system and be able to sign code for a specific OS (I m planning on having JDE 4.2.1, 4.5, 4.6.1, 4.7, and eventually 5.0 on the code-signing VM). If so, do I need multiple keys - one for each JDE version - or is there some way to use the same keys for the different versions?

Thanks for any help in answering this.

Answer 1

It s certainly possible to migrate the keys between machines - We have a set of keys that have been used on Windows XP, Mac OS X and Linux machines.

If you look in one of your BlackBerry JDE Component Package X.Y.Zin directories after you ve used the signing tool manually you ll see these files:

sigtool.csk
sigtool.db

These are the files you need. Simply copy them to the equivalent location in the alternate JDE trees and you will be able to use them for multiple targets . I ve not done this with 4.7.0, but have with 4.6.0, 4.5.0, 4.3.0, and 4.2.1. We re run the signer using

java -jar bin/SignatureTool.jar

I m not sure whether other methods would work.

Migrating to UNIX-like build machines introduces a twist, and this is why I think RIM say the keys are not portable - the SignatureTool application seems to not detect the operating system-specific directory path separator character. The upshot is that it looks for the key files in these locations, even on a UNIX machine (note the backslashes):

binsigtool.csk
binsigtool.db

when you d think it would look for bin/sigtool.csk for example. A solution for this is simply to create soft links with these names that point to the actual files. In the component package top-level directory we do this:

ln -s bin/sigtool.db bin\sigtool.db
ln -s bin/sigtool.csk bin\sigtool.csk

I ve only signed in one VM - a Windows XP image. It worked fine.

Answer 2

Another solution is to just fix the problem with SignatureTool (FYI, RAPC has similar issues), as this blog describes:

http://www.slashdev.ca/2008/03/16/using-sigtool-in-linux/

友情链接