[
https://issues.apache.org/jira/browse/TIKA-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095832#comment-18095832
]
ASF GitHub Bot commented on TIKA-4783:
--------------------------------------
rootvector2 commented on PR #2942:
URL: https://github.com/apache/tika/pull/2942#issuecomment-4956254355
looks right to me. the `(long)` cast on the top byte closes the gap #2887
left: masking fixed per-byte sign extension, but the `<< 24` still ran in int
arithmetic, so a uint32 >= 2^31 went negative on the widen to `dest`. the
encint fix checks out too, the old inline decoder compared a signed byte to
`0x80`, which is never true, so it always stopped after one byte.
one small note: now that `unmarshalUInt32` can't return negative, the
`getBlockCount() < 0` fallback in `enumerateBlockAddresses` is dead code, and
an all-`0xff` block count (the old `-1` sentinel that `TestParameters`
documented) takes the 5000 cap with a zero-padded tail instead of deriving the
count from the remaining data. might be worth an `== 0xFFFFFFFFL` check to keep
that path, though the `Math.min(count, rem)` guard means nothing unsafe happens
either way.
> Further harden chm parsing
> --------------------------
>
> Key: TIKA-4783
> URL: https://issues.apache.org/jira/browse/TIKA-4783
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Minor
>
> I reviewed chm a bit more based on
> [https://github.com/apache/tika/pull/2887,] and there are a number of other
> improvements we should make.
> copilot was helpful in recommending some of those. I think we should take
> copilot's recommendations and open a separate more holistic ticket for
> hardening chm parsing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
