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