On Fri, Mar 11, 2022 at 10:17:47AM -0000, Simon Chopin wrote:
> @sbeattie there's some context on those various fields in
> https://github.com/cpaelzer/ubuntu-mir/pull/3
Thanks for this.
> Basically X-Cargo-Built-Using should be folded into Built-Using.
I agree with this, but is there a plan to land this in jammy?
If not, our tooling needs to compensate.
> There has been no talk of automating detection of packages that ought
> to have those fields, but that does sound like a good idea.
I think something needs to be in place, or there runs the risk of things
needing to pick up updates that don't get them applied.
> However, in the case of rustc and any future main package built using
> Rust, there are going to be vendored dependencies that are not packaged
> at all. It doesn't seem like a good idea to me to document those in the
> same fields as the dependencies that are separately packaged but
> statically linked, which is why I proposed shipping the Cargo.lock file.
>
> If you'd prefer, we could instead ship it in another field, maybe
> X-Vendored-Sources (as mentioned before, Built-Using seems out of scope
> for that).
It would be great if we could get this information as a field in the
Packages info (modulo concerns about size explosion as the set of
packaged rust software expands). I agree that it is not appropriate
for Built-Using; X-Vendored-Sources sounds great (if only we could
get this incorporated across more language ecosystems!). It would
probably be beneficial to have both the field in the packages metadata
list as well as the Cargo.lock file, to be able to identify which
crate versions were incorporated in superseded versions, if need be.
> For instance, using this small Python snippet, I get this for
> the Cargo.lock file shipped in rustc (Jammy):
>
> $ zcat Cargo.lock.gz | python3 -c "import toml; import sys; print(',
> '.join(f\"{p['name']}/{p['version']}\" for p in
> toml.load(sys.stdin)['package'] if 'source' in p))"
Thanks for this, lots to chew on here. Quite a few rust crates have
at least two versions of themselves in the list, which based on reading,
seems to be normal in the ecosystem, but then leads to issues like:
crossbeam-utils/0.7.2
crossbeam-utils/0.8.5
while the latter was patched to address CVE-2022-23639 in the current
jammy packaging, the former (in vendor/crossbeam-utils-0.7.2) was not.
While upstream crossbeam-utils yanked all of the 0.8.x versions < 0.8.7,
but there doesn't appear to be a fixed version of 0.7.x from upstream.
That's somewhat concerning about the ecosystem as a whole.
> The 'if source in p' statement filters out crates that are internal to
> rustc. Surprinsingly, the remaining rustc-* crates are separately
> packaged forks of existing crates.
That is also less than ideal.
> Would the security team feel more comfortable with this?
Yes, I think so.
Thanks!
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-23639
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957932
Title:
[MIR] rustc, cargo
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1957932/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
