[
https://issues.apache.org/jira/browse/TIKA-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139094#comment-18139094
]
ASF GitHub Bot commented on TIKA-5043:
--------------------------------------
tballison commented on PR #3536:
URL: https://github.com/apache/tika/pull/3536#issuecomment-6665363568
Bot nits:
```
1. RAR5 timestamps are shifted by the JVM's time zone (RarParser.java, the
three setLocalTime calls). RAR4 stores times as
DOS local time. RAR5 stores true UTC instants (Unix or Windows
FILETIME; see Rar5FileHeaderReader.readTime). The parser
converts every Date to wall-clock time in the default zone and writes
it without a zone. So a RAR5 entry's MODIFIED
value depends on the server's zone and is wrong as UTC. Its comment
"RAR4 times are DOS local time" is now only
half-true.
- Fix: branch on rar.getFormat() == RarFormat.RAR50 and set the instant
as a UTC date in that case.
- Test: add an mtime to the synthetic archive and assert the result
under a non-UTC default zone.
2. The dictionary size is uncapped (new Archive(tis.getFile())). junrar's
default maxDictionarySize is 4 GiB. Its RAR5
window is allocated lazily but grows as bytes are decompressed. A
small, highly compressible RAR5 that declares a large
dictionary can therefore grow heap use up to min(4 GiB, output) inside
one entry. RAR4 dictionaries topped out at 4 MB,
so this exposure is new with this PR.
- Under Tika's security model this is DoS and not a vulnerability.
- Still, it costs one line: new Archive(file,
ArchiveOptions.builder().maxDictionarySize(...).build()). 256 MB to 1 GB
covers what WinRAR 5/6 produce. Choosing the cap, or making it
configurable, is a maintainer decision.
```
> RarParser refuses RAR5 archives although junrar 8 reads them
> ------------------------------------------------------------
>
> Key: TIKA-5043
> URL: https://issues.apache.org/jira/browse/TIKA-5043
> Project: Tika
> Issue Type: Bug
> Components: parser
> Reporter: Dominik Schmidt
> Priority: Major
>
> RarParser throws {{UnsupportedFormatException("Tika does not yet support rar
> version 5.")}} for any {{application/x-rar-compressed; version=5}} before
> junrar sees the file. junrar has read RAR5 (and RAR7) since 8.0.0 (junrar PR
> #289), and Tika depends on junrar 8.1.2.
> Checked with a real RAR5 archive (a 50-page comic book archive from
> archive.org): {{/rmeta}} answers with the exception and no entries, while
> junrar 8.1.2 called directly lists all 50 entries and extracts them. A RAR4
> archive works either way.
> Removing the version check should be enough; tests with a RAR5 fixture would
> show it. Related: TIKA-3211, whose premise (junrar has no RAR5) no longer
> holds.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
