compiling to wasm fails due to clear_on_drop without no_cc ?

[warner]

I'm experimenting with using magic-wormhole.rs in a browser context, for which I'm compiling it to WASM (https://github.com/warner/magic-wormhole.rs/issues/2). This is my first attempt at doing anything with WASM, so please tell me if I'm missing something obvious, but I'm seeing the wasm-pack build fail because clear_on_drop is trying to compile a C file, and I guess that doesn't work when the target is WASM. The dependency chain is magic-wormhole -> spake2 -> curve25519-dalek -> clear_on_drop.

It looks like clear_on_drop has a feature (no_cc) that would disable the C compilation, which might allow this to work. But there's no way for magic-wormhole to ask curve25519-dalek to ask clear_on_drop to use that feature.

So I think what I'm asking for is some curve25519-dalek feature that would then modify its clear_on_drop dependency's features to avoid this C compile. Then I could add a similar feature to spake2 that affects its dependency upon curve25519-dalek, and then again with magic-wormhole affecting its dependency upon spake2 to pass the request along.

Does that make sense? It sounds like a lot of work spread over many crates, and I have to imagine that every "feature" added to a Cargo.toml is a long-lived maintenance burden, so I don't really want to make a high-cost feature request for a fringe use case. And clear-on-drop is obviously the right thing to be doing, I don't want to see it become harder to achieve that security property. Is there a better way that people deal with this cross-crate feature handling?

For magic-wormhole's own clear-the-old-secrets purposes, I'm considering the zeroize crate, which I think is pure-Rust. But I don't really know what the tradeoffs are; I have to imagine clear_on_drop is more reliable or more thorough when it can use lower-level tools.

[tarcieri]

@warner re: zeroize, I think they're waiting for zeroize 1.0, since it's part of the public API.

Barring any unforeseen circumstances, the next release of zeroize will be 1.0. I can probably cut a 1.0 prerelease soon.

[warner]

Cool, thanks, that sounds like the best solution. I'll wait for that update.

[burdges]

As cargo features are additive then it might help if you add clear_on_drop as your own dependency with the no_cc feature. I suppose clear_on_drop might be violating feature additivity by using no_cc this way, but hey yet another problem with clear_on_drop.

[warner]

Oh, thank you! That at least gets me a quick workaround I can use to move forward with testing.

[hdevalence]

@warner clear_on_drop doesn't require a C compiler when using its nightly feature, so you can alternately prevent its use by enabling the curve25519-dalek/nightly feature.

The issue with zeroize is that it works using a public trait, rather than an internal implementation detail, so while we can drop clear_on_drop at any time to switch to zeroize, once we do, we're stuck supporting it until making a breaking change.