Theo de Raadt <[email protected]> wrote on 2014/10/06 01:12:24: > > > Theo de Raadt <[email protected]> wrote on 2014/10/05 21:36:14: > > > > > > > > A diff back #ifdef OPENSSL_NO_FOO or shuffling the existing ones
> > around > > > > > in order to get things to build will not get accepted. On the other > > > > > hand, diffs carefully removing the remaining defines will be much > > better > > > > > welcomed. > > > > > > > > Being able to exclude unwanted/weak crypto's would be nice though. > > > > > > I think the approach is misguided. > > > > > > Fix the applications that use bad crypto. Don't get mired up in > > removing > > > it from crypto libraries with #ifdef's, which people won't tweak to > > disable > > > it. > > > > How then? Only way to make sure is to not use them in the long run is to > > not build them. > > Oh really. > > Those #ifndef options have been in OpenSSL for how long, 10 years? Or > more? > > And the effect has been ... what? Nothing. No effect at all. I use them :) Possibly other embedded projects too. > > > Dists. can then choose when/if to remove cryptos from their system. > > A nice --enable/--disable knob would be nice but I don't see how to do > > that without any ifdefs > > I think this is similar to what you already did with libressl, you removed > > some bad code > > to force apps to do something better. > > Name a mainstream distribution which did so. Otherwise, it's a pipe > dream. None I think. No surprise there as the old build system was horrible. Still, would it not be a good thing if weak cryptos were removed? The overall developer/admin does not know what cryptos to use I think. Either one can just rip them out, much like you already did for some bad functions in libressl or disable them per default with the an explicit option to turn them on. The current OPENSSL_NO_xxx defines are not good start for that but one could add a few new LIBRESSL_ENABLE_DES etc. and tie them to a --enable knob. Jocke
