-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update container version to v28 #138
Update container version to v28 #138
Conversation
|
Looking at https://crates.io/crates/cargo-audit they call Indeed, locally it fixed the issue, so should we change
cargo generate-lockfile or cargo build ?
|
|
Apparently since 4 years ago: https://github.com/rustsec/rustsec/blame/main/cargo-audit/README.md. I think we're running into rustsec/rustsec#1032, which seems to be the commit at which |
The problem I see is that |
Well here are some solutions I can think of right now:
|
Mh, but "versions we're actually using" is not really a concept for a library target, only for a binary. You can build a library against any versions of its dependencies that are semver compatible. How exactly do we actually expect cargo audit to work here? Maybe "fail if any semver allowed version has a known vulnerability" would make sense (so we can prevent downstream user from using our crates together with vulnerable versions of our dependencies, but I don't think we should do this kind of policing - I know some other rust crates recently came under fire for similar things). But I don't think cargo audit does that. I feel like it can only give meaningful information to a binary target, where everything is pinned to a specific patch version, and we can only make sure that we always support the newest versions of our dependencies, to ensure downstream users can always upgrade should vulnerabilities be found 🤔 |
@roypat I agree. The Rust Cargo team now recommends libraries pin dependencies by committing the lockfile and has some arguments for it: https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control |
@roypat so we should do something like |
I'd be fine with that. When we start checking in Cargo.lock files (which I think we should, @epilys has linked some good arguments. Especially the whole "CI fails because some new version of external dependency got pulled in" thing caused us quite some pain in the past - heck, a different facet of that problem got us into the mess we're in right now!), it'll also start running on those again, for whatever infinitesimal gain that gives us, without us needing to modify the ci package again, so that's a plus. If we really want to main the questionable status quo of "pick random versions of dependencies and then run cargo audit on the result", we can add a |
I also don't have a strong opinion, perhaps a little more toward the latter possibility (which @epilys also suggested). I found that I'll open another PR for this and we can discuss it there. I'll rebase this on that one. |
Starting from v0.18.0, cargo-audit hangs indefinitely if Cargo.lock does not exist. We discovered this while upgrading the container from v26 to v28 [1], which among other things updated cargo-audit. For the binary crates this should not be a problem, since they have Cargo.lock committed, but for many libraries this may not be true. If Cargo.lock is not there, we are generating one with the latest available versions, which may not be very significant. For this and other reasons it's now suggested that libraries also have a Cargo.lock [2] committed (thanks Manos for pointing this out). Note: `cargo generate-lockfile` updates Cargo.lock if it's already there, but we don't want it, that's why we have the guard. [1] rust-vmm#138 [2] https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control Suggested-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Suggested-by: Patrick Roy <roypat@amazon.co.uk> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
31d1748
to
b02d609
Compare
v2: |
Starting from v0.18.0, cargo-audit hangs indefinitely if Cargo.lock does not exist. We discovered this while upgrading the container from v26 to v28 [1], which among other things updated cargo-audit. For the binary crates this should not be a problem, since they have Cargo.lock committed, but for many libraries this may not be true. If Cargo.lock is not there, we are generating one with the latest available versions, which may not be very significant. For this and other reasons it's now suggested that libraries also have a Cargo.lock [2] committed (thanks Manos for pointing this out). Note: `cargo generate-lockfile` updates Cargo.lock if it's already there, but we don't want it, that's why we have the guard. [1] #138 [2] https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control Suggested-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Suggested-by: Patrick Roy <roypat@amazon.co.uk> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
b02d609
to
1947cdf
Compare
This new version contains alsa and pipewire libraries to build vhost-device-sound audio backends. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
1947cdf
to
ad11e6b
Compare
v3:
v4:
|
Summary of the PR
This new version contains alsa and pipewire libraries to build vhost-device-sound audio backends.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:
git commit -s
), and the commitmessage has max 60 characters for the summary and max 75 characters for each
description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafe
code is properly documented.