Package: squashfs-tools / 1:4.3-12

Metadata

Package Version Patches format
squashfs-tools 1:4.3-12 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
0001 kfreebsd.patch | (download)

squashfs-tools/gzip_wrapper.h | 2 1 + 1 - 0 !
squashfs-tools/lz4_wrapper.h | 2 1 + 1 - 0 !
squashfs-tools/lzo_wrapper.h | 2 1 + 1 - 0 !
squashfs-tools/mksquashfs.c | 4 2 + 2 - 0 !
squashfs-tools/read_fs.c | 2 1 + 1 - 0 !
squashfs-tools/read_xattrs.c | 2 1 + 1 - 0 !
squashfs-tools/swap.c | 2 1 + 1 - 0 !
squashfs-tools/unsquashfs.c | 2 1 + 1 - 0 !
squashfs-tools/unsquashfs.h | 2 1 + 1 - 0 !
squashfs-tools/xz_wrapper.h | 2 1 + 1 - 0 !
10 files changed, 11 insertions(+), 11 deletions(-)

 fixes ftbfs on kfreebsd (closes: #557174).
0002 fix_phys_mem_calculation.patch | (download)

squashfs-tools/mksquashfs.c | 78 70 + 8 - 0 !
1 file changed, 70 insertions(+), 8 deletions(-)

 [patch] mksquashfs: fix phys mem calculation for 32-bit processes on
 PAE/64-bit kernels

When adding the code to base default memory usage on physical memory
(by default use 25% of physical memory), I made an oversight.  I assumed
the process would be able to address 25% of physical memory.

However, for 32-bit processes running on a PAE kernel or 64-bit kernel,
25% of physical memory can easily exceed the addressible memory for a
32-bit process, e.g. if a machine has 24 GB of physical memory, the
code would asume the process could easily use 6 GB.

A 32-bit process by definition can only address 4 GB (32-bit pointers).
But, due to the typical kernel/user-space split (1GB/3GB, or 2GB/2GB)
on PAE kernels, a 32-bit process may only be able to address 2 GB.

So, if Mksquashfs is a 32-bit application running on a PAE/64-bit kernel,
the code assumes it can address much more memory than it really can, which
means it runs out of memory.

The fix is to impose a maximum default limit on 32-bit kernels, or
otherwise to never use a value more than 25% of the address space.  If
we assume the maximum address space is 2 GB, then the maximum becomes
512 MB.  But, given most kernels used the 1GB/3GB split, that may be
unduely conservative, and 25% of 3 GB (756 MB) may be better.  This
patch compromises on 640 MB, which is mid-way between the 512 MB and 756 MB
values.  It is also the fixed default value previously used by Mksquashfs.

This patch also alters the code which imposes a maximum size.  Previously
it was believed limiting to the physical memory size was adequate.  But
obviously this needs to be updated to take into account a 32-bit process
may only be able to address 2 GB.  In the process I've also taken the
opportunity to limit all requests to no more than 75% of physical memory.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>

0003 CVE 2015 4645_and_CVE 2015 4646.patch | (download)

squashfs-tools/unsquash-4.c | 11 8 + 3 - 0 !
1 file changed, 8 insertions(+), 3 deletions(-)

 [patch] update unsquash-4.c

0004 unsquashfs add support for LZMA magics.patch | (download)

squashfs-tools/squashfs_fs.h | 6 6 + 0 - 0 !
squashfs-tools/unsquashfs.c | 24 18 + 6 - 0 !
2 files changed, 24 insertions(+), 6 deletions(-)

 [patch] unsquashfs: add support for lzma magics
X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\2t5)({*|jhM<pyWR#k60!#=#>/Vb;]yA5<GWI5`6u&+
 ;6b'@y|8w"wB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7<j&N3ah(m`ku?pX.&+~:_/wC~dwn^)MizBG
 !pE^+iDQQ1yC6^,)YDKkxDd!T>\I~93>J<_`<4)A{':UrE

0005 add fstime.patch | (download)

squashfs-tools/mksquashfs.c | 45 44 + 1 - 0 !
squashfs-tools/unsquashfs.c | 28 27 + 1 - 0 !
2 files changed, 71 insertions(+), 2 deletions(-)

 add -fstime to unsquashfs to extract the fs superblock information
 and -fstime to mksquashfs to set the fs superblock time on create. This is
 needed to support Ubuntu Store unpack and repack checks.
0006 uptream fix race.patch | (download)

squashfs-tools/mksquashfs.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
0007 fix 2GB limit in mksquashfs.patch | (download)

squashfs-tools/mksquashfs.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] fix 2gb-limit of the is_fragment(...) function.

Applies to squashfs-tools 4.3.

Reported-by: Bruno Wolff III <bruno@wolff.to>
Signed-off-by: Guan, Xin <guanx.bac@gmail.com>
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>

0008 preserve_file_capabilities.patch | (download)

squashfs-tools/unsquashfs.c | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

 [patch] unsquashfs: correctly set file capabilities

As posted on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804194.

0009 unsquashfs preserve symlink times.patch | (download)

squashfs-tools/unsquashfs.c | 15 14 + 1 - 0 !
1 file changed, 14 insertions(+), 1 deletion(-)

 [patch] unsquashfs: preserve times on symlink inodes

This patch fixes a bug that caused symlinks created by unsquashfs to
use the current time for atime and mtime rather than the times present
in the squashfs archive.

The timestamps are set using utimensat(2) which does not dereference the
symlink when the AT_SYMLINK_NOFOLLOW flag is used. The utimensat(2)
system call supports nanosecond precision but that's not needed by
squashfs so timespec.tv_nsec is unconditionally set to 0.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Bug-Ubuntu: https://launchpad.net/bugs/1724152
0010 fix_FTBFS_with_glibc_2.28.patch | (download)

squashfs-tools/mksquashfs.c | 49 25 + 24 - 0 !
squashfs-tools/unsquashfs.c | 1 1 + 0 - 0 !
2 files changed, 26 insertions(+), 24 deletions(-)

 fix ftbfs with glibc 2.28
 .
0011 If SOURCE_DATE_EPOCH is set use that timestamp for that timestamp.patch | (download)

squashfs-tools/mksquashfs.c | 33 33 + 0 - 0 !
1 file changed, 33 insertions(+)

 if source_date_epoch is set, use that timestamp for the mkfs time.

See https://reproducible-builds.org/specs/source-date-epoch/ for more
information about this environment variable.

Based on a patch by Alexander Couzens <lynxis@fe...> posted on
https://sourceforge.net/p/squashfs/mailman/message/34673610/

0012 If SOURCE_DATE_EPOCH is set also clamp content times.patch | (download)

squashfs-tools/mksquashfs.c | 13 10 + 3 - 0 !
1 file changed, 10 insertions(+), 3 deletions(-)

 if source_date_epoch is set,
 also clamp content timestamps with that value.

Based on a patch by Alexander Couzens <lynxis@fe...> posted on
https://sourceforge.net/p/squashfs/mailman/message/34673610/

Updated by Chris Lamb <lamby@debian.org> to use (time_t)0 as a
sentinel value over -1.

0013 use macros not raw octal with chmod.patch | (download)

squashfs-tools/unsquashfs.c | 6 4 + 2 - 0 !
1 file changed, 4 insertions(+), 2 deletions(-)

 using macros, rather than raw octal values, better conveys the
 intent of masking off the setuid, setgid, and sticky bits.
0014 also set stickybit as non root.patch | (download)

squashfs-tools/unsquashfs.c | 17 13 + 4 - 0 !
1 file changed, 13 insertions(+), 4 deletions(-)

 [patch 0/2] preserve the sticky bit

The unsquashfs tool was masking off the sticky bit when running as a
non-root user. It isn't documented why the bit was being masked off but
there are at least two possibilities.

The first is because all of the files created by unsquashfs, when
running as a non-root user, will be owned by the same user since
unsquashfs can't chown() the files.I think it is still good practice to
attempt to preserve the sticky bit in this situation because it is
perfectly valid to have a world-writable directory containing files
owned by a single user. The sticky bit set on the directory inode would
prevent other users from deleting those files.

Another reason why the sticky bit was being masked off when running as
non-root could be due to this snippet from the chmod(2) man page:

  On some filesystems, only the superuser can set the sticky bit, which
  may have a special meaning. For the sticky bit, and for set-user-ID
  and set-group-ID bits on directories, see stat(2).

However, I'm not seeing any Linux filesystems that require root
privileges in order to set the sticky bit after a quick search through
v4.17. In the case that such filesystems do exist, old behavior is
preserved by retrying a failed chmod() without the sticky bit.

Setting the sticky bit, when non-root, will not cause any problems in
unsquashfs because all of the created files will by owned by the same
user. Therefore, unsquashfs will not run into any of the restricted
deletion protections after setting the sticky bit on a directory inode
even if unsquashfs needs to remove or rename a file underneath the
directory.

Signed-off-by: Tyler Hicks <tyhicks@...>

0015 numeric uid gid_to_unsquashfs.patch | (download)

squashfs-tools/unsquashfs.c | 24 17 + 7 - 0 !
1 file changed, 17 insertions(+), 7 deletions(-)

---
0016 remove frag_deflator_thread.patch | (download)

squashfs-tools/info.c | 5 0 + 5 - 0 !
squashfs-tools/mksquashfs.c | 71 27 + 44 - 0 !
squashfs-tools/mksquashfs.h | 2 1 + 1 - 0 !
squashfs-tools/restore.c | 15 2 + 13 - 0 !
4 files changed, 30 insertions(+), 63 deletions(-)

 remove frag_deflator_thread

frag_deflator_thread compress fragments.
Replace the deflator_thread with a function and
use the function instead of the to_frag queue.

Updated Fri, 18 Jan 2019 19:22:58 +0000 by Chris Lamb <lamby@debian.org> to
fix issue with lack of compressor initialisation affecting (at least) LZO
compression.

0017 add zstd support.patch | (download)

squashfs-tools/Makefile | 20 20 + 0 - 0 !
squashfs-tools/compressor.c | 8 8 + 0 - 0 !
squashfs-tools/squashfs_fs.h | 1 1 + 0 - 0 !
squashfs-tools/zstd_wrapper.c | 254 254 + 0 - 0 !
squashfs-tools/zstd_wrapper.h | 48 48 + 0 - 0 !
5 files changed, 331 insertions(+)

 [patch] squashfs-tools: add zstd support

This patch adds zstd support to squashfs-tools. It works with zstd
versions >= 1.0.0. It was originally written by Sean Purcell.

Signed-off-by: Sean Purcell <me@seanp.xyz>
Signed-off-by: Nick Terrell <terrelln@fb.com>

0018 mksquashfs fix compressor initialisation in frag_def.patch | (download)

squashfs-tools/mksquashfs.c | 19 12 + 7 - 0 !
1 file changed, 12 insertions(+), 7 deletions(-)

---