Re: [RFC PATCH v3 1/3] scripts: add kconfirm

[Gary Guo]

On Sun May 17, 2026 at 9:25 PM BST, Demi Marie Obenour wrote:
> On 5/17/26 05:58, Miguel Ojeda wrote:
>> On Sun, May 17, 2026 at 8:10 AM Demi Marie Obenour
>> <demiobenour@xxxxxxxxx> wrote:
>>>
>>> I think it is simpler to just inline all of this code into its
>>> single call-site.  The safety of the code is obvious in context,
>>> and you can avoid checking for impossible errors.  For instance,
>>> since all of the options have required arguments, it really is safe
>>> to dereference optarg without any null check.
>> 
>> If we are going to have unsafe code, then let's please build safe
>> abstractions wherever possible, just like we do elsewhere. We should
>> also write `// SAFETY` comments and enable the lints that catch that
>> etc., just like elsewhere too.
>> 
>> (This is not to say we should use `getopt` instead of something like
>> `clap` -- as soon as we start using `cargo vendor`, then it makes
>> sense to at least consider having a set of vetted, well-known crates
>> to write Rust tools in-tree, as I mentioned in v1.)
>
> I was hoping for Linux to avoid the Rust trend of downloading tons
> of third-party crates, with all the supply-chain risks that entails.
> Hence the idea of using getopt and system C libraries.

Well, there're quite a few libraries which are "third-party" but they're
blessed and used by the Rust compiler itself (and often maintained by the same
group of people behind the Rust project).

https://github.com/rust-lang/rust/blob/main/Cargo.lock

For example, I would trust `clap` to be used, and I think it's a huge
developer-experience improvement compared to getopt.

I think it's not really reasonable to avoid all dependencies, after all, C tools
also require a few dependencies, it's just that they're sourced from distro and
not crates.io.

I think the only issue is that unlike C libraries, there's no unified ways for
distros to ship these libraries (and some distros don't ship individual Rust
crates as libraries at all). It used to be the case that you can enable the
`rustc_private` feature and just link against whatever the version that the Rust
compiler depends on, but rustc stopped you from doing that a while ago because
they don't want people to depend on rustc's private dependencies.

If the concern is with supply chain security, there're mechanisms like cargo-vet
https://github.com/mozilla/cargo-vet which can be used to ensure dependencies to
be audited. That plus the hash locking should be sufficient.

Best,
Gary