To address the issue of weak encryption of passwords, CME Group has contracted 
with Sonatype to create a custom build of Nexus that uses ssh keys and PKI for 
authentication.  We are expecting to receive a delivery early to mid April on 
the ssh based approach.  The PKI approach will require some customization on 
the maven client end, to allow for certificate based authentication.

You may want to contact Sonatype to address your issues, they will have a 
solution.

Thanks,

Roy

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Anders Hammar
Sent: Tuesday, March 13, 2012 4:41 AM
To: Maven Users List
Subject: Re: how to custom decrypt settings.xml passwords

I don't think this is possible to do through a Maven plugin. It has to be part 
of Maven core.
Unfortunately, Maven Core currently does not (that I've found) provide with a 
hook or extension to switch the encryption mechanism. Until that is 
implemented, I believe you need to create your own extended Maven installation 
with support for this.

I'm in a similar situation. For a corporate environment with fairly high 
security concerns, the current solution with passwords in settings.xml is a 
problem in general. Also, it causes problems on CI as the credentials are quite 
easy to get hold of (a simple Maven build will reveal it). So, currently, we've 
not allowed CI to deploy artifacts to the repo.

So, from my perspective there are different things to solve (in my case at 
least):
* A simpler/better solution to handle the users' credentials. This could be 
integration with smart cards, Windows SSO (kerberos?), etc.
The user shouldn't have to update the settings.xml.
* A good/secure integration between CI and the repo. Ultimately I'd like the 
end user's credentails to be used (not a generic CI account as I want to know 
exactly who pressed the build button). If a generic CI account is used, it has 
to be kept outside of the Maven Core loop so that it can't be snooped.

/Anders
On Tue, Mar 13, 2012 at 10:07, Lannoye Xavier <[email protected]> wrote:
> Hi
>
> I'm working in a corporate environment, with maven builds processed on 
> atlassian bamboo servers. I've been asked to investigate a solution to 
> encrypt passwords present in the custom settings.xml file against our 
> corporate encryption software.
>
> I've started with the maven's master-password procedure, but with this 
> procedure, we faced the distributed bamboo's remote agents issue. 
> passwords must be encrypted using the master password of the server it 
> is going to be decrypted later on, and with bamboo agents, you cannot 
> guarantee on which server the build will be executed.
>
> Then I read about ssh encrypted passwords, but this requires ssh login 
> for each of our customers on our servers, which they don't have. We 
> have to many users to create unix accounts for each of them, and 
> furthermore, we don't want them to access our servers by other 
> meanings than the bamboo interface. Not mentioning they should have access to 
> every remote agent.
>
> so this is why we finally get to the point we need to force our bamboo 
> users to include in their project their own settings.xml file, which 
> they call in their build with the "-s" parameter.
> in settings.xml however, the passwords are plain text, and so are 
> readable by anyone.
>
> I was thinking about writing a maven plugin which could use our 
> corporate encryption software to decrypt passwords. But I cannot 
> figure out how to hook this inside maven. I already wrote a plugin 
> that reads the settings.xml file, but how to "push" the decrypted 
> password inside the maven build process? I'd need something as a "hook" but 
> cannot find any.
>
> Thanks for everyone for taking the time to read this (quite) long message.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to