[
https://issues.apache.org/jira/browse/MRELEASE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533324#comment-17533324
]
Michael Osipov commented on MRELEASE-1063:
------------------------------------------
One of the issues is that it is not evaluated by Maven itself, but rather a
third party component which is totally unaware of Maven. Although, I cannot
tell why this encryption was added, from a security PoV there is zero benefit.
{quote}As the maven release plugin is responsible for the invocations of the
maven execution for prepare and perform of the release it should in my view
ensure that any properties given to the main command are propagated to the
(forked?) execution for release preparation and release perform.
{quote}
I don't agree with this. The caller and the callee are different there is not
implication tha they have to share the same arguments. Fork is different as
direct invocation by human or machine.
Why can't you use {{MAVEN_OPTS}} to solve your problem? That system property
will be added to the JVM and Plexus Sec Dispatcher can consume it.
> Maven release plugin should retain settings.security environment variable for
> its forked executions of release:prepare and release:perform
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-1063
> URL: https://issues.apache.org/jira/browse/MRELEASE-1063
> Project: Maven Release Plugin
> Issue Type: Improvement
> Affects Versions: 2.5.2
> Reporter: Hans Aikema
> Priority: Major
> Labels: up-for-grabs
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> While trying to create a build with on-demand local provisioning of the
> secrets for the technical build-user on the build-slave (removing them
> directly after their use) I found out the hard way that the Maven-release
> plugin does not support a custom location for settings-security in the way
> that is documented at MNG-4853.
> When running
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform}}
> The user settings.xml flag is honored (by the fix of MRELEASE-577), but the
> custom settings-security from the environment variable is lost causing
> password decryption failures and therefor in the end a release failure when
> running against a repository that requires authentication.
> As a workaround one has to change the invocation to
> either
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> site-deploy -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> or
> {{mvn --settings myGeneratedSettings.xml
> -Dsettings.security=myGeneratedSettings-security.xml -B release:prepare
> release:perform -DpreparationGoals="clean verify
> -Dsettings.security=myGeneratedSettings-security.xml" -Dgoals="deploy
> -Dsettings.security=../../myGeneratedSettings-security.xml"}}
> depending on whether there is a site distribution configuration or not.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
