Add rust v3#1
Conversation
Some golang statements are actually meant to apply to any kind of vendored code, generalize those statements. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Some Golang specific rules apply to rust as well, list go+rust in those cases to make it clear that it applies to both. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
I was discussing with mclemencau/mdhudson/slangasek about what we should do looking forward to rust binaries (like firefox, but less single special snowflakes) in main. We excercised a bit based on my current example of mdevctl [1] and out of this we have efforts to bring the rust toolchain to main as well as these efforts to define the MIR rules for those. But the discussion is more wide-reaching as I want some commitment to get the toolchain itself to be considered supported as well as some guidance how to best deal with rust in its current state. At first it seems to be similar to golang, but it is worse. On one hand lib transitions are often quite hard in rust, see [2]. But more than that I was told that often transitions get stuck for quite a long time and are way too broken (this might improve and then we want to make rust less special). Finally while the concept of dynamic libraries [3] exists, it isn't usable as effectively only .so files from the very same build [4] are usable reliably and therefore are like static builds but in multiple files. In the discussions it was suggested: > " > Regarding the overall rust-in-main question: I'm fine with rustc being in > main provided there's resourcing. I think packages /using/ rust should only > be allowed in main via vendoring of their dependencies, because the > maintenance of rust libraries in Debian is bad right now. > ... > When we did the exception for golang, Jamie Strandboge drafted it for the > Security Team and I think there was some consultation with Foundations / > Archive Admins. > ... > ultimately it's the Security Team that bears the maintenance burden of > decisions we make about what to put in main, so I would defer to them and > have them consult whoever they think is relevant. > " In addition the extra burden will also be on the owning team and sustained engineering, so we want to get all their consultation before we switch to this. And while this is shockingly different from how everything else works today it really seems the only doable way *right now*. All the best practise we are used to (lib only once for re-use and less maintenance) does no more apply here until rust and the rust ecosystem evolves further. But while it is shocking at first, compared to all other approaches that came up so far that at least is realizable in a not too far future. And we also have to admit that all golang MIRs of the recent years have eventually went the vendoring-route as well, so that - for now - just seems to be the more applicable and doable way. Updates to v1: - The new rule/template layout has made this much smaller. - From the first iteration of this we realized that many golang rules will just apply to rust the same way - that again made it less noisy - We also have identified that vendored code in general (not just rust) should have an update plan, so we add a rule for that as well. [1]: https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 [2]: https://github.com/dtolnay/semver-trick [3]: https://rust-lang.github.io/rfcs/0404-change-prefer-dynamic.html [4]: https://doc.rust-lang.org/reference/linkage.html Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Co-authored-by: Lukas Märdian <slyon@ubuntu.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
This is less duplication (and was not rust specific) and makes it more clear that if there are common ways to refresh vendored sources in some languages using those is appreciated. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Following Debians dh tooling built-using no more tracks all dependencies anway. Adapt the wording to reflect that. Furthermore the same applies to the rule statments which need to reflect the go-mod/cargo.lock that we have come to in discussions for other sections of the document. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Until the ecosystems settled and all projects adapted. Ass well as the dh_* toolchain tolerates and produces reliable go.mod/cargo.lock tracking we have to be slightly more lenient on how exactly vendored dependencies are updated. That shall now - for all types - be outlined in README.source. That can for some projects still be `go mod ...` or `cargo update ...` but in other cases might need other steps and README.source provides the flexibility to do so. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
slyon
left a comment
slyon
left a comment
There was a problem hiding this comment.
LGTM overall, just some small inline comments.
I feel like this should be landed soon to have a base to build upon. It can still be improved/adopted later on, once we processed some initial Rust packages.
That is exactly the stance I have to this - thanks for seeing that I'm not the only one :-) |
Co-authored-by: Lukas Märdian <slyon@ubuntu.com>
Co-authored-by: Lukas Märdian <slyon@ubuntu.com>
didrocks
left a comment
didrocks
left a comment
There was a problem hiding this comment.
LGTM. +1. Just a sidenote between go.mod and go.sum requirement.
|
LGTM +1 |
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
|
Thank you all for the review and feedback so far, all integrated in the current PR. To merge this we are waiting on @setharnold to also give a +1 from securities POV as they have the biggest dependency to ensure their existing/intended tracking of CVEs in embedded code will work. |
setharnold
left a comment
setharnold
left a comment
There was a problem hiding this comment.
I believe we need additional tooling support before we allow in the first rustlang package.
Thanks
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
…-Built-Using As discussed in #1 this will add awareness for Static-Built-Using but even more important make the requirement for a generated cargo.lock/go.sum a requirement for now. Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
setharnold
left a comment
setharnold
left a comment
There was a problem hiding this comment.
This goes a very long way to address my concerns. I'd feel better if it included a guidance on using the mdevctl-style change to manually manage the Cargo.lock file.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
|
@setharnold wrote:
Hi Seth, so you mean I was giving in to you "too much" :-) Ok, I can adapt to - instead of generally making it impossible to promote a rust package - provide guidance on how to do it yourself until tooling is available. See the last commit 8625876 added in this branch please, does it cover what you asked for? @setharnold wrote:
Yeah - we all did agree in discussion that this is clearly the mid/long term way to go. |
setharnold
left a comment
setharnold
left a comment
There was a problem hiding this comment.
+1, thanks for working with Matthieu to make sure automated tooling is prioritized to meet our needs. Thanks for iterating on this with us.
6 participants
Hi,
this is the successor of the former discussion here which has now been rebased and updated to match the current state.
Since the last time we discussed this rustc itself is in main and we have a new Ubuntu release going on.
Some other things have settled and some others (e.g. creating cargo.lock in dh-cargo) have not.
We also have internally prepared our test-package mdevctl to present it for review to the MIR team after we have settled on the rules we want to initially have for rust.
Most old discussions became spin-offs into minor details or late additions.
Therefore I have re-started this and rebased it onto the new GH based markdown content and wanted to present it to the MIR team to discuss and vote on adding that.