starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #1308] Redesign the `cargo install` experience #646

New issue

Open

opened 2026-03-15 23:39:18 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 23:39:18 +03:00

Owner

Originally created by @briansmith on GitHub (Dec 1, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1308

I did cargo install trust-dns which installed a binary named in /.cargo/bin/named. There's nothing wrong with that, but I wonder if the names of trust-dns binaries should be prefixed with trust-dns to avoid any potential for collisions?

Also, because somebody can use cargo install trust-dns to install named, and because a Cargo.lock is used, it seems like a patch and new release is needed any time a security update is made to a dependency (including any transitive dependency) of trust-dns, if that security update is at all relevant to trust-dns's use of the dependency. Otherwise, people running cargo install might get a version with a vulnerability. Maybe it would make more sense for the binaries like named to be in their own crate(s) that are versioned independently so that library users would be less affected by such situations.

Or, perhaps Trust-DNS binaries are not to be installed with cargo install? Just because you can, doesn't mean you should.

Really my goal here is to just to start a conversation to make sure these issues have been considered.

Originally created by @briansmith on GitHub (Dec 1, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1308 I did `cargo install trust-dns` which installed a binary `named` in `/.cargo/bin/named`. There's nothing wrong with that, but I wonder if the names of trust-dns binaries should be prefixed with `trust-dns` to avoid any potential for collisions? Also, because somebody can use `cargo install trust-dns` to install `named`, and because a Cargo.lock is used, it seems like a patch and new release is needed any time a security update is made to a dependency (including any transitive dependency) of trust-dns, if that security update is at all relevant to trust-dns's use of the dependency. Otherwise, people running `cargo install` might get a version with a vulnerability. Maybe it would make more sense for the binaries like `named` to be in their own crate(s) that are versioned independently so that library users would be less affected by such situations. Or, perhaps Trust-DNS binaries are not to be installed with `cargo install`? Just because you can, doesn't mean you should. Really my goal here is to just to start a conversation to make sure these issues have been considered.

kerem added the

unclear

trust

labels

2026-03-15 23:39:18 +03:00

kerem commented

2026-03-15 23:39:34 +03:00

Author

Owner

@briansmith commented on GitHub (Dec 1, 2020):

This also has some ramifications for yanking. One might argue that any crate with binaries and fixed Cargo.lock should be yanked so that cargo install $crate --version "$version" will fail for all versions with the vulnerability.

@briansmith commented on GitHub (Dec 1, 2020): This also has some ramifications for yanking. One might argue that any crate with binaries and fixed Cargo.lock should be yanked so that `cargo install $crate --version "$version"` will fail for all versions with the vulnerability.

kerem commented

2026-03-15 23:39:39 +03:00

Author

Owner

@briansmith commented on GitHub (Dec 2, 2020):

This also has some ramifications for yanking. One might argue that any crate with binaries and fixed Cargo.lock should be yanked so that cargo install $crate --version "$version" will fail for all versions with the vulnerability.

...and you might not want to yank the Trust-DNS libraries just for issues specific to the binaries.

@briansmith commented on GitHub (Dec 2, 2020): > This also has some ramifications for yanking. One might argue that any crate with binaries and fixed Cargo.lock should be yanked so that `cargo install $crate --version "$version"` will fail for all versions with the vulnerability. ...and you might not want to yank the Trust-DNS *libraries* just for issues specific to the *binaries*.

kerem commented

2026-03-15 23:39:44 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 2, 2020):

That's a good point on the naming of the binary. We should definitely consider that.

Today, we actually do have the named binary in it's own crate. The only complexity is that the release process for trust-dns is to push all crates together (for consistency). So today, trust-dns is only the named binary.

My personal preference has been to rely on the rustsec advisory system for vulnerabilities, rather than yanking. Though, that doesn't handle the install process your pointing out is an issue, and so maybe yanking binaries is the correct thing? This is a really good question.

@bluejekyll commented on GitHub (Dec 2, 2020): That's a good point on the naming of the binary. We should definitely consider that. Today, we actually do have the named binary in it's own crate. The only complexity is that the release process for trust-dns is to push all crates together (for consistency). So today, trust-dns is only the named binary. My personal preference has been to rely on the rustsec advisory system for vulnerabilities, rather than yanking. Though, that doesn't handle the install process your pointing out is an issue, and so maybe yanking binaries is the correct thing? This is a really good question.

kerem commented

2026-03-15 23:39:49 +03:00

Author

Owner

@briansmith commented on GitHub (Dec 2, 2020):

To clarify my comments above about cargo install, I guess as of Cargo 1.37 or so they apply mostly when cargo install --locked is used and/or when a dependency crate with a security issue hasn't published a minor version update that fixes the security issue.

In the case of cargo install --locked, note that the cargo install documentation suggests using --locked to get (more) reproducible builds. AFAICT there's no easy way to save the Cargo.lock used by cargo install if one doesn't use --locked. I suspect many people, as soon as they learn about these things, will switch to using --locked.

In the case where the crate hasn't published a minor version update that fixes the security issue, I would say that's likely to happen more frequently than people would like.

@briansmith commented on GitHub (Dec 2, 2020): To clarify my comments above about `cargo install`, I guess as of Cargo 1.37 or so they apply mostly when `cargo install --locked` is used and/or when a dependency crate with a security issue hasn't published a minor version update that fixes the security issue. In the case of `cargo install --locked`, note that [the `cargo install` documentation](https://doc.rust-lang.org/cargo/commands/cargo-install.html) suggests using `--locked` to get (more) reproducible builds. AFAICT there's no easy way to save the Cargo.lock used by `cargo install` if one doesn't use `--locked`. I suspect many people, as soon as they learn about these things, will switch to using `--locked`. In the case where the crate hasn't published a minor version update that fixes the security issue, I would say that's likely to happen more frequently than people would like.

kerem commented

2026-03-15 23:39:54 +03:00

Author

Owner

@briansmith commented on GitHub (Dec 2, 2020):

I actually wonder, for Trust-DNS in particular, if it is desired to be available by cargo install at all. Maybe the Trust-DNS binaries should only be installable from GitHub. That way patches and other non-Cargo dependencies could be used when building the binary, which might be necessary if an important change hasn't been accepted yet by a dependency crate.

@briansmith commented on GitHub (Dec 2, 2020): I actually wonder, for Trust-DNS in particular, if it is desired to be available by `cargo install` at all. Maybe the Trust-DNS binaries should only be installable from GitHub. That way patches and other non-Cargo dependencies could be used when building the binary, which might be necessary if an important change hasn't been accepted yet by a dependency crate.

kerem referenced this issue

2026-03-16 02:13:48 +03:00

[PR #647] [MERGED] Add SSHFP and OPENPGPKEY support #1572