The generalizations about the quality of C code is interesting...It is easy to criticize code that has been developed over years, multiple hands, etc.
C code doesn't have to be terrible. And "terrible" often is in the eye of the beholder.
I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms.
Some claim the architecture and quality is crap (often, it's more about style), some just know that's how it was developed and stick to the style and extend / fix / etc. A lot of the OpenSSL issues stem from the wide range of use and the lack of giveback by companies working with it (including donations, etc. This goes back nearly 15+ years).
A new and hot language does not make a new implementation any more secure (maybe it has different issues) than one that has been around awhile, had multiple eyes, etc.
> I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms.
That... really depends on what you consider "worked well". Being a cryptography library, I think I could make a strong argument that working well includes a very good track record with regard to exploits. I don't believe OpenSSL exhibits that[1]. Note the number of items that include overflows and memory corruption in that reference. Also note that the first page (50 items, but some just DoS) only takes us back to mid 2014.
> A new and hot language does not make a new implementation any more secure (maybe it has different issues) than one that has been around awhile, had multiple eyes, etc.
That's true. Unfortunately, OpenSSL has proven itself to be a poor choice for a cryptography library for those that value security over performance. We used it because it's what we had that was free and supported what we needed, but we need more competition (which we are finally getting) so people can make decisions based on their priorities, not just the small pool of what's available.
New implementations (by knowledgeable security professionals) are what we need. Whether those are done in C/C++ using more modern techniques, or some other language that can eliminate certain classes of error in some other way is somewhat irrelevant, as long as it works as a library. I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen. That we might be able to approach that with much smaller performance loss is exciting.
> I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen
How would one know whether there are any major flaws in a code base?
Openssl very much falls into the "so complicated / complected that there are no obvious flaws"-bin, while something like NaCl is closer to "So simple there are obviously no flaws" one.
Note that there turned out to be a distressing number of obvious bugs in Openssl, and that it's doubtful that all serious bugs in a full, real-world crypto stack (especially perhaps if you demand support for x509) could ever be obvious.
You don't, for sure. But when half the security bugs seem to be related to memory corruption and buffer overflows, there are options. We've had languages that put more emphasis on being correct and safe than on performance, but people haven't been using them for much. C/C++ have momentum and people that know how to use them, so they are used. I'm not sure that makes them a good choice for security related work, where bugs sometimes counter the entire purpose of the library.
True, but I hardly have seen any codebase at enterprise level that isn't so.
C doesn't scale when you have projects where modules are written all the time by different people that got hired to work just on piece A and then leave.
They hardly can keep on their head all the nuances of memory management and UB of the company's codebase they have been asked to develop the feature A for in a month.
Languages with more strict type safety help keep people on the right path, even though they still stumble every now and then.
> C doesn't scale when you have projects where modules are written all the time by different people that got hired to work just on piece A and then leave.
That is true for any language, C, Java, Rust, Go. Continuity from team members is important.
No, because some languages make it easier to deal with developers as if they were cogs (even if I hate how things are nowadays).
For example, the use of automatic memory management or bounds checking, not only allows to remove an whole class of errors they remove the need to have a deep understanding of memory allocation patterns in the code.
Similarly the way one can make use of strong type definitions like in Ada, ML languages to only allow the code to compile if certain rules are followed.
We all hate to be dealt as cogs, but that is how the enterprise world works, the majority of the jobs are consulting gigs for specific features in short to mid term projects.
Perhaps, but being a cog in the software team at entreprise level does not preclude problems such as understanding the design decisions made or system limitations that are placed on the software design etc. Sometimes the inscalabity of a design is language independent. The problems are probably emphasised when consultants are engaged to do the job.
C code doesn't have to be terrible. And "terrible" often is in the eye of the beholder.
I've heard people decry OpenSSL and it's various warts (it has many), but as a code base, it's worked well for years across an incredible range of platforms.
Some claim the architecture and quality is crap (often, it's more about style), some just know that's how it was developed and stick to the style and extend / fix / etc. A lot of the OpenSSL issues stem from the wide range of use and the lack of giveback by companies working with it (including donations, etc. This goes back nearly 15+ years).
A new and hot language does not make a new implementation any more secure (maybe it has different issues) than one that has been around awhile, had multiple eyes, etc.