[
https://issues.apache.org/jira/browse/BOOKKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370654#comment-15370654
]
Enrico Olivelli commented on BOOKKEEPER-938:
--------------------------------------------
As you told the DigestType parameter it is not a very useful "security"
feature.
IMHO There is no need to add a new ClientConfiguration option, and let the
DigestType be autodiscovered if the user passes a null value to the
asyncOpenLedger/asyncOpenLedgerNoRecovery functions.
Maybe it would be useful to add a new configuration option to tell BookKeeper
to use the DigestType written on metadata and ignore the hint provided by the
user. This option will ease the switch to a different digest type for legacy
code.
> LedgerOpenOp should use digestType from metadata
> ------------------------------------------------
>
> Key: BOOKKEEPER-938
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-938
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client
> Affects Versions: 4.5.0
> Reporter: Andrey Yegorov
> Priority: Minor
>
> Currently digestType verification in LedgerOpenOp seems to be treated as part
> of security logic. Since it is checked after password and error explicitly
> states that digestType mismatched, all that evil hacker has to do is to
> change digest type to another one. There are only two of them after all.
> here is the scenario significantly affected by current behavior:
> 1. user rolls out clients with digestType set to MAC and creates lots of
> ledgers.
> 2. user notices that MAC is slower than CRC32 and decides to change
> digestType.
> 3. more ledgers created with CRC32.
> 4. user tries to read old and new ledgers
> -> now old ledgers cannot be read because of the digest type mismatch.
> I'll send pull request for review.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
