This function checks a sequence of tar entries for file name security problems. It checks that:

• file paths are not absolute
• file paths do not contain any path components that are ".."
• file names are valid

These checks are from the perspective of the current OS. That means we check for "C:blah" files on Windows and "/blah" files on Unix. For archive entry types HardLink and SymbolicLink the same checks are done for the link target. A failure in any entry terminates the sequence of entries with an error.

Errors arising from tar file names being in some way invalid or dangerous

This function checks a sequence of tar entries for being a "tar bomb". This means that the tar file does not follow the standard convention that all entries are within a single subdirectory, e.g. a file "foo.tar" would usually have all entries within the "foo/" subdirectory.

Given the expected subdirectory, this function checks all entries are within that subdirectroy.

Note: This check must be used in conjunction with checkSecurity (or checkPortability).

An error that occurs if a tar file is a "tar bomb" that would extract files outside of the intended directory.

This function checks a sequence of tar entries for a number of portability issues. It will complain if:

• The old "Unix V7" or "gnu" formats are used. For maximum portability only the POSIX standard "ustar" format should be used.
• A non-portable entry type is used. Only ordinary files, hard links, symlinks and directories are portable. Device files, pipes and others are not portable between all common operating systems.
• Non-ASCII characters are used in file names. There is no agreed portable convention for Unicode or other extended character sets in file names in tar archives.
• File names that would not be portable to both Unix and Windows. This check includes characters that are valid in both systems and the '/' vs '\' directory separator conventions.

Portability problems in a tar archive

The name of a platform that portability issues arise from