back to article OpenSSL audit kicks off for post-Heartbleed strengthening program

A major audit of the ubiquitous OpenSSL web security protocol is set to commence under a US$1.2 million industry commitment to harden open source technologies. OpenSSL is first off the rank under the Linux Foundation’s Core Infrastructure Initiative given its popularity and lack of in-depth security review. "OpenSSL has been …

  1. Woza
    Go

    Start with

    Some of the early change logs for Libre SSL.

    1. Anonymous Coward
      Anonymous Coward

      Re: Start with

      Lol - yes. Our security team were pretty scathing of some of the Libre changes. I guess they'll fix it eventually, assuming they have enough resources...

      1. Dan 55 Silver badge

        Re: Start with

        Why, what's so bad about LibreSSL? Do your team run VMS or Win16 or something?

        1. Anonymous Coward
          Anonymous Coward

          Re: Start with

          I thought that meant that they should save themselves some time and use libressl's changelog as a list of things (probably) known to be broken.

          Am I incorrect?

        2. Michael Wojcik Silver badge

          Re: Start with

          Why, what's so bad about LibreSSL?

          Kernel Normal Form, for a start. Mixing tabs and spaces for indentation is a sign of brain damage.

          Personally, considering the attitude of the LibreSSL team, I'd want to look very carefully at any changes they made. It'd likely be more efficient just to review the OpenSSL code myself. (And yes, I've spent quite a bit of time in the OpenSSL sources.)

  2. Primus Secundus Tertius

    Types of error

    The Heartbleed bug was not a subtle cryptography error but poor interface design, with two variables representing block size. Even if both variables were desirable, there should have been an 'assert'.

    So we may need a redesign rather than a review. Also a zero-tolerance policy for compiler warnings.

    1. Michael Wojcik Silver badge

      Re: Types of error

      "Poor interface design"? It was a failure to check the length of an array. Trivial mistake, trivial fix.

      It's hard to see how it could be considered a design rather than an implementation failure, except in the general sense of the liberal use of antipatterns and failure to refactor common code into safe alternatives. And I'd still consider that primarily an implementation issue.

  3. Nick Pettefar

    YES But...

    One wonders how many Spooks are working on the "audit". Those backdoors won't stay open by themselves.

  4. Michael Wojcik Silver badge

    Matt Caswell says on the realisation that coding was "very unusual"

    A bizarre evaluation. The OpenSSL source is bad by a number of metrics, but it is not at all unusual for C code, either open-source or proprietary. I've looked at probably hundreds of thousands of lines of C source, from hundreds of sources, over the past 27 years, and the vast majority of it ranges from poor to terrible (in terms of readability, maintainability, etc).

    It's possible to write good C code. The rules are pretty straightforward: Know the standard. Use meaningful names. Use whitespace and comments well. Enforce contracts. Use types well, including the types defined by the standard, ADTs (which in C means pointers to incomplete structs), and the const qualifier. Detect and handle errors. Avoid impediments to readability, such as overly-long lines, blocks, and functions. Use macros and conditional compilation judiciously and with restraint.

    There are people who write good C code, people like Chris Torek and Richard Heathfield and Peter van der Linden. I believe I do so as well. It requires a certain effort, which most C programmers are apparently not willing to make - largely, I suspect, because they haven't realized the cost of not doing so.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like