Bug#1144035: ITP: rust-p9 -- server implementation of the 9P filesystem protocol

Package: wnpp
Severity: wishlist
Owner: Yunseong Kim <[email protected]>
X-Debbugs-Cc: [email protected]

* Package name    : rust-p9
  Version         : 0.3.3~git20260608.18e31a4
  Upstream Contact: Daniel Verkamp <[email protected]>
* URL             : https://github.com/google/rust-p9
* License         : BSD-3-Clause
  Programming Lang: Rust
  Description     : server implementation of the 9P filesystem protocol

A server-side implementation of the 9P filesystem protocol in Rust, written
for ChromiumOS and published by Google. crosvm uses it for its virtio-9p
device, which is how a guest is given access to a directory on the host.

I need it to package crosvm (#1026126). With the feature set
qcow,balloon,net,usb,audio, crosvm pulls in 107 crates from crates.io, of
which 105 are already in Debian; p9 and its proc-macro p9_wire_format_derive
are the only two missing. My own motivation is a crosvm backend for
syzkaller, so that Linux kernel fuzzing can run under crosvm as well as QEMU.

One thing I would like a second opinion on, because it decides how this
should be packaged.

The newest version on crates.io is p9 0.3.2. It predates upstream commit
37ff802, "Prevent path traversal and sandbox escape in directory walking and
operations", which validates client-supplied path components and stops
filesystem operations escaping the exported root. Upstream bumped the version
to 0.3.3 for that fix but has never tagged or published it - crates.io still
ends at 0.3.2, and there is no v0.3.3 tag. So the only source carrying the
fix is git.

That matters more than it usually would. The consumer of this crate exports a
host directory into a virtual machine, so the exported root is a trust
boundary between guest and host, and the fix is precisely what defends it. I
do not think Debian should ship 0.3.2 as-is.

That leaves two options and I am happy with either:

  a) package the git snapshot, 0.3.3~git20260608.18e31a4, which is what I
     have prepared - one source package building librust-p9-dev and
     librust-p9-wire-format-derive-dev, at
     https://salsa.debian.org/ysk/rust-p9 branch debian/latest; or

  b) package 0.3.2 and 0.3.0 from crates.io through debcargo-conf in the
     usual way, carrying 37ff802 as a quilt patch until upstream publishes.

(b) is the Rust team's normal route for a crates.io crate and I would default
to it if the team prefers; (a) avoids carrying a security patch in Debian and
gets the tested upstream code. I have the debcargo-conf side prepared too, so
either can go ahead. I will also ask upstream to publish 0.3.3.

Both variants build in a clean unstable chroot and are lintian clean at
-EviIL +pedantic apart from initial-upload-closes-no-bugs. Note for anyone
reviewing: the upstream test suite reopens file handles through /proc/self/fd
and so needs a mounted procfs; in a chroot without one, 44 of its 81 tests
fail with ENOENT and it is the chroot, not the code.

I am filing a separate ITP for p9_wire_format_derive, which p9 depends on,
in case the crates go in as two source packages.

I am not a Debian Developer, so I will need a sponsor.