[ 
https://issues.apache.org/jira/browse/MNG-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15496633#comment-15496633
 ] 

Stephen Connolly commented on MNG-6089:
---------------------------------------

>From my PoV we should do one of three things:

1. The {{settings-security.xml}} file should always be a sibling of the 
{{settings.xml}} file.
2. The {{settings-security.xml}} file should be checked first as a sibling of 
the {{settings.xml}} file and if not present then falling back to {{~/.m2/}}
3. Provide an option / mechanism to control the location

But actually when we look into the code a bit more carefully...

For using maven in embedded mode we cannot even assume there is a settings.xml 
file in the first place.

When the maven-release-plugin comes along to capture the effective settings, it 
therefore cannot be assured of a location of the settings.xml file and has to 
put the "effective" settings into a temporary location in order to ensure that 
the build runs with the correct settings.

So we have to take the release plugin concerns into account. It would be bad if 
the effective settings written to a temporary disk file by the release plugin 
contained decrypted passwords (IIRC it currently writes the passwords with the 
{{settings-security.xml}} encryption into that temporary file)... what would be 
much better is if the secrets were encrypted using a one-time key that is also 
thrown away.

We may have to dig into the embedding API to ensure that we do not make 
assumptions here that invalidate the embedder use as we can have a settings.xml 
that is never on disk or even an XML file through embedder... so it seems to be 
that an embedder user may also have a security settings that isn't even an XML 
file or on disk.

TL;DR

The ability to control the storage location of the master key is a requirement, 
but the actual mechanism as to how to implement and expose this requires an 
awareness of how settings are exposed through the embedder API

> Define an command line option to define settings-security.xml as well as 
> settings.xml as well
> ---------------------------------------------------------------------------------------------
>
>                 Key: MNG-6089
>                 URL: https://issues.apache.org/jira/browse/MNG-6089
>             Project: Maven
>          Issue Type: Improvement
>    Affects Versions: 3.3.9
>            Reporter: Karl Heinz Marbaise
>            Priority: Minor
>
> It would be nice improvement to add a command line to support the defintion 
> of the {{settings-security.xml}} like the {{settings.xml}} which would also 
> help support in Jenkins and of course in many other ways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to