1. 4

    Unfortunately some things that look bad (okay, ARE bad) have side effects if they are removed that may not be obvious. https://twitter.com/matthew_d_green/status/456960435845996544

    1. 4

      That person has no idea how the random subsystem works on OpenBSD, or any halfway sane system for that matter.

      1. 3

        If someone tweeted it, it must be true!

        1. 2

          I am not a cryptography expert, but the people who tweeted it include the guy who audited TrueCrypt, a Tor core developer, well-known cryptographers, leader of the main “dissident faction” on the OpenSSL dev list, etc. There is no doubt they know cryptography.

          But, as duclare says, the people in that Twitter conversation don’t know the specifics of OpenBSD. I’m just pointing out that there are many critical subtleties. Dumb code is not (necessarily) in there because the original developers were idiots, and the amount of rip-n-replace that is being done so quickly worries me.

          1. 6

            [..] the amount of rip-n-replace that is being done so quickly worries me

            If you look carefully, the changes so far have been quite simple and janitorial. Ignoring whitespace diffs, there’s been plenty of unifdeffing to simply remove code that won’t be used, or to remove knobs and unconditionally enable code that should always be there. Then there’s been an effort to remove unnecessary wrappers around some standard library calls.

            One actual change was to replace the built-in RNG goo with a call to arc4random, which is used everywhere on OpenBSD. With this change most of the RNG related functions are reduced to stubs that do nothing (they are unnecessary, arc4random just works), and the one useful function only does one function call.

            Then you have a few bug fixes for freeing things in error paths, or passing the right buffer size to snprintf and such. Using calloc instead of malloc & memset. Simplified ways to construct some strings. Simplification across the board.

            Thus far it’s really been just rip-n-simplify, with very very few code additions. There’s little new replacement code that would have flaws in it (aight, a few mistakes were committed and fixed soon enough).

            But if you are worried, keep watching the commits. It can’t hurt to have an extra pair of eyeballs.

            1. 3

              The dumb code exists because the developers subscribe to a worst common denominator philosophy. Instead of foisting this nonsense onto the users and developers of broken systems, they have internalized it.

              1. 2

                Anyone “worried” about unspecified “critical subtleties” has a very easy way to assuage his feelings: stick with OpenSSL and do not use the OpenBSD fork.

          2. 1

            They couldn’t find something other than the private key to seed the entropy pool with?

          1. 3

            I don’t see a problem. The data is destroyed. It’s removed from the VM host within a few minutes, and entirely within 48 hours. It’s a UI issue since the scrub data feature gives a misleading (and strange*) “Estimated Destroy Time” of a few minutes. That only applies, as far as I can tell, to wiping the instance from the VM host.

            As for tweaking the SSH host key, that likely has to do with their build process. On any VPS you should re-generate the host key. Even if it wasn’t obviously “changed” there’s no guarantee the hosting provider didn’t keep a copy of it.

            I also find that Digital Ocean has allocated a pool of IP addresses for me that gets re-used. The author was surprised to have been re-allocated the same address; for me that happens all the time.

            * It’s strange because (a) why, as a user, would I care how long it takes their internal systems to wipe the data, and (b) it should be instant — delete the encryption key. This implies they aren’t encrypting your VM data at rest.