The encryption can be either PKZIP 2.0 (weak) encryption, or
WinZip-compatible AES encryption, which is considered to be strong
and for that reason is preferred.  In the WinZip AES option, there
are two different keystrengths supported: 128 bits and 256 bits.

The extra field, which I mentioned previously, specifies additional
metadata about the entry, which is strictly-speaking,
optional. These data are things like high-resolution timestamps,
data sizes that exceed 2^^32, and other encryption possibilities.
In each case the library that reads a zip file needs to be able to
correctly deal with the various fields, validating the values within
them.

Now, cross all that with the variety of usage patterns - creating a
zip, or reading, or extracting, or updating, or updating several
times. And also, remember that the metadata may change during
updates: an application can apply a password where none was used
previously, or it may wish to remove an entry from the zip entirely.

The huge variety of combinations of possibilities is what makes testing a
zip library so challenging.