[GH-ISSUE #2069] Heads-up about filing advisories for the renamed crates #870

Closed
opened 2026-03-16 00:40:38 +03:00 by kerem · 15 comments
Owner

Originally created by @thomaseizinger on GitHub (Oct 18, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2069

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.

See https://github.com/rustsec/advisory-db/pull/1806.

Originally created by @thomaseizinger on GitHub (Oct 18, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2069 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. See https://github.com/rustsec/advisory-db/pull/1806.
kerem 2026-03-16 00:40:38 +03:00
Author
Owner

@bluejekyll commented on GitHub (Oct 18, 2023):

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 ?

<!-- gh-comment-id:1767575648 --> @bluejekyll commented on GitHub (Oct 18, 2023): 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 ?
Author
Owner

@thomaseizinger commented on GitHub (Oct 18, 2023):

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.

<!-- gh-comment-id:1767601299 --> @thomaseizinger commented on GitHub (Oct 18, 2023): 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.
Author
Owner

@bluejekyll commented on GitHub (Oct 18, 2023):

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.

<!-- gh-comment-id:1767604905 --> @bluejekyll commented on GitHub (Oct 18, 2023): 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.
Author
Owner

@thomaseizinger commented on GitHub (Oct 18, 2023):

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.

<!-- gh-comment-id:1767608713 --> @thomaseizinger commented on GitHub (Oct 18, 2023): > 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](https://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.
Author
Owner

@djc commented on GitHub (Oct 18, 2023):

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.

<!-- gh-comment-id:1768340696 --> @djc commented on GitHub (Oct 18, 2023): 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.
Author
Owner

@bluejekyll commented on GitHub (Oct 18, 2023):

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?

<!-- gh-comment-id:1769296738 --> @bluejekyll commented on GitHub (Oct 18, 2023): 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?
Author
Owner

@thomaseizinger commented on GitHub (Oct 19, 2023):

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:

github.com/libp2p/rust-libp2p@c35c413b3a/.github/workflows/cargo-audit.yml (L6-L13)

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:

https://github.com/libp2p/rust-libp2p/issues/3136

cargo deny is similar in that it won't trigger build failures unless you explicitly tell it to.

<!-- gh-comment-id:1769847303 --> @thomaseizinger commented on GitHub (Oct 19, 2023): > 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: https://github.com/libp2p/rust-libp2p/blob/c35c413b3a2987892bc822a9c0c63ae8a56d24d1/.github/workflows/cargo-audit.yml#L6-L13 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: https://github.com/libp2p/rust-libp2p/issues/3136 `cargo deny` is similar in that it won't trigger build failures unless you explicitly tell it to.
Author
Owner

@bluejekyll commented on GitHub (Oct 19, 2023):

We run audit with --deny,

github.com/hickory-dns/hickory-dns@bb20324562/justfile (L90-L92)

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.

<!-- gh-comment-id:1769850809 --> @bluejekyll commented on GitHub (Oct 19, 2023): We run `audit` with `--deny`, https://github.com/hickory-dns/hickory-dns/blob/bb203245629f4cc4e7a48861b7d6810c011393c7/justfile#L90-L92 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.
Author
Owner

@thomaseizinger commented on GitHub (Oct 19, 2023):

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).

<!-- gh-comment-id:1769943576 --> @thomaseizinger commented on GitHub (Oct 19, 2023): 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).
Author
Owner

@bluejekyll commented on GitHub (Oct 19, 2023):

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?

<!-- gh-comment-id:1771842604 --> @bluejekyll commented on GitHub (Oct 19, 2023): > 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?
Author
Owner

@bluejekyll commented on GitHub (Oct 20, 2023):

@djc, what do you think of the above idea?

<!-- gh-comment-id:1773044138 --> @bluejekyll commented on GitHub (Oct 20, 2023): @djc, what do you think of the above idea?
Author
Owner

@djc commented on GitHub (Oct 20, 2023):

Sounds good to me!

<!-- gh-comment-id:1773147331 --> @djc commented on GitHub (Oct 20, 2023): Sounds good to me!
Author
Owner

@thomaseizinger commented on GitHub (Oct 22, 2023):

Sounds good! Will update the advisories!

<!-- gh-comment-id:1773974177 --> @thomaseizinger commented on GitHub (Oct 22, 2023): Sounds good! Will update the advisories!
Author
Owner

@thomaseizinger commented on GitHub (Oct 23, 2023):

Please see the updated PR: https://github.com/rustsec/advisory-db/pull/1806.

<!-- gh-comment-id:1774242336 --> @thomaseizinger commented on GitHub (Oct 23, 2023): Please see the updated PR: https://github.com/rustsec/advisory-db/pull/1806.
Author
Owner

@bluejekyll commented on GitHub (Oct 25, 2023):

I'm going to close this as I think we came to a decent solution. Thanks for all the input everyone.

<!-- gh-comment-id:1779975842 --> @bluejekyll commented on GitHub (Oct 25, 2023): I'm going to close this as I think we came to a decent solution. Thanks for all the input everyone.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hickory-dns#870
No description provided.