Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-553

Secure Storage of Server Passwords

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-alpha-3
    • Fix Version/s: 2.1.0, 3.0-alpha-3
    • Component/s: Settings
    • Labels:
      None
    • Environment:
      Although it may not be relevant since this is a general improvement issue, Windows XP, JDK 1.4.1.
    • Complexity:
      Expert
    • Number of attachments :
      1

      Description

      This was a question pose to the Maven User's Group and it was suggested I add it here.

      It would be benefitial to provide a more secure means of storing password's to the servers listed in the .m2/settings.xml. They are currently being stored as plain text and could definately be considered a security breach. Numerous organizations would undoubtedly considered this an unacceptable security risk, and this could prevent widespread adoption of Maven2.

      I would suggest leaving an option to encrypt the password into the settings file (more secure, but not foolproof) or even requiring the password to be manually provided per build (would prevent automation of builds). I am sure that there is a secure solution to this problem and it should be part of the 2.0 release.

      1. MNG-553.patch
        1 kB
        Benjamin Bentmann

        Issue Links

          Activity

          Hide
          Jason van Zyl added a comment -

          I'm just putting this in the queue to be dealt with. I'm not sure if we'll be able to get to this for beta-1but security is a real concern even though we are pushing just to flesh out core features at the moment.

          Show
          Jason van Zyl added a comment - I'm just putting this in the queue to be dealt with. I'm not sure if we'll be able to get to this for beta-1but security is a real concern even though we are pushing just to flesh out core features at the moment.
          Show
          Brett Porter added a comment - here is the first cut I took a few months back. I was still deliberating on the API. http://cvs.plexus.codehaus.org/trunk/plexus-sandbox/plexus-components/plexus-password-store/src/main/java/org/codehaus/plexus/components/password/JksPasswordStore.java?rev=1487&view=markup
          Hide
          Brett Porter added a comment -

          there's a good chance this might miss 2.0 but is a certainty for 2.1. Still holding onto it for the next beta (it won't change existing behaviour), so we'll see how we go.

          Show
          Brett Porter added a comment - there's a good chance this might miss 2.0 but is a certainty for 2.1. Still holding onto it for the next beta (it won't change existing behaviour), so we'll see how we go.
          Hide
          Steve Loughran added a comment -

          It is effectively impossible to secure passwords and have a fully automated build, because, even if encrypted, the key to decrypt will still be needed.

          prompted input suffers from (a) the need to have a human in the build and (b) the fact there is no way to turn off echoed chars from the command line.

          If you do want to keep keys and stuff safe
          -put them in a directory with locked down permissions
          -consider an encrypted filesystem
          -consider an external storage (USB filesys)
          -use the TPM of the laptop to secure a bit of your hdd

          I use the latter and have to deal with the relevant device drivers asking for a password whenever I first try and access the data after a boot/resume.

          Trying to secure passwords in java is a very hard and unreliable process (think: where is your app swapped out to; what if the system hibernated during a run...). At least having blatantly insecure passwords stops people getting overconfident...

          Show
          Steve Loughran added a comment - It is effectively impossible to secure passwords and have a fully automated build, because, even if encrypted, the key to decrypt will still be needed. prompted input suffers from (a) the need to have a human in the build and (b) the fact there is no way to turn off echoed chars from the command line. If you do want to keep keys and stuff safe -put them in a directory with locked down permissions -consider an encrypted filesystem -consider an external storage (USB filesys) -use the TPM of the laptop to secure a bit of your hdd I use the latter and have to deal with the relevant device drivers asking for a password whenever I first try and access the data after a boot/resume. Trying to secure passwords in java is a very hard and unreliable process (think: where is your app swapped out to; what if the system hibernated during a run...). At least having blatantly insecure passwords stops people getting overconfident...
          Hide
          Brett Porter added a comment -

          Thanks Steve. You're absolutely correct and that will make a great start to a doc explaining it

          Show
          Brett Porter added a comment - Thanks Steve. You're absolutely correct and that will make a great start to a doc explaining it
          Hide
          Fabrice Bellingard added a comment -

          I just want to mention that this issue looks more than just minor (at least to me! ).
          Indeed, I want to spread Maven 2 all over my company (thousands of developers), but the fact that it is not possible to encrypt passwords in Maven (at least in the settings.xml file for the proxy parameters) does not encourage security managers to allow me to do so...
          I've already talked a lot about Maven 2, and lots of developers are willing to use it. But I won't be able to distribute Maven in my company unless this issue is resolved. That's why I find that this issue is at least Major, and I will hardly be able to wait till 2.1 (looking at the bug list to fix before releasing it)...

          Show
          Fabrice Bellingard added a comment - I just want to mention that this issue looks more than just minor (at least to me! ). Indeed, I want to spread Maven 2 all over my company (thousands of developers), but the fact that it is not possible to encrypt passwords in Maven (at least in the settings.xml file for the proxy parameters) does not encourage security managers to allow me to do so... I've already talked a lot about Maven 2, and lots of developers are willing to use it. But I won't be able to distribute Maven in my company unless this issue is resolved. That's why I find that this issue is at least Major, and I will hardly be able to wait till 2.1 (looking at the bug list to fix before releasing it)...
          Hide
          Thomas Van de Velde added a comment -

          Same here. This a major security issue and blocks wide adoption of Maven in our organization. A minor priority seems completely inappropriate here, at least if you want to use Maven at a enterprise level.

          Show
          Thomas Van de Velde added a comment - Same here. This a major security issue and blocks wide adoption of Maven in our organization. A minor priority seems completely inappropriate here, at least if you want to use Maven at a enterprise level.
          Hide
          Brett Porter added a comment -

          how do you work around this in the build systems of those areas that have not adopted Maven?

          Show
          Brett Porter added a comment - how do you work around this in the build systems of those areas that have not adopted Maven?
          Hide
          J. Michael McGarr added a comment -

          Currently, our oganization's work around involves the use of public/private key authentication. This requires, however, that the maven repository reside on a machine that is accessible via SSH and SCP protocols (specifically we are using SCPEXE and forcing developers to download and install putty/pagent).

          Ideally, we would have liked to make the Maven Repository HTTP accessible to our developers, but clear text passwords in a configuration file would not pass any of our security audits.

          Show
          J. Michael McGarr added a comment - Currently, our oganization's work around involves the use of public/private key authentication. This requires, however, that the maven repository reside on a machine that is accessible via SSH and SCP protocols (specifically we are using SCPEXE and forcing developers to download and install putty/pagent). Ideally, we would have liked to make the Maven Repository HTTP accessible to our developers, but clear text passwords in a configuration file would not pass any of our security audits.
          Hide
          Emmanuel Venisse added a comment -

          If it's an internal repository, why do you need login/password?

          Show
          Emmanuel Venisse added a comment - If it's an internal repository, why do you need login/password?
          Hide
          Brett Porter added a comment -

          Thanks. Specifically I was addressing Thomas' comment "blocks wide adoption of Maven". Presumably the solution they already have in place handles this otherwise it wouldn't block adoption - I'm wondering what that is. Unless everything is shipped around by hand / via the SCM?

          Show
          Brett Porter added a comment - Thanks. Specifically I was addressing Thomas' comment "blocks wide adoption of Maven". Presumably the solution they already have in place handles this otherwise it wouldn't block adoption - I'm wondering what that is. Unless everything is shipped around by hand / via the SCM?
          Hide
          Brett Porter added a comment -

          upgrading priority for 2.1 release.

          Show
          Brett Porter added a comment - upgrading priority for 2.1 release.
          Hide
          Brett Porter added a comment -

          Something to investigate for implementation of this:

          • how exactly do apps like svn cache and store it. I assume that while its not perfect, the addition of home directory security + some mild encryption helps.
          • utilise the plexus-interaction jline lib for password entry, to have first time entry on the command line

          We should probably recommend that deployment only be done from well secured servers by restricted users, and have this mostly as a download option.

          Show
          Brett Porter added a comment - Something to investigate for implementation of this: how exactly do apps like svn cache and store it. I assume that while its not perfect, the addition of home directory security + some mild encryption helps. utilise the plexus-interaction jline lib for password entry, to have first time entry on the command line We should probably recommend that deployment only be done from well secured servers by restricted users, and have this mostly as a download option.
          Hide
          Oliver Siegmar added a comment -

          Also note, that at least Java6 has support for reading passwords without echoing it to the console - http://java.sun.com/javase/6/docs/api/java/io/Console.html

          Show
          Oliver Siegmar added a comment - Also note, that at least Java6 has support for reading passwords without echoing it to the console - http://java.sun.com/javase/6/docs/api/java/io/Console.html
          Hide
          galmeida added a comment -

          Even storing encrypted password is considered insecure by some organizations/individuals, so please, wagons should really ask for passwords when they can not be found in settings.xml (or other more secure store)

          Show
          galmeida added a comment - Even storing encrypted password is considered insecure by some organizations/individuals, so please, wagons should really ask for passwords when they can not be found in settings.xml (or other more secure store)
          Hide
          Brett Porter added a comment -

          good number of votes - I'll take a crack at a proposal

          Show
          Brett Porter added a comment - good number of votes - I'll take a crack at a proposal
          Hide
          Scott Wintermute added a comment -

          I am thrilled to hear and see this issue will be looked into. I agree with others above that it should have been a higher priority for some time now (at least Major) as I have been waiting and hoping to see it implemented. I have personally had fairly significant issues in trying to work around this issue within our organization over the past year and a half while trying to spread the adoption of Maven2. Can't wait to see!

          Show
          Scott Wintermute added a comment - I am thrilled to hear and see this issue will be looked into. I agree with others above that it should have been a higher priority for some time now (at least Major) as I have been waiting and hoping to see it implemented. I have personally had fairly significant issues in trying to work around this issue within our organization over the past year and a half while trying to spread the adoption of Maven2. Can't wait to see!
          Hide
          Joe Cool added a comment -

          I agree. A fix for this issue should be in the next maven release.

          Show
          Joe Cool added a comment - I agree. A fix for this issue should be in the next maven release.
          Hide
          Douglas Kaminsky added a comment -

          Any traction on this issue? Been over 2 years since it's been reported.

          Show
          Douglas Kaminsky added a comment - Any traction on this issue? Been over 2 years since it's been reported.
          Hide
          Maria Odea Ching added a comment -

          Is there a design document for this available somewhere?

          Show
          Maria Odea Ching added a comment - Is there a design document for this available somewhere?
          Hide
          Brett Porter added a comment -

          Sorry Deng, I didn't get that done.

          My suggestion would be to come up with something similar to Jetty's password obfuscation feature.

          Show
          Brett Porter added a comment - Sorry Deng, I didn't get that done. My suggestion would be to come up with something similar to Jetty's password obfuscation feature.
          Hide
          Maria Odea Ching added a comment -

          Ok, thanks Brett. I'll see what I can come up for this..

          Show
          Maria Odea Ching added a comment - Ok, thanks Brett. I'll see what I can come up for this..
          Hide
          Maria Odea Ching added a comment -

          I made an initial draft on how to implement this issue, please see http://docs.codehaus.org/display/MAVEN/Secured+Passwords. Comments and suggestions are very welcome

          Show
          Maria Odea Ching added a comment - I made an initial draft on how to implement this issue, please see http://docs.codehaus.org/display/MAVEN/Secured+Passwords . Comments and suggestions are very welcome
          Hide
          Heinrich Nirschl added a comment -

          the original report was asking for increased security. Password
          obfuscation does not help very much to achieve that. Everybody with
          access to the obfuscated password can easily get back the clear text.
          It might make people think their passwords are safe, when in fact
          they are not. So from security point of view obfuscation may be even
          more dangerous than storing passwords in clear because then everybody
          knows that the settings file has to be protected in some other way.

          What about using real encryption? For example with a password based
          encryption scheme where a master password that has to be entered
          interactively is used to decrypt all the other passwords. This must be
          an optional feature to still allow convenient working in low secure
          environments and for batch usage.

          Show
          Heinrich Nirschl added a comment - the original report was asking for increased security. Password obfuscation does not help very much to achieve that. Everybody with access to the obfuscated password can easily get back the clear text. It might make people think their passwords are safe, when in fact they are not. So from security point of view obfuscation may be even more dangerous than storing passwords in clear because then everybody knows that the settings file has to be protected in some other way. What about using real encryption? For example with a password based encryption scheme where a master password that has to be entered interactively is used to decrypt all the other passwords. This must be an optional feature to still allow convenient working in low secure environments and for batch usage.
          Hide
          Brett Porter added a comment -

          I think it is worth having both capabilities - perhaps the obfuscation feature should be a new issue. I keep my home dir pretty safe, but if I open the settings file in front of someone they could read the password.

          The code I linked to above should do enough for a keystore for this. We would then need to use the bundled interactivity API to unlock it with a master password on first use (but make sure it's not earlier). Otherwise it could become very annoying.

          Show
          Brett Porter added a comment - I think it is worth having both capabilities - perhaps the obfuscation feature should be a new issue. I keep my home dir pretty safe, but if I open the settings file in front of someone they could read the password. The code I linked to above should do enough for a keystore for this. We would then need to use the bundled interactivity API to unlock it with a master password on first use (but make sure it's not earlier). Otherwise it could become very annoying.
          Hide
          Maria Odea Ching added a comment -

          Ok, thanks for pointing that out Heinrich. I'll create a separate design doc for the encryption. I'll look more into the code Brett posted above.. Thanks!

          Show
          Maria Odea Ching added a comment - Ok, thanks for pointing that out Heinrich. I'll create a separate design doc for the encryption. I'll look more into the code Brett posted above.. Thanks!
          Hide
          Maria Odea Ching added a comment -

          I made some updates in the design docs: http://docs.codehaus.org/display/MAVEN/Secured+Passwords
          I already included password encryption in the document. Please review.. Thanks!

          Show
          Maria Odea Ching added a comment - I made some updates in the design docs: http://docs.codehaus.org/display/MAVEN/Secured+Passwords I already included password encryption in the document. Please review.. Thanks!
          Hide
          Paul Benedict added a comment - - edited

          I think we should go for the full kitchen sink solution. We shouldn't invent something new, but should provide adapters to datastores. Just do what Spring (Acegi) Security did, which is provide a simple API to be implemented by anyone who wants to write in a provider.... NT authentication, LDAP, DB2, etc.

          Show
          Paul Benedict added a comment - - edited I think we should go for the full kitchen sink solution. We shouldn't invent something new, but should provide adapters to datastores. Just do what Spring (Acegi) Security did, which is provide a simple API to be implemented by anyone who wants to write in a provider.... NT authentication, LDAP, DB2, etc.
          Hide
          Ringo De Smet added a comment -

          On Mac OS X, I would really like to see the passwords stored in the Keychain. I don't know if there is any Java based access to this system though.

          Show
          Ringo De Smet added a comment - On Mac OS X, I would really like to see the passwords stored in the Keychain. I don't know if there is any Java based access to this system though.
          Hide
          Brett Porter added a comment -

          as long as one implementation uses a Java keystore, you can use the Keychain on OS X: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html#//apple_ref/doc/uid/TP40001901-210260

          However, I don't believe this will give access to existing internet passwords, etc. It just allows you to store keys in there.

          Show
          Brett Porter added a comment - as long as one implementation uses a Java keystore, you can use the Keychain on OS X: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html#//apple_ref/doc/uid/TP40001901-210260 However, I don't believe this will give access to existing internet passwords, etc. It just allows you to store keys in there.
          Hide
          Haikal Saadh added a comment -

          Another "Keychain integration would be nice on MacOS X" comment.

          Show
          Haikal Saadh added a comment - Another "Keychain integration would be nice on MacOS X" comment.
          Hide
          Oleg Gusakov added a comment - - edited

          I started adding this to 2.1 trunk according to http://docs.codehaus.org/display/MAVEN/Secured+Passwords

          Show
          Oleg Gusakov added a comment - - edited I started adding this to 2.1 trunk according to http://docs.codehaus.org/display/MAVEN/Secured+Passwords
          Hide
          Oleg Gusakov added a comment -

          changes done, waiting for central sync before commiting

          Show
          Oleg Gusakov added a comment - changes done, waiting for central sync before commiting
          Hide
          Oleg Gusakov added a comment - - edited

          Implemented solution is manual for now, I will add automation plugin later on. I already have the plugin but need to modify it a little.

          Manual process

          To encrypt a password, run the following cli:

          java -cp maven-2.1.0-M2-SNAPSHOT-uber.jar org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher [ -m | -p ]

          where:

          • -m means encrypt master password
          • -p means encrypt a password

          To setup encryption for server my.server

          • encrypt master password - get the output and save in ~/.m2/sec.xml
            <settingsSecurity>
              <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master>
            </settingsSecurity>
            
          • encrypt the password with cli
          • save the password into settings.xml
                <server>
                  <id>my.server</id>
                  <username>foo</username>
                  <password>{COQLCE6DU6GtcS5P=}</password>
                </server>
            
          • that is all. Maven will intercept the password and decrypt it on the fly.

          Because password is decrypted and send like that on the wire, you don't get much security from this approach, unless the connection itself is encrypted.

          The best layout is like the following:

          • have all global settings in in the global settings.xml file - $M2_HOME/conf/settings.xml, keep all profiles here
          • move servers secrion to ~/.m2/settings.xml - keep all you private passwords encrypted in this file
          • keep encrypted master password in ~/.m2/sec.xml
            • if you want to enhance this - move this file to a removable disk and put a reference to that file into ~/.m2/sec.xml
              <settingsSecurity>
                <relocation>/Volumes/mySecureUsb/secret/sec.xml</relocation>
              </settingsSecurity>
              

              then password will be read from /Volumes/mySecureUsb/secret/sec.xml

          Show
          Oleg Gusakov added a comment - - edited Implemented solution is manual for now, I will add automation plugin later on. I already have the plugin but need to modify it a little. Manual process To encrypt a password, run the following cli: java -cp maven-2.1.0-M2-SNAPSHOT-uber.jar org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher [ -m | -p ] where: -m means encrypt master password -p means encrypt a password To setup encryption for server my.server encrypt master password - get the output and save in ~/.m2/sec.xml <settingsSecurity> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> </settingsSecurity> encrypt the password with cli save the password into settings.xml <server> <id>my.server</id> <username>foo</username> <password>{COQLCE6DU6GtcS5P=}</password> </server> that is all. Maven will intercept the password and decrypt it on the fly. Because password is decrypted and send like that on the wire, you don't get much security from this approach, unless the connection itself is encrypted. The best layout is like the following: have all global settings in in the global settings.xml file - $M2_HOME/conf/settings.xml , keep all profiles here move servers secrion to ~/.m2/settings.xml - keep all you private passwords encrypted in this file keep encrypted master password in ~/.m2/sec.xml if you want to enhance this - move this file to a removable disk and put a reference to that file into ~/.m2/sec.xml <settingsSecurity> <relocation>/Volumes/mySecureUsb/secret/sec.xml</relocation> </settingsSecurity> then password will be read from /Volumes/mySecureUsb/secret/sec.xml
          Hide
          Oleg Gusakov added a comment -

          Exception encrypting a regular password - fixing ...

          Show
          Oleg Gusakov added a comment - Exception encrypting a regular password - fixing ...
          Hide
          Oleg Gusakov added a comment -

          everything is fixed, waiting for central sync before committing changes .. I will post a comment as soon as everything comes together.

          What's in the trunk now works, but does not have CLI to encrypt passwords

          Show
          Oleg Gusakov added a comment - everything is fixed, waiting for central sync before committing changes .. I will post a comment as soon as everything comes together. What's in the trunk now works, but does not have CLI to encrypt passwords
          Hide
          Benjamin Bentmann added a comment -

          Some comments:

          SecUtil.read() leaks file handles in case of exceptions, the call to in.close() should be moved to a finally block.

          SecUtil.toStream() suffers from the same subtle bug I reported in MERCURY-63.

          The impl of DefaultSecDispatcher.isEncryptedString() introduces a regression for any passwords of the form *{*}* , causing the build to fail with a FATAL ERROR. Why don't we extend the settings model with an additional element to clearly indicate
          a) that the password is encrypted instead of checking for some arbitrary syntax
          b) what password encryption method is used if in the future we come up with alternatives users can choose from

          Show
          Benjamin Bentmann added a comment - Some comments: SecUtil.read() leaks file handles in case of exceptions, the call to in.close() should be moved to a finally block. SecUtil.toStream() suffers from the same subtle bug I reported in MERCURY-63 . The impl of DefaultSecDispatcher.isEncryptedString() introduces a regression for any passwords of the form *{*}* , causing the build to fail with a FATAL ERROR. Why don't we extend the settings model with an additional element to clearly indicate a) that the password is encrypted instead of checking for some arbitrary syntax b) what password encryption method is used if in the future we come up with alternatives users can choose from
          Hide
          Oleg Gusakov added a comment - - edited

          Will fix the util - thank you!

          *{*}* - please be more specific. Pure isEncrypted( "*{*}*" ) works just fine. Overall check is a simple "find first

          {", "find first }

          ", "make sure first } is after first {".

          Introduction of a new element immediately wipes out any attempts to backport encryption to previous versions. Besides - this is a low-frequency operation, it does not affect any speed characteristics.

          Specifying encryption method and the rest is already there, but I want to test it first, before talking about it.

          Show
          Oleg Gusakov added a comment - - edited Will fix the util - thank you! *{*}* - please be more specific. Pure isEncrypted( "*{*}*" ) works just fine. Overall check is a simple "find first {", "find first } ", "make sure first } is after first {". Introduction of a new element immediately wipes out any attempts to backport encryption to previous versions. Besides - this is a low-frequency operation, it does not affect any speed characteristics. Specifying encryption method and the rest is already there, but I want to test it first, before talking about it.
          Hide
          Benjamin Bentmann added a comment -

          please be more specific.

          The attached patch slightly tweaks the existing IT 0113 by having the password include braces. The IT still works with
          existing Maven version but breaks with 2.1.x branch including the security feature.

          Besides - this is a low-frequency operation, it does not affect any speed characteristics.

          My concern is not speed but backward-compat. Previously, all strings were valid plaintext passwords. Now, a certain subset of this space has been given a new semantic, namely an encrypted password.

          Show
          Benjamin Bentmann added a comment - please be more specific. The attached patch slightly tweaks the existing IT 0113 by having the password include braces. The IT still works with existing Maven version but breaks with 2.1.x branch including the security feature. Besides - this is a low-frequency operation, it does not affect any speed characteristics. My concern is not speed but backward-compat. Previously, all strings were valid plaintext passwords. Now, a certain subset of this space has been given a new semantic, namely an encrypted password.
          Hide
          Jörg Schaible added a comment -

          I did not have a real problem using a plain password in .m2/settings.xml. If you set the proper rights for the .m2 directory it is no more different than the private keys kept in .ssh. However, the main problem IMHO was that with effective:pom you were able to display the password and the password was also written into the URLs of a released POM. Does the change address those two problems also?

          Show
          Jörg Schaible added a comment - I did not have a real problem using a plain password in .m2/settings.xml. If you set the proper rights for the .m2 directory it is no more different than the private keys kept in .ssh. However, the main problem IMHO was that with effective:pom you were able to display the password and the password was also written into the URLs of a released POM. Does the change address those two problems also?
          Hide
          Oleg Gusakov added a comment - - edited

          Benjamin:

          Now I understand the concern.

          Yes - it may fail on a plaintext password like _dlkajflhjwe

          {jwb}

          nn_. To address that I will introduce an option to turn this feature off completely. So that developers will have an option to either change password or turn this feature off

          Show
          Oleg Gusakov added a comment - - edited Benjamin: Now I understand the concern. Yes - it may fail on a plaintext password like _dlkajflhjwe {jwb} nn_. To address that I will introduce an option to turn this feature off completely. So that developers will have an option to either change password or turn this feature off
          Hide
          Oleg Gusakov added a comment - - edited

          Joerg wrote:

          I did not have a real problem using a plain password in .m2/settings.xml

          This has the same security strength as the added solution, but many people misused settings.xml and kept <servers> section in the public place. This can now be addressed with having a private ~/.m2/sec.xml which contains the encryption key - now the server section can be public, but only people with appropriate key can use it.

          This is also enhanced with the "relocate" feature, which allows to put encryption key to a removable drive, so that multiple people can use the same OS account, but only those with the USB disk can update repositories.

          However, the main problem IMHO was that with effective:pom you were able to display the password and the password was also written into the URLs of a released POM. Does the change address those two problems also?

          help:effective-settings shows encrypted password, I did not check the released POM, but good chances are it also gets stuffed with encrypted password.

          Please let me know if it's not the case

          Show
          Oleg Gusakov added a comment - - edited Joerg wrote: I did not have a real problem using a plain password in .m2/settings.xml This has the same security strength as the added solution, but many people misused settings.xml and kept <servers> section in the public place. This can now be addressed with having a private ~/.m2/sec.xml which contains the encryption key - now the server section can be public, but only people with appropriate key can use it. This is also enhanced with the "relocate" feature, which allows to put encryption key to a removable drive, so that multiple people can use the same OS account, but only those with the USB disk can update repositories. However, the main problem IMHO was that with effective:pom you were able to display the password and the password was also written into the URLs of a released POM. Does the change address those two problems also? help:effective-settings shows encrypted password, I did not check the released POM, but good chances are it also gets stuffed with encrypted password. Please let me know if it's not the case
          Hide
          Oleg Gusakov added a comment - - edited

          Looks like the name sec.xml is too short and may be confusing. Changing for security-settings.xml

          Show
          Oleg Gusakov added a comment - - edited Looks like the name sec.xml is too short and may be confusing. Changing for security-settings.xml
          Hide
          Oleg Gusakov added a comment -

          Final name - settings-security.xml

          I left a snapshot in the trunk in case there are more changes

          Show
          Oleg Gusakov added a comment - Final name - settings-security.xml I left a snapshot in the trunk in case there are more changes
          Hide
          Oleg Gusakov added a comment -

          settings-security.xml - root tag renamed to settingsSecurity

          Show
          Oleg Gusakov added a comment - settings-security.xml - root tag renamed to settingsSecurity
          Hide
          Oleg Gusakov added a comment -

          Done in 2.1.x and 3.0 trunks

          Show
          Oleg Gusakov added a comment - Done in 2.1.x and 3.0 trunks

            People

            • Assignee:
              Oleg Gusakov
              Reporter:
              J. Michael McGarr
            • Votes:
              40 Vote for this issue
              Watchers:
              37 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: