#2
|
|||
|
|||
If you store your signing certificate in the Windows certificate store, you don't need specify a password on the Sign Code action [1].
Another option would be to store the password in a global macro instead of the .bld file, and reference that macro from the password field. Then only someone with access to the machine where the global macro has been added will have access to the password. You could also store it there encrypted, but VBP won't currently do that for you. We do intend to provide encryption capabilities in a future release (most likely a level with hard-coded key and another requiring the user to provide a password to unencrypt/open/build; since unless VBP prompts for a password to unencrypt the .bld file, any encrypting that it does will just amount to security through obscurity [2]). But even this doesn't really eliminate the problem, since *that* password still has to be stored and provided in order to build in an automated fashion. [1] http://www.kinook.com/blog/?p=10 [2] http://en.wikipedia.org/wiki/Security_through_obscurity Admin note: Implemented in v7 |
|
|