Added tests/files/README.

1 files changed, 108 insertions, 0 deletions

diff --git a/tests/files/README b/tests/files/README
new file mode 100644
index 0000000..f2b274c
--- /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.
+