[MNG-5438] cli parameter to use a custom path settings-security.xml

[jira-importer]

Sarah Haselbauer opened MNG-5438 and commented

added -ssec as cli param, so that you have the same flexibility to place your settings-security.xml as you have to point to a custom settings.xml file

mvn -s /path/to/my/custom/settings.xml -ssec /path/to/my/custom/settings-security.xml

I attached to patches: one that can be run on the maven-3.0.4 tag and one that can be run on trunk (latest code state of today).
I also attached a maven-3.0.4-bin.zip (linux) so you can quickly try out the feature and test it yourself.

if you like the idea, I would welcome to have this feature merged into one of the next releases. I need it to write a puppet-maven module that allows to download artifacts from maven repositories with encrypted passwords in the puppet recipe.

---

Affects: 3.0.4, 3.0.5

Attachments:

• apache-maven-3.0.4-ssec-bin.tar.gz (4.65 MB)
• apache-maven-3.0.4-ssec-bin.zip (4.67 MB)
• maven-3.0.4-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch (3.27 kB)
• maven-latest-0001-added-ssec-as-cli-param-so-that-you-have-the-same-fl.patch (3.13 kB)
• MNG-5438-maven-embedder.patch (1.34 kB)

Issue Links:

• MNG-6089 Define a command line option to define settings-security.xml as well as settings.xml as well

• MNG-4853 Make location of settings-security.xml configurable

5 votes, 9 watchers

[jira-importer]

Paul Landolt commented

This has been a big "missing" for a long time. Any team using shared build machines and enterprise build tools (Bamboo, Jenkins, TeamCity, etc) must patch around this on the fly.

The proposed solution worked at the time. What are the odds of an updated patch / pull request getting accepted?

[jira-importer]

Paul Landolt commented

Patch file against code as of Feb-20-2017. Follows current checkstyle rules

[jira-importer]

Matthias Balke commented

When is this change planned to be released? It seems that there is no progress since last year in here.

[jira-importer]

Robert Scholte commented

I prefer not to have an additional commandline argument for this. The settings-security file is strongly bound the the users settings.xml, so I would prefer to have these files in the same directory.
Allowing any random location might open a security breach.

[jira-importer]

Logan Mzz commented

So may be you can change '-s' behavior to accept a directory ?

 

Because you said its strongly bound but for the moment you can change 'settings.xml' location but not 'security-settings.xml' one

[jira-importer]

Robert Scholte commented

Either that or var securitySettings = settings.resolveSibling("security-settings.xml"); where settings is a Path.

[jira-importer]

Ed Randall commented

MNG-4853 already gave us -Dsettings.security=path/to/settings-security.xml, so any security breach is already present. And there's also the relocation mechanism.

The system actually become less secure if we are forced to keep settings.xml and settings-security.xml in the same directory (even if permissions are tightened).

We would like the ability to keep them separate in different locations so the permissions on settings-security.xml can be locked down rather more tightly (maybe separate filesystem, hidden/accessible by CI user only). This would allow developers to be permitted to view settings.xml whilst storing settings-security.xml safely out of the way.

Stalling this long-awaited feature on grounds of security becomes rather moot, this is just a usability convenience.