Skip to content

Conversation

kirillsurkov
Copy link

@kirillsurkov kirillsurkov commented Aug 13, 2025

Description

For now, the rsa feature is not supported on the wasm32 target. However, the ring crate supports wasm32 targets by enabling the wasm32_unknown_unknown_js feature.

Notes & open questions

I know that migrating to the rsa crate is planned, but it is not expected in the near future. These changes allow us to connect to public bootstrap nodes (which use RSA by default) from the browser.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@kirillsurkov kirillsurkov changed the title Enable rsa for wasm32 targets fix(identity): Enable rsa for wasm32 targets Aug 13, 2025
Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Looks like there is an error with wasm32-unknown-emscripten, which I wonder if we can get around that by checking explicitly for wasm32-unknown-unknown in the Cargo.toml?

Also can you update the Cargo.lock? :)

@kirillsurkov kirillsurkov force-pushed the master branch 5 times, most recently from db1f905 to f04e56d Compare August 13, 2025 14:27
@dariusc93 dariusc93 requested review from jxs and elenaf9 August 13, 2025 14:29
Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Left a quick comment

Comment on lines 79 to 85
#[cfg(all(
feature = "rsa",
any(
not(target_arch = "wasm32"),
all(target_arch = "wasm32", target_os = "unknown")
)
))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe we need to use "any" here. I believe using "all" would be enough. So it could be something like "#[cfg(all(feature = "rsa", all(.....)))]" so we are checking if it has the target os, although do we need to check it here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We check target_os to exclude wasm32-unknown-emscripten and wasm32-wasi. If we replace any with all, non-wasm targets will no longer pass the check.

Copy link
Member

@dariusc93 dariusc93 Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. Does it still happen if we were to just check for the feature itself?

Edit: i.e "#[cfg(feature = "rsa")]"

Also bare with me as I'm not at my computer right now :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we use just #[cfg(feature = "rsa")], the condition will be true on all platforms, which will break on wasm32-unknown-emscripten and wasm32-wasi.

Copy link
Member

@elenaf9 elenaf9 Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We check target_os to exclude wasm32-unknown-emscripten and wasm32-wasi. If we replace any with all, non-wasm targets will no longer pass the check.

Are there any other target_os we want to reject? If not, couldn't we just do not(any(target_os = "wasm32-unknown-emscripten", target_os = "wasm32-wasi"))?
Or else not(all(target_arch = "wasm32", not(target_os = "unknown")))?

I don't feel strongly about it, but IMO the current multi-line feature gate is a bit difficult to understand. If you want to stick with the current impl the it would be great to have at least a comment on one of the feature gates(e.g., the one that gates the rsa module) that explains why it can only be enabled on wasm for target_os = "unknown".

Copy link
Author

@kirillsurkov kirillsurkov Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elenaf9 Hi! Sorry for the delay, I was on vacation for the past 2 weeks.

I tried simplifying the expression, and the best I could get is:

#[cfg(all(
    feature = "rsa",
    any(not(target_arch = "wasm32"), target_os = "unknown")
))]

It's still multi-line, so I'm proposing introducing a build.rs script that creates an alias rsa_supported using cfg_aliases crate.

With that, the usage would look like this:

#[cfg(all(feature = "rsa", rsa_supported))]

What do you think?

@dariusc93
Copy link
Member

Also an fyi, no need to rebase the PR :)

@elenaf9
Copy link
Member

elenaf9 commented Aug 20, 2025

I think we can just merge master into this branch once, before merging the whole PR.
Otherwise everyone who subscribed gets a GitHub notification every single time the master is merged :)

hex-literal = "0.4.1"

[build-dependencies]
cfg_aliases = "0.2.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure if we should have another dependency in our tree (even though it's only for the building process). Thoughts @elenaf9 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants