>Then encourage upstream to: > > 1. Include a file compat_explicit_bzero.c into their tarball. > Ideally, talk to some of our C wizards (like tedu@) how > a portable implementation should look like. I suspect > that src/lib/libc/string/explicit_bzero.c will not be > very portable and maybe not even work outside libc.
LibreSSL contains a version, so that covers the majority of systems upstream will care about: https://github.com/libressl-portable/openbsd/blob/master/src/lib/libc/string/explicit_bzero.c The other good place to look for portable best-effort versions is in OpenSSH -portable. > 2. Include a configuration test checking at least whether the > operating system provides a function explicit_bzero(3) with the > correct prototype in the correct header, ideally also whether > it actually zeros the memory in some situation where some > compilers would optimize a memset(3) away. Agree, always prefer the system version if it exists. (Such a strategy in the past would have helped upstreams who wished to adopt arc4random() but were being overwhelmed by the sockpuppets). >If upstream does not want advice 1, tell them to use this: > >> ++#ifndef HAVE_EXPLICIT_BZERO >> ++#define explicit_bzero(p, len) memset((p), 0, (len)) >> ++#endif And why not. Upstreams who makes assumptions about the memory model probably trust the compiler as well. Cannot fight all battles. When they finally come around, they'll be lightly prepared.
