Building a cargo vet infrastructure

[sophie-h]

To get a better handle on our "supply chain," I would like to try out cargo vet. @sdroege originally suggested the tool.

We likely want to set up one or more audit sources that other projects like our Core apps can import. This includes

1. Wildcard certify the packages we release in the project like all of gtk-rs, and
2. Aggregate the reviews we do in places like Core apps.

Some options

• gtk-rs could publish its own audits.toml for just wildcard certifying what gtk-rs publishes.
• GNOME could wildcard certify a list of popular and well-maintained crates that we use a lot in a central repo. We could create a fake project with a Cargo.toml with these crates as dependencies for that.
• GNOME (maybe separately from the above) also publishes an audits.toml which aggregates the reviews from our projects.

The goal would not be to start with reviewing every code base because that would get us nowhere. Instead, my goal would be to trust more reliable vendors for now and focus on niche crates that have far fewer eyes on them.

What do you all think?

[felinira]

I think this is a great idea :)

gtk-rs could publish its own audits.toml for just wildcard certifying what gtk-rs publishes.

What is the benefit? Every crate can certify themselves that they themselves are legit. To more clearly protect against gtk-rs itself being compromised shouldn't this list better live somewhere else? Or am I missing something?

Besides, there are many bindings and auxilliary crates that are not under the gtk-rs umbrella, and we need a solution for those too (adw, webkit, …).

• GNOME could wildcard certify a list of popular and well-maintained crates that we use a lot in a central repo. We could create a fake project with a Cargo.toml with these crates as dependencies for that.

Sounds like something for the release team to think about? IMO this list should be controlled by a rather small group, to make it be meaningful. As we are trusting people here, in the past and the future, not specific fixed code, this should be very limited in access scope.

• GNOME (maybe separately from the above) also publishes an audits.toml which aggregates the reviews from our projects.

The most important thing here is that such an aggregated list should very clearly document review procedures and guidelines, to not give a false sense of security. Is it possible and / or helpful to maybe limit these kinds of audits to just include proper code audits, and not wildcard audits?

Publically announcing / publicising a list would be a separate step from the above, and could be something to think about once the infrastructure is in place and successfully used internally. This could be very valuable for other projects to use - if it's maintained well.

[sophie-h]

What is the benefit? Every crate can certify themselves that they themselves are legit. To more clearly protect against gtk-rs itself being compromised shouldn't this list better live somewhere else? Or am I missing something?

The intention of wildcard certification is that organizations publish them because they have their own internal structures to ensure that they deliver trustworthy code. So that's exactly what they are for.

Besides, there are many bindings and auxiliary crates that are not under the gtk-rs umbrella, and we need a solution for those too (adw, webkit, …).

Yes, it might make sense to just publish them under GNOME together.

Sounds like something for the release team to think about? IMO this list should be controlled by a rather small group, to make it be meaningful. As we are trusting people here, in the past and the future, not specific fixed code, this should be very limited in access scope.

Since many people can also change the actual code in the GNOME/ group, there is no need to limit access more than that. We have a commit history, so there is no need to make that extra secure.

The most important thing here is that such an aggregated list should very clearly document review procedures and guidelines, to not give a false sense of security.

I would suggest that the aggregated list is not recommended for use in other projects for now and we don't have very strict review procedures. Many of the google, Mozilla etc reviews are also limited to checking for unsafe code and file operations. For what I have seen, the notes for each review contain information about what has been reviewed.

Is it possible and / or helpful to maybe limit these kinds of audits to just include proper code audits, and not wildcard audits?

I think this would have to be manual filtering on the generated audits.toml to publish if you use certify. If you use trust, the trust is only suggested to consumers of the imported audits.toml, not automatically trusted.

Publically announcing / publicising a list would be a separate step from the above, and could be something to think about once the infrastructure is in place and successfully used internally.

Yeah, we don't have to advertise it yet, but it will be public.

[sdroege]

I think this is a great idea and personally I would start with setting up such a thing GNOME-wide. On the GStreamer side we also talked about this a couple of times in the past, and I think this is something that could be shared between both projects (especially considering that many GNOME apps depend on GStreamer anyway, but not necessarily the other way around).

I'm not entirely sure what the point of the self-wildcard certification is. Is this just so that all e.g. gtk-rs crates are collected in a single place, and the GNOME-wide aggregate certification just has to point at a single "entity" instead of listing all 50 or so crates separately? If so that makes sense to me and adding that to gtk-rs / gstreamer-rs / etc would definitely be a good idea (together with some documentation what this is, how it's to be used).

How about we start such a gitlab project under World/Rust for the aggregate, and see where this takes us? For review rules, I would for now just go with things like "how widely used is this", "who maintains it", etc. and then take it from there. I would be happy to review MRs to that repository, and also the initial content of that repository.

[federicomenaquintero]

This looks fantastic. I've opened https://gitlab.gnome.org/GNOME/librsvg/-/issues/1112 in similar spirit to this issue.

[sophie-h]

That's how I would imagine the central part to work for GNOME https://gitlab.gnome.org/sophie-h/rust-supply-chain

[sophie-h]

This is now at https://gitlab.gnome.org/Teams/Releng/rust-supply-chain

[sdroege]

Should also add the pieces for that to gtk-rs. Do you want to track that individually in the crates, or should we just keep this one here open?

[sophie-h]

I think it makes sense to track that in the crates since there is no need for coordination between them.

[sdroege]

See gtk-rs/gtk4-rs#1837 gtk-rs/gtk-rs-core#1509 https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/528 https://gitlab.gnome.org/World/Rust/libadwaita-rs/-/issues/39

Other issues to be created if someone cares enough about those crates