[
https://issues.apache.org/jira/browse/MNG-8417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904098#comment-17904098
]
Tamas Cservenak edited comment on MNG-8417 at 12/9/24 11:12 AM:
----------------------------------------------------------------
Issue title is right: corrupt passwords will make Maven4 refuse to start.
But the assumptions in description are wrong. For start, on workstation you
should use some tool (pinentry, gpg-agent) that is usually integrated with OS
keychain and just not care about this (just like GPG plugin).
Second, if Maven "cannot decrypt" password, it implies that it will not able to
do so even if needed. So this merely goes ahead, is more consistent, that
telling you after 30 min build that it failed to deploy as, well, could not
decrypt password.
Third, the fact you do have non-encryptable passwords in your settings just
nicely shows why Maven3 approach was bad: nobody cared, and your config just
went stale. Keep your settings tidy, and now you can (as Maven3 did not provide
you any other option that to deploy, as you said, to check is pw ok or not).
Moreover, Maven4 now _decrypts whole settings_, so you are free now to put PT
tokents into HTTP headers and so on. Again, whole settings is decrypted, and
you are free to use encrypted strings wherever you want.
This solution is in fact far superior of that done in Maven3 (even if you
neglect the fact that Maven3 merely "obfuscated" and not "encrypted" passwords).
There is no "security risk", unsure why you think there is. In fact, there IS
if you use Maven3 passwords, as the master-master-password (pwd used to encrypt
your master pw) is in plain sight. Just set up yourself properly, the env
variable source is NOT meant for workstations, is for CI uses, gosh. Read on
GPG site about this, as the strategy is pretty much similar.
was (Author: cstamas):
Issue title is right: corrupt passwords will make Maven4 refuse to start.
But the assumptions in description are wrong. For start, on workstation you
should use some tool (pinentry, gpg-agent) that is usually integrated with OS
keychain and just not care about this (just like GPG plugin).
Second, if Maven "cannot decrypt" password, it implies that it will not able to
do so even if needed. So this merely goes ahead, is more consistent, that
telling you after 30 min build that it failed to deploy as, well, could not
decrypt password.
Third, the fact you do have non-encryptable passwords in your settings just
nicely shows why Maven3 approach was bad: nobody cared, and your config just
went stale. Keep your settings tidy, and now you can (as Maven3 did not provide
you any other option that to deploy, as you said, to check is pw ok or not).
Moreover, Maven4 now _decrypts whole settings_, so you are free now to put PT
tokents into HTTP headers and so on. Again, whole settings is decrypted, and
you are free to use encrypted strings wherever you want.
This solution is in fact far superior of that done in Maven3 (even if you
neglect the fact that Maven3 merely "obfuscated" and not "encrypted" passwords).
There is no "security risk", unsure why you think there is. In fact, there IS
if you use Maven3 passwords, as the master-master-password (pwd used to encrypt
your master pw) is in plain sight. Just set up yourself properly.
> New encrypted passwords prevent maven from building projects
> ------------------------------------------------------------
>
> Key: MNG-8417
> URL: https://issues.apache.org/jira/browse/MNG-8417
> Project: Maven
> Issue Type: Bug
> Components: Settings
> Affects Versions: 4.0.0-beta-5, 4.0.0-rc-1
> Reporter: Lenny Primak
> Priority: Blocker
>
> When settings.xml contains new-style encrypted passwords, maven will not
> build unless it can decrypt the password.
> The use case is that the passwords are used only for deployment, while 99% of
> the use cases don't require the passwords.
> This forces the users to have to have secure environment variables or other
> ways to get the master password at all times, enhancing security risks
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
