Heads-up about filing advisories for the renamed crates
thomaseizinger opened this issue · comments
Hi!
I discovered that this project has been renamed but dependabot does not know that so it is not going to issue updates for the new crates. Thus, I am in the process of filing "unmaintained" advisories for the old crates and thought you might want to know about that ahead of time :)
Please give your input there in case that is somehow not wanted.
I'm not sure if we need or want to create an advisory, and I don't think I'd denote trust-dns crates as unmaintained right now. We can and have posted patches to previous versions when necessary. To be clear, while the name has change, we still have full control and ability to post patches to trust-dns, if those are needed. I'm not sure we need to force everyone to upgrade right now.
What do others think, @djc ?
The default for cargo deny is to issue a warning: https://embarkstudios.github.io/cargo-deny/checks/advisories/cfg.html#the-unmaintained-field-optional
That doesn't force anybody to update unless they explicitly set this to deny.
Perhaps I am misunderstanding something: How do you expect users to know that they are depending on a crate that is only passively maintained? The docs don't mention anything about this rename for example: https://docs.rs/trust-dns-proto.
I just stumbled over this by accident and went ahead to file the advisories to help other people find out about this in an automated way.
Ah, that was an oversight on the docs. I should have included a note in the 0.23.1 release. I do have a notice on https://crates.io/crates/trust-dns-proto
We could publish a 0.23.2 to put the notice there as well.
In terms of unmaintained, I've seen this be disruptive in the past with some other crates, some were warranted, others not. I'm just trying to avoid unnecessary disruption to users as there's no security issue at the moment with the trust-dns crates.
Ah, that was an oversight on the docs. I should have included a note in the 0.23.1 release. I do have a notice on crates.io/crates/trust-dns-proto
We could publish a 0.23.2 to put the notice there as well.
That sounds good.
In terms of
unmaintained, I've seen this be disruptive in the past with some other crates, some were warranted, others not. I'm just trying to avoid unnecessary disruption to users as there's no security issue at the moment with the trust-dns crates.
Ultimately your decision :)
The PRs are there at the advisory if you want them merged. Otherwise just let them know they are not wanted so they can get closed.
I think issuing unmaintained advisories would be useful in principle, but I would probably hold off on doing it for a few months to minimize disruption (allowing people to switch organically).
On the other hand, given that it's warn by default, maybe it makes sense to just get this done so people who are looking for it will notice.
Ok, I've added the notices in #2071.
@djc, that didn't feel like a confident answer on the unmaintained notices. It sounds like you have similar concerns as I do in regards to community disruption. Is there anyone that can answer the default audit behavior so that we can better understand the implications there?
Is there anyone that can answer the default audit behavior so that we can better understand the implications there?
We run the cargo-audit action with the default configuration:
This produces warnings on unmaintained crates:
https://github.com/libp2p/rust-libp2p/actions/runs/5981551811/job/16229566931#step:3:12
Which then creates issues to notify you about it:
cargo deny is similar in that it won't trigger build failures unless you explicitly tell it to.
We run audit with --deny,
Lines 90 to 92 in bb20324
Which I think will cause build failures when audit warnings are triggered. Based on some past experience here, I think a lot of projects run with the --deny flags passed, which is where some of the churn has come from, at least as I've noticed it in the community.
Personally, I don't think that is a good CI setting because it could fail your CI based on external factors unrelated to your code. That obviously then creates friction by e.g. stalling PRs if this check is required.
But this is kind of unrelated to the issue at hand.
If you don't want to issue an advisory, I'd suggest you deprecate a core symbol in each crate, point users to the renamed crate and issue that as a patch release. For users interested in updates, dependabot will update their PR which then will issue warnings.
The deprecation approach is more work for you but would be deterministic in regards to users CI runs (assuming they have a lockfile).
I don't think that is a good CI setting because it could fail your CI based on external factors unrelated to your code
Perhaps, though it also means that you don't get an automatic notice on potentially concerning issues. It's also why we use --deny on clippy for example.
If you don't want to issue an advisory, I'd suggest you deprecate a core symbol in each crate, point users to the renamed crate and issue that as a patch release. For users interested in updates, dependabot will update their PR which then will issue warnings.
I got some feedback from some folks that I think I like, which might be a decent middle ground. Right now the advisory is for all versions. What do you think about constraining it to >= 0.23.1, and then folks audits would only fail when they update their lock files or other builds. I think I like that approach?
@djc, what do you think of the above idea?
Sounds good to me!
Sounds good! Will update the advisories!
Please see the updated PR: rustsec/advisory-db#1806.
I'm going to close this as I think we came to a decent solution. Thanks for all the input everyone.