squashfs-tools-ng.git, branch v1.0.6

Release version 1.0.6

2021-08-15T20:40:00+00:00

Signed-off-by: David Oberhollenzer

Update CHANGELOG.md

2021-08-15T20:34:31+00:00

Signed-off-by: David Oberhollenzer

Bump coverity scan version

2021-08-15T20:17:23+00:00

Signed-off-by: David Oberhollenzer

Travis-CI: dump test-suite.log if make check fails

2021-08-15T20:17:23+00:00

Gets a little difficult to debug otherwise. Signed-off-by: David Oberhollenzer

Backport documentation changes

2021-08-15T20:17:23+00:00

Signed-off-by: David Oberhollenzer

Fix symlink path traversal in rdsqaushfs

2021-08-14T13:20:05+00:00

If rdsquashfs unpacks a directory tree that contains a symlink, followed by something else with the exact same name, it will follow the symlink and can be tricked into writing to an arbitrary filesystem location controlled by the SquashFS image. Because there might actually be a reasonable use case, where an image is unpacked into an directory existing directory tree, with symlinks that should be followed, this is solved as follows: - Before unpacking, recursively sort the directory by filename. - FAIL if (after sorting) two consequtive entries at the same hierarchy level have the same name. This solution is more generic and prevents the unpacker from accessing the same thing twice in generall, thus also excluding the symlink issue. Hardlinks are already unfolded into duplicate tree nodes by the tree reader (with loop detection) so that should not prompt further issues. Signed-off-by: David Oberhollenzer

Add a test case for the path traversal bug

2021-08-14T13:19:17+00:00

Signed-off-by: David Oberhollenzer

Fix libsquashfs directory writer size accounting

2021-07-21T08:01:39+00:00

The squashfs readdir() implementation in the Linux kernel returns non-existing "." and ".." entries for offsets 0 and 1, and after that reads from disk. For convenience, it was decided to store an off-by-3 value on disk instead of doing complex primary school math to adjust for this. This didn't show up until now, because the kernel implementation trusts the value from the directory header more than the actual size in the inode and happily reads 3 more than the inode would allow it to. This only showed up with 7-zip which subtracts 3 from the size and expects the result to be exact and bails if the directory headers suggest otherwise. And yes, I did consider making a "Holy Hand Granade of Antioch" reference, but consciously decided not to. Signed-off-by: David Oberhollenzer

Add a separate architecture/structure writeup

2021-07-21T08:00:03+00:00

Signed-off-by: David Oberhollenzer

Fix printf format specifiers used for generating tarballs

2021-07-09T18:00:36+00:00

When processing files > 4G, using "%o" truncates the result and the tarball is not readable. This should have been discovered when auto-patching the printf format specifiers, but a cast was added instead and the issue was overlooked. This commit replaces the down-cast and printf format specifiers. Signed-off-by: David Oberhollenzer