gnodet commented on issue #12811: URL: https://github.com/apache/maven/issues/12811#issuecomment-5443091750
### Recommendation: Stay on 2.0, document the limitation After reviewing the actual `PBECipher` source in plexus-cipher 2.0, the cryptographic weakness is real and significant: - The key derivation is a **single SHA-256 hash** of `password || salt` — the `PBE_ITERATIONS = 1000` constant is defined but **never used** in the code - There is no authenticated encryption (AES/CBC without HMAC) - Key and IV are derived from the same hash output A GPU-based attacker with access to the ciphertext can brute-force typical passwords in seconds to minutes. The encryption is effectively obfuscation, not security. That said, **Option 1 (stay on 2.0) is the right call for the maintenance branches**, for these reasons: 1. **Breaking change on a patch release is worse than the weakness.** Users upgrading from 3.9.15 to 3.9.17 don't expect their builds to break because `settings.xml` passwords stopped decrypting. The semver contract of a maintenance line is stability. 2. **The threat model hasn't changed.** This weakness has existed since plexus-cipher's inception. Anyone who has relied on this encryption for real credential security has been exposed all along — a bump in a maintenance release doesn't change their actual risk posture. 3. **Detection is unreliable (Option 2 is harder than it looks).** A `BadPaddingException` from the wrong KDF is indistinguishable from a wrong password or corrupted ciphertext. There is no format version marker in the ciphertext that would let the decrypt path say "this is old-format, please re-encrypt" vs "your password is wrong." Building this detection in Maven's `SecDispatcher` layer would require shipping a copy of the old KDF alongside the new one — at which point you are implementing Option 3. 4. **Migration tooling (Option 3) is disproportionate effort.** Maven 4 has already moved to `plexus-sec-dispatcher` 4.x with a different encryption architecture. Investing in re-encryption tooling for 3.9.x / 3.10.x adds maintenance burden to branches that are winding down while 4.0.0 is in RC. 5. **Maven 4 is the real fix.** With RC-6 already out, the migration path for users who care about credential encryption strength is Maven 4, not a retrofitted KDF swap on 3.9.x. ### What I would suggest instead - **Close PR #12786** (already done) and keep `plexus-cipher` at 2.0 on both `maven-3.9.x` and `maven-3.10.x`. - **Add a documentation note** making it explicit that `settings.xml` password encryption in Maven 3.x provides obfuscation (prevents casual exposure in logs, screen-sharing, etc.) but is **not** a substitute for proper secrets management. Recommend file permissions (`chmod 600`), CI/CD secrets vaults, or Maven 4 for users with stronger requirements. - **Consider a console warning** (low-effort): when `MavenCli.encryption()` runs on 3.9.x, print a one-line notice that the encryption scheme provides limited protection and point to the documentation. No code-level crypto changes needed. *This comment was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
