Gradle reading maven's settings.xml and settings-security.xml

I know the question of having gradle reading settings.xml and possibly also settings-security.xml to get authentication information comes up from time to time. I have a little bit of code I wrote to do this. It’s not very elegant, but it has the two lines of code required to decrypt passwords using settings-security.xml. The code is in the form of a class that you can get into your build script’s classpath. It’s not that useful in its current form though since there’s a chicken and egg problem…I can’t deploy this to my internal nexus and have anyone else (internal) use it because they need its functionality to get it from the repo. For something like this to be useful, it either has to be built in or it has to be in a public place, but we have all our formal builds configured to only pull things from our nexus repository.

So…would providing this code be useful? settings-security.xml is just obfuscation, and anyone can do what I did, which is to look at the maven source code and figure out exactly how to decrypt the passwords. It’s so trivial that I may just drop use of settings-security.xml entirely and just let the passwords be in clear text. But the advantage of obfuscation is that, while it doesn’t provide any real security, it at least makes it harder to accidentally expose passwords.

Should I do anything with this code other than using it internally?

Thanks for bringing this up. It’s not something we’d likely ship with Gradle, as we strongly believe that Gradle builds should be self-contained. That said, perhaps you could publish this as a third-party plugin. Another option might be to provide a similar feature for Gradle that allows to, say, read obfuscated credentials from ‘gradle.properties’.