Bug#1050604: python3-binwalk: Fails to extract cramfs

[Shorrer]

Package: python3-binwalk
Version: 2.3.4+dfsg1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: sho...@yandex.by

Dear Maintainer,

While trying to unpack everything from a blob that contains a cramfs
using the "binwalk -e blob_name.bin" I've encountered an error:

WARNING: Extractor.execute failed to run external extractor 'cramfsck -x 'cramfs-root' '%e'': [Errno 2] No such file or directory: 'cramfsck', 'cramfsck -x 'cramfs-root' '%e'' might not be installed correctly

Sure enough, there truly is no "cramfsck" executable, neither in /usr/bin
nor in /usr/sbin. I've found it in "cramfs-tools" repository
(https://github.com/npitre/cramfs-tools/blob/master/cramfsck.c) but
there is no such package in Debian. There is an "fsck.cramfs" from the
"util-linux" package that is doing what "cramfsck" is, albeit with
a different arguments: "-x" is "--extract" in "fsck.cramfs".

The bug was reported upstream some time ago
(https://github.com/ReFirmLabs/binwalk/issues/623) with not much
attention (and latest commit in the repository was around 7 months ago).
Issue is also present with two other Linux distributions: Arch Linux
(tested by myself right now) and it's derivative Manjaro (encountered by
at least one user 2.5 years ago
https://forum.manjaro.org/t/how-to-install-cramfsswap/48970)

While so far it seems that this is the problem of the upstream to adapt
to distributions using "util-linux"'s "fsck.cramfs" instead of
"cramfsck" the issue is also in the fact that "fsck.cramfs" is in
/usr/sbin, which is not in the PATH of non-root users on Debian by
default. As I don't think anyone would try to install a whole another
package for functionality that is present in "util-linux" and neither
it is possible to just symlink "cramfsck" to "fsck.cramfs" due to
argument incompatibility, the only probable way of this is to patch
"binwalk" to try "fsck.cramfs" and maybe symlink "fsck.cramfs" to
/usr/bin for non-root users to see.

However, of course, maybe you can see a better resolution of this. I
will try to figure out some way of patching the "binwalk" for the new
utility in the meantime, if nobody beats me to it.

-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-binwalk depends on:
ii libmagic1 1:5.44-3
ii python3 3.11.2-1+b1

Versions of packages python3-binwalk recommends:
ii arj 3.10.22-26
ii bzip2 1.0.8-5+b1
ii cramfsswap 1.4.2
ii mtd-utils 1:2.1.5-1
ii ncompress 4.2.4.6-6
ii p7zip 16.02+dfsg-8
ii p7zip-full 16.02+dfsg-8
ii python3-pyqtgraph 0.13.1-4
ii sleuthkit 4.11.1+dfsg-1+b1
ii squashfs-tools 1:4.5.1-1

python3-binwalk suggests no packages.

-- no debconf information

[Shorrer]

I've looked a bit into it and found some interesting things.

First, there is an upstream (as I've understood) "deps.sh" file, which
pulls "cramfs-tools" and installs "cramfsck" as well as "mkcramfs"
(haven't found mentions of mkcramfs being used anywhere).
I'm not understanding the Debian's package system at all, but at least
in the package's source repo that I've checked out there is no mention
of "deps.sh" anywhere else except the "Dockerfile" that is also provided
by upstream.

I've attached a patch. It is not to be forwarded upstream as it really
is a fix for how the package is in Debian repository. I could've added
those lines so that binwalk would try to use one tool and then the
other, spamming the console with warnings as it goes, but it does not
seem like a good approach to me.

Please note that there is a difference in how fsck.cramfs extracts
the file compared to cramfsck: cramfsck keeps all symlinks as they are
while fsck.cramfs replaces symlinks that point out of extraction dir to
point to /dev/null.

If you want to go down "fsck.cramfs" route then it is also required to
deal with it not being available in /usr/bin as well as adding
dependency to util-linux. I'm sorry but I've experienced enough of
package buildsystem for today so I hope that someone who knows it better
could do it. Modifying "debian/control" file just didn't work for
whatever reason. I will also note that in case of failure the "clean"
target at "dpkg-buildpackage" does not clean the leftover "__pycache__"
directories as well as:
- testing/tests/.coverage
- testing/tests/.config/
- src/binwalk.egg-info/
which results in errors while trying to rebuild package once more, but
it is very likely that I'm just using wrong tools for the job.

Maybe a better approach would be to actually do what "deps.sh" file
wants to do -- download the cramfs-tools and compile cramfsck. It's a
small binary after all, which does exactly what the original author
intended (bad symlinks are more descriptive than /dev/null, if a bit
dangerous).

If you need any additional info/tests/whatnot then feel free to write
back. Sorry if I'm doing something wrong, the intention is to help with
the problem I've found but I'm new to the Debian processes.