Tracking issue for migration to `extern_item_impls`

[newpavlov]

extern_item_impls provides language support for ergonomically adding getrandom support for targets which do not have a default impl. It also allows to override default getrandom implementations if necessary.

On stabilization of the feature we probably should fully migrate to it by replacing the opt-in backends and the wasm_js crate feature with a number of plug-in implementation crates.

Open questions:

• Should we use externally implementable traits (EITs) instead of externally implementable functions (EIFs)? IIUC EIFs are likely to get stabilized earlier than EITs. Additionally, it looks like the current design of EITs is not compatible with the TryRng trait.
• Security considerations for silently overwriting the default getrandom impls. Ideally, it would be nice if it was impossible to silently override the default impl by just adding a dependency, but the current design of EIFs does not provide a way to protect against it. (previous discussion)
• Should we keep plug-in crates in this repository or move it into a new one?

[bushrat011899]

Should we use externally implementable traits (EITs) instead of externally implementable functions (EIFs)? IIUC EIFs are likely to get stabilised earlier than EITs. Additionally, it looks like the current design of EITs is not compatible with the TryRng trait.

I think a trait is a better match conceptually, it would be nice if you could, for example, use an associated type for getrandom::Error. But the current nightly feature isn't really traits. I think for the current design of getrandom, EIFs are close enough to provide a meaningful ergonomic improvement. Since the whole crate is currently built around providing a single fn(&mut [MaybeUninit<u8>]) -> Result<(), Error>, I think the migration to EIFs would be quite straightforward.

Security considerations for silently overwriting the default getrandom impls. Ideally, it would be nice if it was impossible to silently override the default impl by just adding a dependency [...]

I see 3 cases here that need to be designed around:

1. Relying on a default backend from getrandom
2. Relying on a 3rd party backend from a dependency
3. Providing your own implementation

Cases 2 & 3 are trivially resilient to overwriting the backend, since EIFs (and EITs) will throw a compilation error if there isn't exactly 1 implementation (or 0 if a default is provided by getrandom). That does mean a dependency could break compilation, but that's nothing special since any crate can just compile_error!.

Case 1 is tricky, since in an ideal world a user shouldn't need to do anything to make getrandom work on a default-supported platform. The most secure option would be to just remove the default implementations of any EIFs and EITs and explicitly require someone to implement them, and encourage the user to either add a crate which does the implementation, or expose the getrandom default backends as public exports and make the user register it themselves.

Personally, I like the idea of splitting getrandom into its API (the EIFs/EITs, error type, etc.), and it's backends. If there was a getrandom-default crate which contained all the tier 1 default implementations, we could require the user to just add that as a dependency. Users which want to use a non-default backend would then just not include getrandom-default as a dependency and instead use getrandom-wasm-js, etc.

Should we keep plug-in crates in this repository or move it into a new one?

I think a single repository makes the most sense, since experimental backends could start as a separate crate, and then be merged into the main default crate once stable (e.g., efi_rng).

[dhardy]

If there was a getrandom-default crate which contained all the tier 1 default implementations, we could require the user to just add that as a dependency. Users which want to use a non-default backend would then just not include getrandom-default as a dependency and instead use getrandom-wasm-js, etc.

In this case I think we'd want getrandom to depend on getrandom-default as a default-feature, in which case I don't think it gains us anything.

Otherwise, I agree, though it's not yet clear when EII or EIT features will be stable.

[newpavlov]

If there was a getrandom-default crate which contained all the tier 1 default implementations, we could require the user to just add that as a dependency.

I don't think it's a good idea. Similarly to alloc users want for stuff to "just work" whenever possible.

Imagine SysRng being part of std/core (which is very likely to eventually happen), how should it work in such context?