Attempted to use functionality that requires system randomness!!

[blue-freedom-technologies]

Hello,

I am getting this error for a ESP32-S3(xtensa-esp32s3-espidf).

The ESP-IDF have a Random Number Generation which do this type of things.

I am guessing that this is not supported and it will not be supported, right ?

This is connected with Is the ESPIDF implementation actually correct?

panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/getrandom_or_panic-0.0.3/src/lib.rs:29:55:
Attempted to use functionality that requires system randomness!!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
``

[burdges]

This crate only knows what cargo features you enable. It knows nothing about your getrandom implementation.

In an ideal world, we'd have cargo features that disabled the whole signing aperatus for crates that use this, but this creates considerable complexity in practice, like tests cannot work, etc. Anyways, substrate runtimes should never call the signing code, so in theory linkers should remove that dead code, and so this crate suffices to catch people doing broken things, like exposing secrets in their runtime.

[newpavlov]

ESP IDF should be supported by getrandom out of box as documented in the supported targets list (but you need to correctly configure your peripherals to get secure randomness), so getrandom_or_panic should not be needed. Are you sure that you target is configured correctly? target_os should be equal to espidf for it.

[blue-freedom-technologies]

Are you sure that you target is configured correctly? target_os should be equal to espidf for it.

More or less like this...

[target.'cfg(all(target_os = "espidf"))'.dependencies]
getrandom = { git = "https://github.com/rust-random/getrandom.git" , branch = "master" }

[newpavlov]

Why are you using the git version instead of the one published on crates.io? And why are you adding getrandom dependency gated on target_os?

[burdges]

As I said above, this specific error disapears if you pass this crate the getrandom feature, but this crate takes gitrandom from rand_core:

https://github.com/burdges/getrandom_or_panic/blob/main/Cargo.toml#L15

If you're using rand master then you'll need some cargo patch gymnastics, otherwise you'll loose whatever new features rand master gives.

We depend upon cargo unifying features, but features cannot unify when cargo pulls in multiple versions.

[blue-freedom-technologies]

Something is not right here.

I am using the ring library in my rust app.

My .cargo.toml

[build]
target = "xtensa-esp32s3-espidf"

[target.xtensa-esp32s3-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor"
rustflags = ["--cfg", "espidf_time64", "-C", "default-linker-libraries", "--cfg", "mio_unsupported_force_poll_poll"]

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32s3"
ESP_IDF_VERSION = "v5.1.3"
TARGET_CFLAGS = "-mlongcalls"
TARGET_CC = "/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32-elf-cc"

And where I am calling the rand function

Nevertheless, I am going to close this,

Cheers,

[burdges]

I migrated schnorrkel to this crate within the last 10 months. In fact, we've not yet published any of the dependents for which this crate was created:

https://crates.io/crates/getrandom_or_panic/reverse_dependencies

You've somehow depended upon schnorrkel/sr25519, but those are our non-standard crypto used only within the substrate/polkadot ecosystem, plus related ecosystems.

https://crates.io/crates/schnorrkel/reverse_dependencies

We always did this trick in schnorrkel, which would've triggered the same bug for you, even before this crate existed.

The other thing that happened is: substrate guys wanted more crypto to exist inside substrate runtimes, becuase doing so let them compute the original genensis hash cleaner or something. This creates a bunch of churn on the key derivation side of things, which maybe added some strange dependencies.