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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
