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