[guusbeckett]

Authored by Guus H. Beckett.

When a request failed to send (DNS failure, timeout, connection reset, TLS error and so on), HttpHelper.sendRequest threw a RuntimeException whose message contained the complete request body. That body holds the product token, the recipient numbers and the message content (which can include one-time passwords). Anyone able to read the application's logs, crash reports or CI output could therefore recover the product token and personal data.

Changes

• HttpHelper: the exception message now only contains the URL (Error sending request to url: <url>). The original exception is still attached as the cause, so the underlying failure remains visible.
• Add MessagingClientErrorTest, which asserts that neither the product token, the recipient nor the message content appear in the exception message or any of its causes, for both a refused connection and an HTTP 500 response. The tests fail against the previous code.
• Add JUnit 4 as a test dependency, and stop ignoring test failures in the Maven build workflow so that a regression fails the build.
• Update actions/checkout and actions/setup-java in the build and publish workflows. The old setup-java@v2 failed while restoring the Maven cache, so every build job failed before Maven ran.
• Publish to Maven Central through the Central Portal (central-publishing-maven-plugin) instead of the retired OSSRH endpoint. The ossrh Maven profile is replaced by a central profile, and the workflow now needs CENTRAL_TOKEN_USERNAME and CENTRAL_TOKEN_PASSWORD repository secrets (a Central Portal user token). The publish workflow can only be fully tested by creating a release.
• Bump the version to 3.0.1 in pom.xml and the README.md dependency snippet.
• Add a 3.0.1 entry to CHANGELOG.md.

Notes

• Versions 2.0.1, 2.1.0 and 3.0.0 are affected. Users should upgrade to 3.0.1 once released.
• Applications that already logged exceptions from earlier versions should consider rotating their product token if their logs are accessible to others.