Maven password encryption and usage in a CI server

[Olivier Dehon <od...@gmail.com>]

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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven password encryption and usage in a CI server

[Brett Porter <br...@apache.org>]

Even removing permissions may not help since anyone that can write a  
unit test to read that file. If you give Maven access to deploy, you  
give anyone with access to write code for that project to know the  
credentials to deploy with. As Brian said the best thing to do here is  
to use a CI specific account, and I'd add you might restrict requests  
to deploy to coming from that particular build server's IP. As long as  
the scope of those credentials is only to deploy snapshots of code  
then there should be little issue with someone gaining access to them  
more than committing some arbitrary code to the built tree.

Cheers,
Brett

On 05/05/2009, at 11:16 PM, Brian Fox wrote:

> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Re: Maven password encryption and usage in a CI server

[Brian Fox <br...@infinity.nu>]

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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org