[
https://issues.apache.org/jira/browse/BOOKKEEPER-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371167#comment-15371167
]
Andrey Yegorov commented on BOOKKEEPER-938:
-------------------------------------------
[~eolivelli] Thank you for the code review.
I thought about passing null or something similar, but it still requires change
in the LedgerOpenOp + making sure null won't cause problems on the way
(logging? default config params?) + client side configuration that enables this
behavior (digestType config currently used for both create and open ledger). So
I figured this way touches fewer things and does the same thing.
Regarding bookkeeper - can it really create a ledger with different digest
types for different entries in it? If this is the case I'd consider this a bug,
different from this one, though logically related.
> 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)
