Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for WASM targets running in a custom runtime #83

Merged

Conversation

hculea
Copy link
Contributor

@hculea hculea commented Jun 3, 2024

Background

Currently, on WASM targets, the zxcvbn crate can only be used if the host environment is JavaScript, such that functions such as js_sys::new_0()::get_time() would be available through bindings generated by e.g. wasm-bindgen.

Rationale

Not all code compiled to WASM is run in a JavaScript runtime.

One example is the 1Password Go SDK, which uses Extism to communicate with a Wazero runtime, which does not have the JS bindings available.

For context, this project leverages a Rust core (wherezxcvbn is used to determine the password's strength, when creating or updating 1Password items) compiled to WASM. Calls to it are made from the Go host env.

In situations where these system functions are not available, placeholders for it have to be injected into the runtime by the host.

In the Go code, injecting such a function would look similar to:
https://github.com/1Password/onepassword-sdk-go/blob/main/internal/imported.go#L31-L38

Thought process

This PR addresses this issue by allowing the host environment to inject its own implementation for the now function. It requires the environment to export a unix_time_milliseconds_imported, returning the unix timestamp in milliseconds.

This change is fully backwards compatible, and it requires that the consumers of the crate explicitly opt in to provide this custom implementation by activating the custom_wasm_env feature. In the absence of this feature, calls to zxcvbn would panic.

How to test

Code review, to begin with, would be greatly appreciated.

For functional review, I have put together a test repository where the new behaviour can be validated.

See testing notes in the README: https://github.com/hculea/zxcvbn-test

Additional information

In the scope of this PR, I have also:

  • removed the getrandom dependency from the wasm32 dependency tree, as it was not being used anywhere
  • removed the #![forbid(unsafe_code)] linter, as injecting a custom function requires the execution of unsafe code

@hculea hculea marked this pull request as draft June 3, 2024 12:38
@hculea hculea changed the title draft: Add support for non js wasm targets Add support for non js wasm targets Jun 3, 2024
@hculea hculea changed the title Add support for non js wasm targets Add support for WASM targets running in a custom runtime Jun 3, 2024
@hculea hculea marked this pull request as ready for review June 3, 2024 16:44
@hculea
Copy link
Contributor Author

hculea commented Jun 5, 2024

@shssoichiro please do let me know if there is anything that I can do to help move this forward! 😄

@shssoichiro
Copy link
Owner

Sorry, I missed this MR before. It looks like there's still some issues with the build though. Would you mind taking a look? Wasm isn't my specialty.

@hculea
Copy link
Contributor Author

hculea commented Jun 19, 2024

No worries @shssoichiro, thanks for reaching back! Can you please re-run the workflows? 😄

@shssoichiro
Copy link
Owner

Looks like a missing use statement this time

@AndyTitu
Copy link
Contributor

Hey @shssoichiro, @hculea is out on PTO so I agreed to take this to the finish line. I reverted a change that I believed to have caused the build step fail this last time, so can you please re-run the jobs when possible? Thanks!

@AndyTitu
Copy link
Contributor

AndyTitu commented Jul 2, 2024

Hey @shssoichiro! Kind bump on the above: can you please re-run the jobs when possible? Thanks!

@shssoichiro
Copy link
Owner

Just returned from vacation, so I'm looking at this again now.

@shssoichiro
Copy link
Owner

Seems to still be having some issues, unfortunately.

Copy link
Owner

@shssoichiro shssoichiro left a comment

Choose a reason for hiding this comment

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

Thanks!

@shssoichiro shssoichiro merged commit 635a42f into shssoichiro:master Jul 5, 2024
5 checks passed
@hculea
Copy link
Contributor Author

hculea commented Jul 11, 2024

Thank you for the help here @shssoichiro!

Is there a process that we could kick off to create a new tag? We'd like to already leverage this functionality in our codebase

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.

None yet

3 participants