You are correct. If someone is able to read the maven code and find the
default password, decrypt the master password, then they could decrypt
the user password. It's also decrypted "on the wire" if you aren't using
https with your repos. The trick with a build server is to make a
special account for that system, the real danger comes when you use a
corporate password and someone gets that.
If you have real concerns about the build server, don't give people
permissions to change the jobs and then it will be harder for them to
get at these files.
Olivier Dehon wrote:
Hi,
I was reading about the recent enhancements to the management of server
passwords in settings.xml at
http://maven.apache.org/guides/mini/guide-encryption.html
A few questions arose around the actual security provided by these
enhancements in the context of a build/CI server.
Agreed, this is an enhancement over passwords in clear text in
settings.xml, where any developer can run the help:effective-settings
goal in a custom build definition to gain access to the passwords
configured there on the server.
But can it be considered a safe protection in the context of a build
server? For instance, what prevents a developer from running a build
definition that runs a command through the exec or antrun plugin that
outputs the content of the settings-security.xml, thereby compromising
the encryption?
Unless I miss the obvious (or the less obvious) I am under the
impression that this enhancement makes it harder to get to the
passwords, but does not make it impossible (and maybe this was never the
goal).
Thank you in advance for your insights/pointers.
-Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
