[jira] [Updated] (MNG-8622) Ditch settings.xml (supplying credentials)

["Lars Bruun-Hansen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MNG-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Bruun-Hansen updated MNG-8622:
-----------------------------------
    Description: 
When working with Maven and CI workflows you'll often find yourself in a situation where the {{settings.xml}} file exists {*}solely as a vessel for credentials{*}.

Like this:
{code:xml}
<settings>
    <servers>
        <server>
            <id>my-server</id>
            <username>${env.MY_SERVER_USERNAME}</username>
            <password>${env.MY_SERVER_PASSWORD}</password>
        </server>
    </servers>
</settings>
{code}
 

Luckily there are nowadays various solutions in modern CI systems for {*}generating such file on-the-fly{*}. (for example: check out GitHub's own {{setup-java}} action).

 

But why?

 

This ticket is about exploring ideas for a having a CI world where such non-sense file is not required.

The first thing to recognize is that in a CI world the recommended way to supply credentials is by using environment variables. Writing some credentials to disk (even if only temporary) is seen as a major security risk. This is why CI workflows often look like the above.

So, environment variables are the way to go.

 

One idea would be that the elements of the {{<server>}} section could equally well be supplied using environment variables using some kind of fixed naming scheme, for example:
{noformat}
MVN_SERVER__<server-id>__USERNAME
MVN_SERVER__<server-id>__PASSWORD
MVN_SERVER__<server-id>__PRIVATE_KEY
MVN_SERVER__<server-id>__PASSPHRASE
{noformat}
In other words: As an example, if a plugin would look for credentials for a server-id named "my-server" it would first check so see if such entry existed in {{settings.xml}} file. It would then turn to OS environment variables to check if such values existed there, in this case looking for environment variables with named like:
{noformat}
MVN_SERVER__MY_SERVER__USERNAME
MVN_SERVER__MY_SERVER__PASSWORD
MVN_SERVER__MY_SERVER__PRIVATE_KEY
MVN_SERVER__MY_SERVER__PASSPHRASE
{noformat}
 

These are just ideas.

The basic theme here is how to make Maven more CI friendly.
 

  was:
When working with Maven and CI workflows you'll often find yourself in a situation where the {{settings.xml}} file exists {*}solely as a vessel for credentials{*}.

Like this:
{code:xml}
<settings>
    <servers>
        <server>
            <id>my-server</id>
            <username>${env.MY_SERVER_USERNAME}</username>
            <password>${env.MY_SERVER_PASSWORD}</password>
        </server>
    </servers>
</settings>
{code}
 

Luckily there are nowadays various solutions in modern CI systems for {*}generating such file on-the-fly{*}. (for example: check out GitHub's own {{setup-java}} action).

 

But why?

 

This ticket is about exploring ideas for a having a CI world where such non-sense file is not required.

The first thing to recognize is that in a CI world the recommended way to supply credentials is by using environment variables. Writing some credentials to disk (even if only temporary) is seen as a major security risk. This is why CI workflows often look like the above.

So, environment variables are the way to go.

 

One idea would be that the elements of the {{<server>}} section could equally well be supplied using environment variables using some kind of fixed naming scheme, for example:
{noformat}
MVN_SERVER__<server-id>__USERNAME
MVN_SERVER__<server-id>__PASSWORD
MVN_SERVER__<server-id>__PRIVATE_KEY
MVN_SERVER__<server-id>__PASSPHRASE
{noformat}
In other words: As an example, if a plugin would look for credentials for a server-id named "my-server" it would first check so see if such entry existed in {{settings.xml}} file. If not, it would look for values in environment variables, in this case:
{noformat}
MVN_SERVER__MY_SERVER__USERNAME
MVN_SERVER__MY_SERVER__PASSWORD
MVN_SERVER__MY_SERVER__PRIVATE_KEY
MVN_SERVER__MY_SERVER__PASSPHRASE
{noformat}
These are just ideas.

The basic theme here is how to make Maven more CI friendly.
 


> Ditch settings.xml (supplying credentials)
> ------------------------------------------
>
>                 Key: MNG-8622
>                 URL: https://issues.apache.org/jira/browse/MNG-8622
>             Project: Maven
>          Issue Type: Improvement
>            Reporter: Lars Bruun-Hansen
>            Priority: Major
>
> When working with Maven and CI workflows you'll often find yourself in a situation where the {{settings.xml}} file exists {*}solely as a vessel for credentials{*}.
> Like this:
> {code:xml}
> <settings>
>     <servers>
>         <server>
>             <id>my-server</id>
>             <username>${env.MY_SERVER_USERNAME}</username>
>             <password>${env.MY_SERVER_PASSWORD}</password>
>         </server>
>     </servers>
> </settings>
> {code}
>  
> Luckily there are nowadays various solutions in modern CI systems for {*}generating such file on-the-fly{*}. (for example: check out GitHub's own {{setup-java}} action).
>  
> But why?
>  
> This ticket is about exploring ideas for a having a CI world where such non-sense file is not required.
> The first thing to recognize is that in a CI world the recommended way to supply credentials is by using environment variables. Writing some credentials to disk (even if only temporary) is seen as a major security risk. This is why CI workflows often look like the above.
> So, environment variables are the way to go.
>  
> One idea would be that the elements of the {{<server>}} section could equally well be supplied using environment variables using some kind of fixed naming scheme, for example:
> {noformat}
> MVN_SERVER__<server-id>__USERNAME
> MVN_SERVER__<server-id>__PASSWORD
> MVN_SERVER__<server-id>__PRIVATE_KEY
> MVN_SERVER__<server-id>__PASSPHRASE
> {noformat}
> In other words: As an example, if a plugin would look for credentials for a server-id named "my-server" it would first check so see if such entry existed in {{settings.xml}} file. It would then turn to OS environment variables to check if such values existed there, in this case looking for environment variables with named like:
> {noformat}
> MVN_SERVER__MY_SERVER__USERNAME
> MVN_SERVER__MY_SERVER__PASSWORD
> MVN_SERVER__MY_SERVER__PRIVATE_KEY
> MVN_SERVER__MY_SERVER__PASSPHRASE
> {noformat}
>  
> These are just ideas.
> The basic theme here is how to make Maven more CI friendly.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)