In this series of posts and videos, we will explore creating and deploying a SOA composite using Oracle Developer Cloud Service.
To get started with Maven encryption, you need to create a master private key using some passphrase you come up with:
The output of this command is your private key. In order for Maven to use it, create a file under Maven's .m2 directory (usually under your user directory: ~/.m2 for linux, %USERPROFILE%/.m2 for Windows):
<master>OUTPUT FROM MVN --ENCRYPT-MASTER-PASSWORD</master>
Once this is done, use the following command to encrypt your real passwords:
This will generate another encrypted hash that can be used in settings.xml (or anywhere that is enabled to use Maven encryption. For example, here we defined a server in Maven's settings.xml:
<username>Your DevCS Username</username>
<password>OUTPUT FROM MVN --ENCRYPT-PASSWORD</password>
You can then use this server's id string as a reference in other settings.xml tags. In the video, for example, we use the above to connect to the remote Maven repository.
It is important to keep in mind that the master password is a lot like a private RSA key. Once someone has it, they can decrypt your password. In fact, the master password itself is decryptable (kudos to you if you can decipher the passwords shown in the video and answer the questions!), so putting the master key in source control is roughly equivalent to simply using clear-text passwords.
Maven actually suggests putting the master password on a USB drive so only a select group with the key can do deployments to production servers. For life in the cloud, though, this simply will not do. Compounding the matter is the fact that Hudson and Maven do not provide any nice way for you to pass in a custom security-settings.xml.
My only suggestion is to put the master password in another git repository with stricter / limited access and include this repository in the Hudson build. Then, add a script to the build that copies the master password into .m2/settings-security.xml (or whatever the path may be) on the build machine. That way, you can put a settings.xml containing encrypted passwords to sensitive hosts into your project's DevCS Git repository. Then, only the people with access to this second repository (namely the Hudson machine) will be able to decrypt the passwords. Suggestions on this issue are welcome.
For individual users, while encryption is always a safe idea, Maven's execution is a bit wanting. If a user can read your Maven configuration directory containing settings.xml and settings-security.xml, then it is all over because they can read your private key and decrypt your passwords. Still, it might be worth it if you routinely show your screen to people and want to avoid the embarrassment of a clear-text password. Of course, you can always do the USB trick yourself and lock the drive in a drawer when not needed.