Maven 2 & 3

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.

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

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.

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...

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

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)...

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.

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

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.

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

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?

upgrading priority for 2.1 release.

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.

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

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)

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

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!

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

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

Is there a design document for this available somewhere?

Sorry Deng, I didn't get that done.

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

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

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

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.

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.

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!

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!

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.

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.

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.

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

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

changes done, waiting for central sync before commiting

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

Exception encrypting a regular password - fixing ...

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

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

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.

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.

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?

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

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

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

Final name - settings-security.xml

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

settings-security.xml - root tag renamed to settingsSecurity

Done in 2.1.x and 3.0 trunks