Comment 19 for bug 1957932

On Tue, Mar 15, 2022 at 05:14:00PM -0000, Simon Chopin wrote:
> Before even starting to address the various points further, I must ask
> whether they're showstopper for the *rustc* MIR.

> I ask because some of the concerns raised here are irrelevant for rustc
> itself. For instance, the X-Cargo-Built-Using is not only not used by
> the rustc packaging at all, it would also not be used by Rust packages
> entering main since, under the proposed amended rules, those packages
> would first vendor all their dependencies.

Ah, I had missed this piece from the conversation on the github
MR. That places more emphasis on making sure Cargo.lock at a minimum
is included. Long term, it would be ideal to have these in package
metadata as X-Embedded-Copies or whatever, but ultimately that's
a feature that would be generally useful across the distro and in
Debian, not just in the Rust portions of it.

For X-Cargo-Built-Using vs Built-Using in dh-cargo, the Security team
can compensate one way or the other, we just need to know that, no,
Built-Using not going to land in jammy. With the intent to fully vendor
things in main, it's less important (from our team's perspective)
that this gets resolved one way or the other, but I note that we are
not the only ones with an opinion here.

One other consideration is that organizations and governments are
pushing really strongly for Software Bills of Materials (SBOMs) so
the more proactive we are about collecting needed information in a
structured, easily consumable way, the more straightforward it will
be to satisfy those requirements.

> We intend to implement all tooling changes that are required for a
> wider Rust ecosystem support in main, but this starts with having the
> compiler!

The reason I ask about ecosystem supportability here is because this
is likely the sole point where it's even in bounds for an MIR security
audit. The 'dh-cargo' package as a "build-time only" tool means there
is no requirement for it to go into main, and thus will likely never
receive an MIR. When it comes time to review cargo, the argument will
then be "Of what use is having rustc in main without cargo?" Individual
applications or libraries will have reviews focused on themselves.

The reality is we accepted Go-lang into main with a hypothetical plan
to support its ecosystem security-wise, but has been difficult to
turn into something real. My concern is that we're about to do the
same for Rust, despite our broad general approval of the language.

[There are also other constraints within Canonical that cause me
to be thinking about the supportability of the ecosystem as a whole
beyond what gets integrated into main, but you are correct that they
are out of bounds for an MIR.]

Anyhow. I have concerns about supporting this ecosystem, but the
provisional ACK is already there.

Thanks.