[ 
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:11 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.


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

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

Reply via email to