slachiewicz opened a new issue, #12811: URL: https://github.com/apache/maven/issues/12811
`org.codehaus.plexus:plexus-cipher` 2.1.0 changes the key derivation function that `PBECipher` uses to encrypt and decrypt master passwords and server credentials, and ciphertext produced by one version cannot be decrypted by the other. #12786 bumps `maven-3.9.x` from `plexus-cipher` 2.0 to 2.1.0 and fails `MavenITmng0553SettingsAuthzEncryptionTest.testitEncryption` with `javax.crypto.BadPaddingException: Given final block not properly padded` in `PBECipher.decrypt64`. This issue is to decide how the project wants to handle that break, separately from the bump PR itself. ## Background Version 2.0 derives its key with an OpenSSL `EVP_BytesToKey`-style `SHA-256(password || salt)` chain. Version 2.1.0, from [codehaus-plexus/plexus-cipher#23](https://github.com/codehaus-plexus/plexus-cipher/pull/23) ("Fixed insecure cryptography in PBECipher.java", merged 2023-04-22), switches to `PBEKeySpec(password, salt, 310000, 256)` with `PBKDF2WithHmacSHA1`. The two key derivation functions are incompatible, so ciphertext encrypted under one can never decrypt under the other. The upstream PR description states this in bold: "This fix is not backwards compatible and will cause people using Plexus Cipher to have to re-encrypt their information." A [2023-04-10 comment on that PR](https://github.com/codehaus-plexus/plexus-cipher/pull/23#issuecomment-1501580887) already pointed at `MavenCli.java#L848` as a place this would surface. ## Why this is more than a failing test `MavenCli.encryption()` decrypts the existing `<master>` password from `settings-security.xml` before it can encrypt anything new, and the same `DefaultSecDispatcher` path decrypts server passwords from `settings.xml` during ordinary builds. A user who upgrades a maintenance line onto `plexus-cipher` 2.1.0 finds their existing master password and every encrypted server password stop decrypting, with no migration path and no clear error pointing at the cause. ## Current status by branch - `maven-3.9.x` and `maven-3.10.x` depend directly on `org.codehaus.plexus:plexus-cipher` 2.0 (the `cipherVersion` property) alongside `plexus-sec-dispatcher` 2.0. Both maintenance lines are exposed to this break if bumped. - `master` and `maven-4.0.x` no longer depend on `plexus-cipher` at all. They use `org.codehaus.plexus:plexus-sec-dispatcher` 4.1.0 and 4.2.0 respectively, and an enforcer rule bans the older `org.sonatype.plexus:plexus-cipher` and `org.sonatype.plexus:plexus-sec-dispatcher` coordinates from returning. Maven 4 is not directly affected by this specific dependency bump. Whatever key derivation `plexus-sec-dispatcher` 4.x uses internally is a separate question from this issue. ## Options 1. Stay on `plexus-cipher` 2.0 on `maven-3.9.x` and `maven-3.10.x` and don't take the fix. 2. Take 2.1.0 and add a detection path that recognizes ciphertext produced by the old key derivation function and fails with a clear, actionable error instead of a raw `BadPaddingException`. 3. Take 2.1.0 together with migration guidance or tooling that re-encrypts existing `settings-security.xml` and `settings.xml` entries. Maintainers: which of these, or another option, should the project pursue for the maintenance lines? *This issue 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]
