Raw Feed of OpenBSD's Work on Cleaning Up OpenSSL


Raw Feed of OpenBSD's Work on Cleaning Up OpenSSL

This is an amazing timeline of how much and how quickly work can get done with a determined, dedicated team of hackers.

Here are some gems:


now that knf carpet bombing is finished, switch to hand to hand combat.
still not sure what to make of mysteries like this:
        for (i = 7; i >= 0; i--) {      /* increment */


If modern society can get past
selling daughters for cows, surely we can decide to write modern C code in
an "application" that is probably 3 lines of shell/python/cgi away from
talking to the internet in a lot of places..


egd support is too dangerous to leave where somebody might find it.


Remove support for big-endian i386 and amd64.

Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
        /* Most will argue that x86_64 is always little-endian. Well,
         * yes, but then we have stratus.com who has modified gcc to
         * "emulate" big-endian on x86. Is there evidence that they
         * [or somebody else] won't do same for x86_64? Naturally no.
         * And this line is waiting ready for that brave soul:-) */

So, yes, they are on drugs. But they are not alone, the stratus.com people are,


todo: do not leave 15 year old todo lists in the tree.


This code is the reason perl has a name as a write only language.


quoth the readme:
NOTE: Don't expect any of these programs to work with current
OpenSSL releases, or even with later SSLeay releases.


spray the apps directory with anti-VMS napalm.
so that its lovecraftian horror is not forever lost, i reproduce below
a comment from the deleted code.

        /* 2011-03-22 SMS.
         * If we have 32-bit pointers everywhere, then we're safe, and
         * we bypass this mess, as on non-VMS systems.  (See ARGV,
         * above.)
         * Problem 1: Compaq/HP C before V7.3 always used 32-bit
         * pointers for argv[].
         * Fix 1: For a 32-bit argv[], when we're using 64-bit pointers
         * everywhere else, we always allocate and use a 64-bit
         * duplicate of argv[].
         * Problem 2: Compaq/HP C V7.3 (Alpha, IA64) before ECO1 failed
         * to NULL-terminate a 64-bit argv[].  (As this was written, the
         * compiler ECO was available only on IA64.)
         * Fix 2: Unless advised not to (VMS_TRUST_ARGV), we test a
         * 64-bit argv[argc] for NULL, and, if necessary, use a
         * (properly) NULL-terminated (64-bit) duplicate of argv[].
         * The same code is used in either case to duplicate argv[].
         * Some of these decisions could be handled in preprocessing,
         * but the code tends to get even uglier, and the penalty for
         * deciding at compile- or run-time is tiny.