[I] [Bug]: REST transform does not decrypt trustStorePassword, unlike every other password field (hop)

["fskorgen (via GitHub)" <gi...@apache.org>]

fskorgen opened a new issue, #8054:
URL: https://github.com/apache/hop/issues/8054

   ### Apache Hop version?
   
   2.19
   
   ### Java version?
   
   21
   
   ### Operating system
   
   Windows
   
   ### What happened?
   
   The REST transform reads its trust store password with `resolve()` only, without
   `Encr.decryptPasswordOptionallyEncrypted(...)`. Every other password field in Hop — including the
   one a dozen lines above it in the very same method — is decrypted after resolving. As a result an
   encrypted value that reaches the field through a variable is passed to the trust store loader
   verbatim, and the SSL context cannot be built.
   
   ### Where
   
   `plugins/transforms/rest/src/main/java/org/apache/hop/pipeline/transforms/rest/Rest.java`, in
   `init()` (2.19.0-rc1, lines 2243-2257):
   
   ```java
   data.realHttpLogin = resolve(meta.getHttpLogin());
   data.realHttpPassword =
       Encr.decryptPasswordOptionallyEncrypted(resolve(meta.getHttpPassword()));   // decrypted
   ...
   data.trustStoreFile = resolve(meta.getTrustStoreFile());
   data.trustStorePassword = resolve(meta.getTrustStorePassword());                // not decrypted
   ```
   
   Both fields are declared the same way in `RestMeta`:
   
   ```java
   @HopMetadataProperty(key = "httpPassword", injectionKey = "HTTP_PASSWORD", password = true)
   private String httpPassword;
   
   @HopMetadataProperty(key = "trustStorePassword", injectionKey = "TRUSTSTORE_PASSWORD", password = true)
   private String trustStorePassword;
   ```
   
   Everywhere else in Hop, a trust store password is decrypted before use:
   
   | Location | Handling |
   | --- | --- |
   | `plugins/misc/rest/.../metadata/rest/RestConnection.java:566` (same field name, REST connection) | `Encr.decryptPasswordOptionallyEncrypted(resolve(trustStorePassword))` |
   | `plugins/databases/oracle/.../OracleDatabaseMeta.java:561` | `decrypt(variables, trustStorePassword)` |
   | `plugins/transforms/ldap/.../LdapSslProtocol.java:41` | `Utils.resolvePassword(variables, ...)`, i.e. resolve + decrypt |
   | `plugins/transforms/rest/.../Rest.java:2257` | `resolve(...)` only |
   
   ### Why it is not visible in the simple case
   
   A password typed straight into the dialog works, because `XmlMetadataUtil` already decrypts
   `password = true` properties when the pipeline is deserialized
   (`core/src/main/java/org/apache/hop/metadata/serializer/xml/XmlMetadataUtil.java:1211`). The
   failure needs the value to arrive *after* deserialization: through a variable, or through metadata
   injection.
   
   ### Steps to reproduce
   
   1. Encrypt a trust store password: `hop-encrypt.sh -hop mypassword` → `Encrypted 2be98afc86aa7f2e4bb18bd63c99dbdde`
   2. Put that string in a variable, for example `REST_TRUSTSTORE_PW`, in `hop-config.json` or the
      project variables — the documented way to keep a secret out of plain text.
   3. In a REST transform, set an HTTPS URL that needs a custom trust store, set **Trust store file**,
      and set **Trust store password** to `${REST_TRUSTSTORE_PW}`.
   4. Run the pipeline.
   
   ### Expected behaviour
   
   The variable resolves to the encrypted string, the string is decrypted, and the trust store opens —
   exactly what happens when the same construct is used for **HTTP password**.
   
   ### Actual behaviour
   
   The literal text `Encrypted 2be98afc86aa7f2e4bb18bd63c99dbdde` is passed as the trust store
   password. `trustStoreSslContext()` fails with `Rest.Error.IOException`, caused by
   `java.io.IOException: keystore password was incorrect`.
   
   The same applies to metadata injection into `TRUSTSTORE_PASSWORD`.
   
   ### Suggested fix
   
   One line, matching the sibling field directly above it:
   
   ```java
   data.trustStorePassword =
       Encr.decryptPasswordOptionallyEncrypted(resolve(meta.getTrustStorePassword()));
   ```
   
   `decryptPasswordOptionallyEncrypted` is a no-op for a value that is not encrypted, so plain-text
   passwords keep working unchanged.
   
   ### Note
   
   This is long-standing, not a regression — the line has not changed since a code-formatting commit
   in 2021. Happy to open a PR if the fix above is acceptable.
   
   ### Issue Priority
   
   Priority: 2
   
   ### Issue Component
   
   Component: Transforms


-- 
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: issues-unsubscribe@hop.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Bug]: REST transform does not decrypt trustStorePassword, unlike every other password field (hop)

["hansva (via GitHub)" <gi...@apache.org>]

hansva closed issue #8054: [Bug]: REST transform does not decrypt trustStorePassword, unlike every other password field
URL: https://github.com/apache/hop/issues/8054


-- 
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: issues-unsubscribe@hop.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] [Bug]: REST transform does not decrypt trustStorePassword, unlike every other password field (hop)

["hansva (via GitHub)" <gi...@apache.org>]

hansva commented on issue #8054:
URL: https://github.com/apache/hop/issues/8054#issuecomment-5370918563

   Feel free to open a PR. This is indeed a bug; you can claim tickets by using the [.]take-issue command (without []).


-- 
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: issues-unsubscribe@hop.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org