aboutsummaryrefslogtreecommitdiff
path: root/tests
diff options
context:
space:
mode:
authorLasse Collin <lasse.collin@tukaani.org>2008-01-07 18:09:44 +0200
committerLasse Collin <lasse.collin@tukaani.org>2008-01-07 18:09:44 +0200
commit9a71d573100a990ceb30ce0bec6a9a15d795605f (patch)
treee9be2faed8befbeb64a477865c92fa2da811fd9c /tests
parentTell in COPYING that everything in tests/files is (diff)
downloadxz-9a71d573100a990ceb30ce0bec6a9a15d795605f.tar.xz
Added tests/files/README.
Diffstat (limited to 'tests')
-rw-r--r--tests/files/README108
1 files changed, 108 insertions, 0 deletions
diff --git a/tests/files/README b/tests/files/README
new file mode 100644
index 00000000..f2b274c2
--- /dev/null
+++ b/tests/files/README
@@ -0,0 +1,108 @@
+
+.lzma Test Files
+----------------
+
+0. Introduction
+
+ This directory contains bunch of files to test handling of .lzma files
+ in .lzma decoder implementations. Many of the files have been created
+ by hand with a hex editor, thus there is no better "source code" than
+ the files themselves. All the test files (*.lzma) and this README have
+ been put into the public domain.
+
+
+1. File Types
+
+ Good files (good-*.lzma) must decode successfully without requiring
+ a lot of CPU time or RAM. If the decoder supports only Single-Block
+ Streams, then good-multi-*.lzma won't decode, of course.
+
+ Bad files (bad-*.lzma) must cause the decoder to give an error. Like
+ with the good files, these files must not require a lot of CPU time
+ or RAM before they get detected to be broken.
+
+ Malicious files (malicious-*.lzma) are good in terms of the file format
+ specification, but try to trigger excessive CPU, RAM or disk usage in
+ the decoder. To prevent malicious files from putting the decoder in
+ inifinite loop (*), eating all available RAM or disk space, decoders
+ should have internal limitters that catch these situations.
+
+ (*) Strictly speaking not infinite, but if decoding of a small file
+ would take a few weeks or even years, it's an infinite loop in
+ practice.
+
+
+2. Descriptions of Individual Files
+
+2.1. Good Files
+
+ good-single-none.lzma uses implicit Copy filter with known Uncompressed
+ Size.
+
+ good-single-none-pad.lzma is good-single-none.lzma with Footer Padding.
+
+ good-cat-single-none-pad.lzma is two good-single-none-pad.lzma files
+ concatenated as is. Fully decoding this file requires that the decoder
+ supports decoding concatenated files.
+
+ good-single-lzma.lzma is LZMA compressed file with EOPM.
+
+ good-single-subblock-lzma.lzma has basic combination of Subblock and
+ LZMA filters.
+
+ good-single-subblock_rle.lzma takes advantage of Subblock filter's
+ run-length encoding.
+
+ good-single-delta-lzma.tiff.lzma is an image file that compresses
+ better with Delta+LZMA than with plain LZMA.
+
+
+2.2. Bad Files
+
+ bad-single-data_after_eopm.lzma has LZMA+Subblock, where the Subblock
+ filter gives one byte of data to LZMA after LZMA has detected EOPM.
+
+ bad-single-data_after_eopm_2.lzma is like
+ bad-single-data_after_eopm.lzma but Subblock gives 256 MiB of data to
+ LZMA after LZMA has detected EOPM.
+
+ bad-single-subblock_subblock.lzma has Subblock+Subblock, where the
+ Subblock decoder is given End of Input in the middle of a Subblock.
+
+ bad-single-subblock-padding_loop.lzma contains huge amount of
+ consecutive Padding bytes, which isn't allowed by the Subblock filter
+ format. If it were allowed, this file would hang the decoder for very
+ long time (weeks to years).
+
+ bad-single-subblock1023-slow.lzma is similar to
+ malicious-single-subblock31-slow.lzma except that this uses 1023 bytes
+ of Padding in every place instead of 31 bytes. The Subblock filter
+ format specification allows only 31-byte Padings, thus this file must
+ get detected as bad without producing any output. Allowing larger
+ Padding than 31 bytes was considered (so this test file was created),
+ but it seemed to be a bad idea since it would increase worst-case CPU
+ usage.
+
+
+2.3. Malicious Files
+
+ malicious-single-subblock31-slow.lzma requires quite a bit of CPU time
+ per decoded byte. It contains LZMA compressed Subblock filter data that
+ has as much Padding as the specification allows. LZMA is also used as
+ a Subfilter, to further slowdown the decoder. Every Subfilter instance
+ produces only one byte of output. If you can create a file that wastes
+ notably more CPU cycles than this file, please contact Lasse Collin.
+
+ malicious-single-subblock-256MiB.lzma is a tiny file that produces
+ 256 MiB of output. It uses Subblock filter's run-length encoding
+ to achieve this.
+
+ malicious-single-subblock-64PiB.lzma is a tiny file that produces
+ 64 PiB of output (if you have patience to wait). This is done by
+ chaining two Subblock filters and using their run-length encoders.
+
+ malicious-multi-metadata-64PiB.lzma is like
+ malicious-single-subblock-64PiB.lzma but the huge amount of output
+ is in a Metadata Block. Trying to decode this file may take years
+ unless the decoder catches that the Metadata has unreasonable size.
+