Addendum 2: Maven 4 adds new CLI tool mvnenc, and it's sole purpose is to help you set up, check, encrypt and decrypt/check passwords (Maven 3 was never offering this, to check passwords all you could is to perform operation decrypting them, like deploying).
And yes, IF you use (unsecure) Maven 3 "encrypted passwords", Maven 4 will mercilessly nag you about them. On Wed, Jan 1, 2025 at 4:21 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > Addendum: > 1. Yes, the API is a bit clumsy, as it was always meant to decrypt > Settings bits (Servers, proxies...) so even my PR does a "hack" by > creating a Server entry on the fly to decrypt a password. Still, this > is the "official" password decrypt API since Maven 3.0, not the > SecDispatcher direct use. Moreover, people started circumventing (like > here, using reflection, or even sticking to workaround as explained in > https://issues.apache.org/jira/browse/MNG-4384). Anyway, SecDispatcher > was not meant for direct consumption in Maven3 and beyond. > > 2. Alternative fix for "password decryption" that PR would be simply > detecting is "runtime Maven 4", as in that case, as explained in blog > above, _whole settings.xml is decrypted early on Maven boot_. Hence, > no encryption needed at all for anything that comes from effective > settings (decrypt method should be just no-op). Maven 4 sets security > boundary aligned to Maven security model > https://maven.apache.org/security.html while Maven 3 had some awkward > idea to "protect sensitive data" from possibly "rogue plugins", but > this was more "security through obscurity" as explained in blog: > nothing prevented rogue plugin to decrypt them anyway. > > On Wed, Jan 1, 2025 at 4:04 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > > > Howdy Mirko, > > > > Yes, SecDispatcher 1.x/2.x had a TON of issues, and received another > > TON of improvements in Maven 4 :) > > Some of changes are explained here: > > https://cstamas.org/blog/2024/09/handling-sensitive-data-in-maven/ > > > > The problem of this plugin, and sadly many other plugins, was that > > they opted for direct use of SecDispatcher that was never meant to be > > exposed in Maven 3 > > The official API was always this (introduced along with SecDispatcher > > core library): > > https://github.com/apache/maven/tree/629fd749e59a679809c86eb26d554520e4de3a78/maven-settings-builder/src/main/java/org/apache/maven/settings/crypto > > > > As explained above, Maven 4 fixes many if not all the Maven 3 password > > encryption issues, and still provides "backward" compatibility for > > Maven 3 plugins. > > So that api mentioned above should work with Maven4, while direct use > > of SecDispatcher will not work anymore. > > > > Simplest fix (as SecDispatcher went from 2.x to 4.x and is not > > compatible) is to not use it directly (as was the original intention): > > https://github.com/fabric8io/docker-maven-plugin/pull/1848 > > > > HTH > > Tamas > > > > On Tue, Dec 31, 2024 at 5:25 PM Mirko Friedenhagen > > <mfriedenha...@gmx.de.invalid> wrote: > > > > > > Hi, > > > > > > I see that SecDispatcher now stems from another location, unfortunately > > > this breaks fabric8io’s docker-maven-plugin. I have a small reproducer > > > here: > > > > > > https://github.com/fabric8io/docker-maven-plugin/issues/1845 > > > > > > I would appreciate any hints how to fix this. > > > > > > > > > Mit freundlichen Grüßen > > > Mirko Friedenhagen > > > — > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
