Hi I come back to you with my corporate encryption mechanism with a partial (still working) solution:
1/ get the maven sources 2/ change in the maven-core\src\main\resources\META-INF\plexus\component.xml file the implementation for the "org.sonatype.plexus.components.sec.dispatcher.SecDispatcher" compo to my own implementation of the org.sonatype.plexus.components.sec.dispatcher.SecDispatcher interface. 3/ mvn package I said partial working solution, because I still need to repack maven, when all I had to do was changing one line in the xml file. The implementation could be externalised of the maven sources (in a separate jar) but I did not found a way to load my jar before the maven-uber jar. (class shadowing approach). If someone of you know a way to do this, please tell me:-) thanks for your reading On 30 March 2012 13:00, Lannoye Xavier <lannoye.xav...@gmail.com> wrote: > hi all > > there is however something that bothers me: > I wrote a plugin that access the Settings object. That object > is instantiated by maven, and contains the merge of all settings available > (M2_HOME/conf/settings.xml, ~/.m2/settings.xml and "-s settings.xml"). > with my plugin, I look after my corporate encoded passwords, decode them, > and update the Settings object with the decoded value. > I linked my plugin with initialize, generate-resources > and process-resources phases. My debug shows me that at the very first > phase (initialize), the Settings object is well updated (password decrypted > using our corporate tool), and the two next phases show the correctly > updated Settings object - having the passwords decrypted. > > However, when maven goes for downloading dependencies, it fails because > maven takes the encrypted version of the password. IMHO, I think that maven > reads again the settings.xml file, whether it should use the Settings > object. > > Has someone some feedback for that? > > thanks for your reading > > > On 13 March 2012 14:59, Lyons, Roy <roy.ly...@cmegroup.com> wrote: > >> 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: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] 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 <lannoye.xav...@gmail.com> >> 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: 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 >> >> >
