Make it harder to use fuzztarget

[real-or-random]

I fear that someone just enables fuzztarget (it seems undocumented) or uses all-features, and people leak their private keys... It's inconvenient but maybe we can comment out the feature in Cargo.toml (will rustc complain?), maintain a separate branch or do something else to make it harder to shoot yourself in the foot.

[TheBlueMatt]

Agreed, but I'm not sure what the right answer is. Most of the point is to make it easier to run fuzzing as otherwise you have to recursively replace dependencies until you have everything running with fuzztarget enabled. I suppose at least documenting what it does is useful, maybe there is some hack with can do with requiring fuzzers set an undocumented static global setinal before the fuzztarget-mode functions will run?

[real-or-random]

maybe there is some hack with can do with requiring fuzzers set an undocumented static global setinal before the fuzztarget-mode functions will run?
This sounds reasonable.

Another idea, maybe simpler: fail the build and/or the program unless some special environment variable is set. That's kind of global, and we can use it for the build and the actual execution.

[TheBlueMatt]

IRC discussion:

<BlueMatt> real_or_random: as for fuzztarget, the only obvious thing I can come up with is a #[doc_hidden]pub static REALLY_ENABLE_BROKEN_CRYPTO: bool = false; that fuzzers have to set
<BlueMatt> and then just assert it in the fuzztarget functions
<real_or_random> have you seen my latest comment?
<BlueMatt> oh, no, i hadnt
<BlueMatt> hmm, i guess we could do that, too, you mean in the build script?
<BlueMatt> I'm game with either, just as long as we can include it in the crates version and it gives a reasonable "you forgot to do X" result when you dont do it
<BlueMatt> env var in build.rs may actually generate a better error message

[real-or-random]

@apoelstra You mentioned somewhere else that this issue has been solved but I don't think that's true. Or what were you referring to?

[apoelstra]

Yes, it is fixed by #263