* Package name    : binwalk3
  Version         : 3.1.0
  Upstream Author : ReFirmLabs and contributors
* URL             : https://github.com/refirmlabs/binwalk
* License         : MIT
  Programming Lang: Rust
  Description     : Fast, signature-based binary and firmware analysis tool

Binwalk identifies and optionally extracts files and data embedded
inside other files via signature scanning and entropy analysis.

Motivation: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107530

Debian's current binwalk (2.4.3+dfsg1) tracks OSPG/binwalk, a fork
that has declared itself EOL now that upstream's Rust rewrite is
active again (https://github.com/OSPG/binwalk).

This ITP packages binwalk3 as a new, separate package for now, not a
same-name replacement because it has no Python API like the current
python3-binwalk, so swapping in place today would silently break
anything depending on that. A takeover (Provides/Replaces/Conflicts)
is planned once reverse-dependency exposure is checked.

Depends on crc32-v2 and crc32-codegen (#1146632, #1148656), currently
being packaged first.

I intend to maintain it within pkg-rust-maintainers via the
debcargo-conf monorepo process.

Just FYI, there's already a Debianized package for binwalk3 in Kali Linux at https://gitlab.com/kalilinux/packages/binwalk3 and the maintainer of it there, Sophie Brun, also happens to be a Debian Developer.

Pardon my ignorance, Sophie, but this isn't the first time I've seen a Debian RFP or ITP issue filed for an application that—unbeknownst to the submitter—is already in Kali. Furthermore, such packages seem at first glance to be in good shape and more or less ready for proper inclusion in Debian. Seeing as you and a couple other Kali folks are (to the best of my knowledge) Debian Developers with uploading privileges, is there a specific reason these packages aren't uploaded to Debian for the greater good? This isn't rhetorical—I'm actually clueless.

Thank you