[improve][client] Use SHA-256 for generated reader subscription names#26153
Merged
david-streamlio merged 2 commits intoJul 9, 2026
Merged
Conversation
The auto-generated reader subscription name hashed a random UUID with SHA-1. The hash is not a security control, but SHA-1 is rejected by strict security providers (e.g. BC-FIPS in approved-only mode), which would make readers without an explicit subscription name fail on FIPS-configured JVMs. The generated names are ephemeral and never persisted, so the change is not observable across versions.
david-streamlio
force-pushed
the
fips-qw-reader-subscription-hash
branch
from
July 6, 2026 17:16
adbcd25 to
5409f5d
Compare
This was referenced Jul 6, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves Pulsar client compatibility with FIPS-restricted JVMs by removing SHA-1 usage from autogenerated reader subscription names, which can fail under strict security providers.
Changes:
- Switch
ReaderImplautogenerated subscription name hashing from SHA-1 to SHA-256. - Switch
MultiTopicsReaderImplautogenerated subscription name hashing from SHA-1 to SHA-256 (keeping the same prefix + 10-hex-char shape).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| pulsar-client/src/main/java/org/apache/pulsar/client/impl/ReaderImpl.java | Replace DigestUtils.sha1Hex(...) with DigestUtils.sha256Hex(...) for generated reader subscription names. |
| pulsar-client/src/main/java/org/apache/pulsar/client/impl/MultiTopicsReaderImpl.java | Replace DigestUtils.sha1Hex(...) with DigestUtils.sha256Hex(...) for generated multi-topic reader subscription names. |
merlimat
approved these changes
Jul 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
When a reader is created without an explicit subscription name,
ReaderImpl/MultiTopicsReaderImplgenerate one by hashing a random UUID with SHA-1 (DigestUtils.sha1Hex). The hash is not a security control — it just produces a short random identifier — but strict security providers reject SHA-1: under BC-FIPS in approved-only mode the call throws, so creating a reader without a subscription name fails on FIPS-configured JVMs.This is one of a set of small preparatory cleanups for FIPS-restricted deployments; a broader PIP is being drafted separately.
Modifications
Replaced
DigestUtils.sha1Hex(...)withDigestUtils.sha256Hex(...)in the generated-subscription-name paths ofReaderImplandMultiTopicsReaderImpl. The generated names keep the same shape (reader-/multiTopicsReader-prefix + 10 hex chars) and entropy (40 bits of a hash over a random UUID). The names are ephemeral, used for non-durable subscriptions, and never persisted, so nothing is observable across versions.Verifying this change
This change is a trivial rework / code cleanup without any test coverage. (Existing reader tests, e.g.
ReaderImplTest, exercise the generated-name path.)Does this pull request potentially affect one of the following parts: