[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography-randombit
Subject:    Re: [cryptography] Just how bad is OpenSSL ?
From:       Jeffrey Walton <noloader () gmail ! com>
Date:       2015-01-06 18:30:24
Message-ID: CAH8yC8kWvFGC8A1ttSmK=qY1aAfmG4qoMCiO_0k=m7c7RGjaOw () mail ! gmail ! com
[Download RAW message or body]

> The source code is mostly written to the OpenSSL coding standards, which
> are seriously different from any other coding standard I've seen (it's
> not Linux/K&R, nor GNU, nor Microsoft, nor Sun/Oracle).  Nonconformance
> with the coding standards in later patches is very common, so it's a
> mishmash of indentation standards on top of that ...

Sorry to dig up an old thread. This seems news worthy for anyone who
has spent time staring at the sources.

"[openssl-users] OpenSSL source reformat",
http://openssl.6102.n7.nabble.com/openssl-users-OpenSSL-source-reformat-td55691.html.

On Fri, Oct 26, 2012 at 3:38 PM, Andy Isaacson <adi@hexapodia.org> wrote:
> On Fri, Oct 26, 2012 at 06:29:47PM +0000, John Case wrote:
>> So, given what is in the stanford report and then reading this rant
>> about openssl, I am wondering just how bad openssl is ?  I've never
>> had to implement it or code with it, so I really have no idea.
>>
>> How long has it been "understood" that it's a mess (if it is indeed
>> a mess) ?  How dangerous is it ?
>>
>> It looks like the rant was published in 2009 ....
>
> "Bad" is such a subjective measurement.
>
> OpenSSL is very very hard for a non-expert to code against.  It's hard
> to figure out what interfaces you should use, what interfaces are well
> tested, what interfaces are known to be unsafe, and what interfaces are
> buggy but can be used safely with careful coding.  It's fairly easy to
> accidentally disable security critical codepaths in the process of
> iterative "hmm that doesn't quite work, the docs are unclear, maybe this
> is a bug in my code or maybe a bug in OpenSSL?" that is a normal part of
> software development.  If you need to implement anything even slightly
> different from what was expected by the authors.
>
> The source code is mostly written to the OpenSSL coding standards, which
> are seriously different from any other coding standard I've seen (it's
> not Linux/K&R, nor GNU, nor Microsoft, nor Sun/Oracle).  Nonconformance
> with the coding standards in later patches is very common, so it's a
> mishmash of indentation standards on top of that.  Naming conventions
> sometimes indicate that functions are strictly internal and should not
> be used by applications, but sometimes you have to use an internal API
> to get a necessary result and other times there are clearly internal
> APIs in the public namespace.  I could go on.
>
> Overall, I would say that yes, OpenSSL is a huge mess for application
> developers.  In that sense, it's very bad.  On the other hand, it's the
> most thoroughly reviewed open source crypto implementation, and hasn't
> had very many security bugs found in the library per se.  Its
> performance is fairly good.  In that sense it's still the best option
> for some use cases.
>
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
[prev in list] [next in list] [prev in thread] [next in thread]