summaryrefslogtreecommitdiffstats
path: root/lib/libcrypto/engine/engine.h
diff options
context:
space:
mode:
authorderaadt <deraadt@openbsd.org>2014-06-02 15:08:37 +0000
committerderaadt <deraadt@openbsd.org>2014-06-02 15:08:37 +0000
commit1cdc2ead0725c40cbbda34f52f4a488f09f52669 (patch)
tree7d3cee2b23dfabb03ac07d3fccc1d2207839f0ba /lib/libcrypto/engine/engine.h
parentRename more variables for readability and consistency. (diff)
downloadwireguard-openbsd-1cdc2ead0725c40cbbda34f52f4a488f09f52669.tar.xz
wireguard-openbsd-1cdc2ead0725c40cbbda34f52f4a488f09f52669.zip
A few months back there was a big community fuss regarding direct-use
of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone. Send this support straight to the abyss. ok kettenis
Diffstat (limited to 'lib/libcrypto/engine/engine.h')
-rw-r--r--lib/libcrypto/engine/engine.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/lib/libcrypto/engine/engine.h b/lib/libcrypto/engine/engine.h
index 5c2f7b05276..e99ad750e47 100644
--- a/lib/libcrypto/engine/engine.h
+++ b/lib/libcrypto/engine/engine.h
@@ -320,7 +320,6 @@ void ENGINE_load_padlock(void);
#endif
void ENGINE_load_cryptodev(void);
void ENGINE_load_rsax(void);
-void ENGINE_load_rdrand(void);
void ENGINE_load_builtin_engines(void);
/* Get and set global flags (ENGINE_TABLE_FLAG_***) for the implementation