I'm not sure whether you are sarcastic or not, but to me the seemingly endless amount of this kind of bug in high profile projects like OpenSSL is pretty good proof that nobody can write secure C.
Of course I am being sarcastic, you just need to check my other posts. :)
The point being, that in spite of what everyone says, not even with the help of the best tools to detect memory corruption issues in C, developers write memory corruption free code in it.
Are the openssl developers using the "best tools to detect memory corruption issues in C"?
In my experience, most open source projects don't devote the money or time to use, understand, deploy, and ensure such tools are used and the issues they find are resolved.
Actually, I think they're using the best tools to create memory corruption issues in C. There could in fact be a slow-moving fuzzer in their build system that transforms safe C constructs into unsafe ones before release. It's random and hits one thing at a time. Probably borrowed from mutation component of a genetic algorithm toolkit. I won't speculate if lack of focus or quality could indicate rest of OpenSSL code was produced by genetic algorithms.
No, it just takes a good developer to write secure C.
See: Qmail [1], which in 20 years only four bugs have been found, and only one of those was a potential security bug. Or djbdns [2]; similar lack of security holes despite being faster and safer than Bind.
It's far easier to write code in C than it is to write good code in C. It's a downside of the security of open source projects that the contributors are those who care enough to volunteer who can contribute code, rather than restricting the team, or at least those who can approve code going into the core, to vetted experts.
I'm a good developer, but far from the best, and glancing through the OpenSSL code that I've seen, I would never have approved most of it in code review. There needs to be someone at least as good as I am reviewing every last line of code submitted to OpenSSL. Even better if it were someone much better than I.
All the more reason not to rely on security properties of code written in C - I don't have time to read and understand the source of every piece of software I use, and popularity is completely useless as a proxy for code quality. Being written in a memory-safe language isn't a silver bullet for all problems, but it actually _is_ a silver bullet for memory corruption problems.
Memory corruption problems are a bit like infant mortality in the history of the medical profession - people that live past infancy still died, but infant deaths overwhelmingly impact the historical life expectancy statistics. Let's get our industry past the dark ages so we can start to live longer and begin to tackle more interesting causes of death.
EDIT: fixed very silly typo (which I'm really surprised i wasn't instantly called on - it basically made me say I wasn't willing to understand my own code. thanks for the generous reading!)
There are plenty of codebases (including large ones) written in C that have a low number of vulnerabilities, even compared to projects written in higher level languages (setting aside Rust et al because they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer. OpenSSL has louder vulnerabilities than most software because it's (1) very old, (2) very bad code, and (3) relied upon by heaps of software. There are lots of things wrong with OpenSSL, and those are the reasons that it's vulnerable. We should address the real issues instead of using C as a scapegoat.
> It requires discipline and care, but it's not impossible or even that hard if you're a skilled C programmer.
I have been reading about this mythical "skilled C programmer" since I got to learn C in 1993 and eventually joined C++ ranks instead, leaving my favorite Turbo Pascal behind.
Never met one to this day, but fixed lots of memory corruption issues left behind by not so skilled ones, during the days I used to work daily with C and C++ codebases.
We know they exist. Bernstein and Cutler are two probables based on reviews of their code. Thing is, these people are mentally not even human: it's like Human++ in terms of technical proficiency. So, maybe skilled C programmers only exist among the super-humans. ;)
There are plenty of freeways with speeding/puddle jumping drivers that have a low number of crashes, even compared to slower drivers (setting aside AI drivers, as they aren't that popular yet). It requires discipline and care, but it's not impossible or even that hard if you're a skilled driver at speed. Old cars have more accidents than not because they are (1) very old, (2) very poor parts, and (3) there are lots of them out there. There are lots of things wrong with old cars, and those are the reasons that they have accidents. We should address the real issues instead of using speeding drivers as a scapegoat.
I thought I was being clever. This is so well-written I can't tell if you're agreeing with C opponents, mocking them, or baiting someone like me into writing a comment like... Moving on.
I think the problem is partly with unsafe equipment, and partly with people that in seeking to go just a little faster, or get a little more of a thrill, make things quite a bit less safe for all those around them. To some degree, we all do this in different parts of our lives. People tend to vastly overestimate their ability to sustain high output, if not in one area (defensive coding) then in others (driving, procrastination, etc). Some of these affect the people around you more than others.
To clarify my original comment somewhat, I was talking less about general speeding of a few miles over the speed limit, and more about those people that are going significantly faster than surrounding traffic and weaving in and out of it to advance (puddle jumping). I do not enjoy having my chance of an accident increased my many orders of magnitude because of someone else's (impossible!) sense of competency, and I think that's very relevant in these discussions.
That's very interesting. I agree that effect is there. Passing down incorrect cultural knowledge about C is another I counter with my Pastebin. There's others like SPARK, Rust, and ATS countering concept that safety equals too slow or nothing low-level. Many things.
Back to your analogy, it seemed to start with both types of drivers: IBM vs Burroughs; C vs Wirth languages. The puddle jumper style got pretty popular with most roads and Interstates being built between their cities. The safer drivers have to be on those roads, too, but fewer in number since "Move Fast and Break Things" wasn't popular with small town folk. Got to point that majority of traffic and causes of accidents are puddle jumpers who mostly don't see their cars and driving styles are the problem.
And now we gotta find a way to re-design roads and cars to make their style less damaging while encouraging others to drive more wisely. Wow, put it in your analogy and I suddenly have less hope. ;)
The analogy breaks down the deeper you go, but there are some interesting parallels when you consider driving habits in other cultures. In the US (and probably most western countries) we have highly standardized and policed roads to prevent injury and accidents. I would argue this provides for a more efficient system overall, where in the end more people are able to get to their destination not just safer, but also faster, because the lack of accidents and assurance about other's likely actions on the road allow for mostly smooth operation. With computers, how much less (less, because it would never be none) hardware, software, CPU time and memory would need to be devoted security (firewalls, IDS, malware/virus detection and cleanup) if we had sacrificed a small amount of performance to ensure a more secure operating environment most the time?
We've achieved this with some aspects of society by making rules that hamper some for the benefit of all (traffic laws, employment laws, etc), because we've recognized in some places the failure of individual people and groups to be able to correctly assess risk and danger at wider levels and at longer time frames. These laws and regulations can go overboard, but they're needed to some degree because people are very poor stand ins for rational actors with good information, which in a pure market economy could make these decisions correctly. We've had little to nothing like this for software engineering, which has led to great advancements in short times, but I think we are nearing the point (if we haven't already passed it) when our past decisions to prioritize efficiency and performance over safety are resulting in a poorer relative outcome than if we have made different choices in the past.
"but also faster, because the lack of accidents and assurance about other's likely actions on the road allow for mostly smooth operation."
Yes, yes. It would seem so. There was a counter-point here that showed eliminating traffic controls reduced crashes and congrestion because people paid more attention. Was done in quite a few cities. I'd agree some standardization on behavior and design definitely improves things, though, as you know what to expect while driving.
"how much less (less, because it would never be none) hardware, software, CPU time and memory would need to be devoted security (firewalls, IDS, malware/virus detection and cleanup) if we had sacrificed a small amount of performance to ensure a more secure operating environment most the time?"
BOOM! Same message I've been preaching. My counterpoint to Dan Geer gave a summary of examples with links to more specific details.
"We've had little to nothing like this for software engineering, which has led to great advancements in short times, but I think we are nearing the point (if we haven't already passed it) when our past decisions to prioritize efficiency and performance over safety are resulting in a poorer relative outcome than if we have made different choices in the past."
Total agreement again. It's time we change it. We did have results with Walker's Computer Security Initiative and are getting them through DO-178B. Clear standards with CompSci- and industry-proven practices plus financial incentives led to many products on the market. The Bell paper below describes the start, middle, and end of that process. Short version: NSA killed market by competing with it and forcing unnecessary re-certifications.
Anyway, I've worked on the problem a bit. One thing is a modern list of techniques that work and could be in a certification. Below, I have a list I produced during an argument about no real engineering or empirical methods in software. Most were in the Orange Book but each were proven in real-world scenarios. Some combo of them would be a nice baseline. Far as evaluation itself, I wrote up an essay on that based on my private experience and problems with government certifications. I think I have solid proposals that industry would resist only because they work. :) The DO-178B/C success makes me think it could happen, though, because they already do it piece by piece with a whole ecosystem formed aroud re-usable components.
Of course, I'd be interested in your thoughts on the empiracle stuff and security evaluations for further improvement. For fun, you might try to apply my security framework or empirical methods to your own systems to see what you find. Only for the brave, though. ;)
> Of course, I'd be interested in your thoughts on the empiracle stuff and security evaluations for further improvement. For fun, you might try to apply my security framework or empirical methods to your own systems to see what you find. Only for the brave, though. ;)
If only I worked in an environment where that was feasible. I write Perl for a very small off-market investment firm (event ticket brokerage) as the only software engineer. My work time is split between implementing UI changes to our internal webapp (which we are thankfully going to be subbing out), reporting and alerting tools for the data we collect, manipulating and maintaining the schema as data sources are added, remove or change and maintaining the tools and system that streams the data into the model. While getting to a more secure state would be wonderful, I'm still working to reduce the number of outright blatant bugs I push into production every day due to the speed at which we need to iterate. :/
> Counter point to Dan Geer: Hardware architecture is the problem
This is interesting, and aligns quite well with the current discussion. We live with the trade-offs of the past, which while they may have made sense in the short term, are slowly strangling us now.
> Bell Looking Back
An interesting paper on the problems of security system development and how market changes have helped and hampered over time. I admit I skimmed portions of it, and much of the later appendix sections, as my time is limited. The interesting take-away I got from it is that our government security standards and certification are woefully inadequately provided for, where they aren't outright ignored (both at a software level and at an organizational policy level). I now feel both more and less secure, since I wasn't aware of the specifics of government security certification, so seeing that there are many and are somewhat well defined encourages me to believe the problem at least received rigorous attention. Unfortunately it looks like it's a morass of substandard delivery and deployment, so there that. :/ It is a decade old though, so perhaps there have been positive developments since?
> Essay on how to re-design security evaluations to work
and from that your "nick p on improving security evaluations" and
> List of empirically-proven methods for robust, software engineering
These all look quite well thought out, from my relative inexperience with formal computer security and exploitation research (I've followed it more closely at some times than others, and it's a path I almost went down after college, but did not). The only thing I would consider is that while these are practices for developing secure systems, and they could (and should in some cases) be adopted for regular systems, I think there is a place for levels of adherence to how strict you need to be, and how much effort needs to go into your design and development. Just as we require different levels of expertise and assurance for building a small shed, a house, an office building, and a skyscraper, it would be useful to have levels of certification for software that provided some assurance that specific levels of engineering were met.
"While getting to a more secure state would be wonderful, I'm still working to reduce the number of outright blatant bugs I push into production every day due to the speed at which we need to iterate. :/"
Interesting. What do you think about the tool below designed to handle apps like yours with low defect?
It originally delivered server parts on Java I think. Switched to Node due to low uptake, client/server consistency, & all RAD stuff being built for Node. Main tool written in ML language by people that take correctness seriously. I doubt you can reboot your current codebase but it seems it should be applicable for a similar set of requirements or a spare-time app. Also, not a write-only language. ;)
Jokes on Perl aside, you might find it fascinating and even ironic given current usage (eg UNIX hackery) to know that Perl only exists due to him working... on the first, high-assurance VPN for Orange Book A1 class (highest). Took me 10-20 minutes of Google-fu to dig it out for you:
I'm sure you'll find his approach to "secure," configuration management entertaining.
" We live with the trade-offs of the past, which while they may have made sense in the short term, are slowly strangling us now."
Yep. Pretty much. Outliers keep appearing that do it better but rejected for cost or lack of feature X. Some make it but most don't.
" I now feel both more and less secure..."
"I think there is a place for levels of adherence to how strict you need to be"
Very fair position. :) Early standard did that to a degree by giving you levels with increasing features and assurance: C1, C2, B1, B2, B3, A1. Really easy to understand but security features often didn't match product use case. ITSEC let you describe the features, security features, and assurance rating separately to fit your product. It was less prescriptive on methods, too. Common Criteria did that but knew people would screw up security requirements. So, they added (and preferred) Protection Profiles for various types of product (eg OS, printer, VPN) with threats specified, baseline of countermeasures, and minimal level of assurance applicable. You could do "augmented" (EAL4 vs EAL4+) profiles that added features and/or assurance. CIA's method more like Orange Book where it's simple descriptions on the cover but like this: Confidentiality 5 out of 5, Integrity 5 out of 5, Availability 1 out of 3. Specified level of risk or protection corresponding to each number with methods to achieving it up to manufacturer & evaluators.
So, your expectation existed in the older schemes in various ways. It can definitely be done in next one.
"different levels of expertise and assurance for building a small shed, a house, an office building, and a skyscraper"
Nah, bro, I want my shed and house build with the assurance of an office building or skyscraper. I mean, I spend a lot of time there with some heavy shit above my head. I just need the acquisition cost to get to low six digits. If not, then sure... different levels of assurance... grudgingly accepted. :)
> I doubt you can reboot your current codebase but it seems it should be applicable for a similar set of requirements or a spare-time app.
No kidding. At 85k+ LOC (probably ~70k-75k after removing autogenerated ORM templates) in a language as expressive as Perl... well, I wouldn't look forward to that. And really, if it didn't have a DB abstraction layer at least approaching what I can do with DBIx::Class, I'm not going to contemplate it. Mojolicious takes care of most my webapp needs quite well. As for type checking, what I have isn't perfect, but it's probably worlds better than what you are imagining. I'll cover it below.
> Also, not a write-only language. ;)
use Moops; # [1]. Uses Kavorka[2] by default for funciton/method signatures
role NamedThing {
has name => (is => "ro", isa => Str);
}
class Person with NamedThing;
class Company with NamedThing;
class Employee extends Person {
has job_title => (is => "rwp", isa => Str);
has employer => (is => "rwp", isa => InstanceOf["Company"]);
method change_job ( Object $employer, Str $title ) {
$self->_set_job_title($title);
$self->_set_employer($employer);
}
method promote ( Str $title ) {
$self->_set_job_title($title);
}
}
# Now to show of Kavorka's more powerful features
use Types::Common::Numeric;
use Types::Common::String;
fun foo(
Int $positional_arg1 where { $_ % 2 == 0 } where { $_ > 0 }, # Composes a subset of Int on the fly
Str $positional_arg2,
ArrayRef[HashRef|MyObject] $positional_arg3, # Complex type
DateTime|NonEmptySimpleStr :$start = "NOW", # Named param with default
DateTime|NonEmptySimpleStr :stop($end)!, # Named param with different bound variable in function, which is optional, so may be undef (which composes Undef into the allowed types)
) {
...
}
It's not at compile time checking, but man is it useful. If you've been following Perl 6 at all, it's mostly a backport of those features. Particularly useful is the ability to define your own subtypes and use those in the signatures to keep it sane. E.g. declare HTTPMethod, as Str, where { m{\A(GET|POST|PUT|PATCH|DELETE)\Z} }; Perl 6, where at least some of this is compile time checked (obviously complex subtypes cannot be entirely), fills me with some hope. I'm not entirely sold though, that's one beast of a language. It really makes you put your money where your mouth is when it comes to espousing powerful, extensible, expressive languages. I guess time will tell whether all that rope can be effectively used to make a net instead a noose more often than not. :)
> I'm sure you'll find his approach to "secure," configuration management entertaining.
Ha, yeah. I think secure is a bit of a misnomer here though, as it is a fairly novel way to do authorized configuration management, for the time.
> So, your expectation existed in the older schemes in various ways. It can definitely be done in next one.
And after you've filled me with such confidence that they are capable of both speccing a good standard and incentivizing its use at the same time! ;)
> Nah, bro, I want my shed and house build with the assurance of an office building or skyscraper. I mean, I spend a lot of time there with some heavy shit above my head.
I'm a little disappointed that I just image searched for "overengineered shed" and all the results ranged from a low of "hmm, that's what I would probably do with the knowledge and time" to "oh, that's a job well done". The internet has failed me...
" If you've been following Perl 6 at all, it's mostly a backport of those features. "
Definitely an improvement over my Perl days. Not sure how well they'll eventually get it under control or not. It is better, though.
" I think secure is a bit of a misnomer here though, as it is a fairly novel way to do authorized configuration management, for the time."
Definitely haha. Quite a few things were improv back then as there existed no tooling. Secure SCM was eventually invented and implemented in various degrees. Wheeler has a nice page on it below. Aegis (maintenance mode) and esp OpenCM (dead link) implemented much of that.
" I just image searched for "overengineered shed""
Bro, I got you covered. I didn't subscribe to Popular Science for the layperson-oriented, science news. It was for cool shit like the SmartGarage: a truly-engineered garage. They took it down but I found article and vid of its construction. Enjoy! :)
That is absolutely true and I don't disagree that it is possible to write C securely. But I would contend that the statistics you mention reflect differences in programmer attitudes and skill, and should be controlled for in any comparison. The same level of care and skill in another language will very likely lead to even fewer vulnerabilities, as long as that language doesn't have its own even worse foot-guns.
The priorities of the language are just different. When I use C, I get fairly decent performance basically for free, but I have to work and maintain discipline to obtain safety, high-level abstractions, etc. I'd much rather work in a language where I get memory safety and basic type-sanity checks for free and have to work for performance. This should really be the default, as it's much more in line with the end-user's needs. When I vet software, it's extremely easy to tell whether it is performant, but it takes serious auditing in C to tell whether it is even memory-safe, let alone actually correct and relatively free of side-channels, etc.
The thing about memory safety is that it can be compromised almost anywhere in your code. Your attack surface compared to what _should_ be exposed to attackers is incredibly large. If I can trust the memory-safety of a codebase I am auditing, I don't have to spend nearly as much time on it because I can focus on the parts that actually deal with the intended purpose of the code rather than having to go through every allocation and every memory access in the entire codebase with a fine-toothed comb.
Why do we continue to prefer a language where it's easy to achieve the only goal that is obvious when not achieved, at the expense of requiring great care and discipline 100% of the time in order to not instantly and fully compromise the harder-to-evaluate goals that actually matter (especially in security-oriented software such as openssl)? In this case, bad buffer handling in a data structure deserializer gave attackers a free ride past man-years (perhaps man-centuries) of work writing and auditing security-critical code.
Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler. Especially when there are so many good compilers for so many good languages that already do it.
Oops, forgot to make the explicit connection to your comment - the TL;DR is really the last paragraph.
OpenSSL is a beautiful case study in this. If it were written in a memory-safe language, you're right that many things would still be wrong with it - the author(s) very well may have botched "heartbleed" anyway with their custom allocator, but the parade of other buffer handling errors would not have been exploitable except potentially as denials of service. The weaknesses would have at least been interesting (and less numerous, all other things being equal).
I think that we need an improved C compiler more than we need new languages. You put it quite eloquently:
>Surely it'd be better if these kinds of failures were at least interesting rather than an endless parade of careless mistakes that could literally have been caught by trivial automation in the compiler.
You're right - they CAN be caught by trivial automation in the compiler, so let's add that.
You can generally respond even if you don't have the link by clicking on the timestamp ("1 hour ago" or whatever) to go directly to my comment.
My comment was not meant to point out that libsodium doesn't make a general OpenSSL replacement. It was meant to point out that if you restrict the problem domain enough, of course it's possible for people to write secure C. I can write a secure "Hello, World!" program; even a secure networked "Hello, World!". But being able to write a secure "Hello, World" does not mean that I am capable of writing secure C in general.
Pointing out one small piece of code that is apparently secure isn't what a claim like "nobody can write secure C" is really about. "Nobody can write secure C" means that when programming in the large, implementing standardized network protocols with all of their warts, having codebases that evolve over time, that no one can consistently and reliably write secure C.
OpenBSD is likewise a minimalist system with a heavy emphasis on security, but even with that approach, they have had to change their slogan to "Only two remote holes in the default install, in a heck of a long time."
Now, of course, this does point out a few things. Minimalism is important for security; and more minimalist approaches and care in writing code can help reduce the frequency and severity of critical vulnerabilities. But even given some of the most careful, security conscious approaches, people still make mistakes.
That's why, when practicing responsible security, you should use defense in depth. In addition to all of the care, review, minimalism, principal of least authority, isolation, etc, you should also use tools that can prevent whole classes of bugs at compile time.
It also doesn't interoperate with any widely deployed crypto standards.
Yes, NaCL is a better design for cryptographic primitives, being much more limited in scope and reducing the number of primitives supported. It's great, if you can control both sides of the protocol so you can use something like this, and if you can also write your own safe, secure protocol code on top of it that doesn't introduce any errors of its own.
The problem being solved by OpenSSL is much harder; for interoperability, you need to support a much wider range of standards, and they are always changing. It also supplies the full protocol stack to implement TLS, including multiple versions of TLS, rather than just the crypto primitives.
It's when you have code that is trying to do all of this, and evolve over time, with contributions from multiple people, that it's easy for such mistakes to creep in. Writing a single piece of code in C with no vulnerabilities is hard, but not impossible; maintaining such a piece of code, implementing complex and changing standards, over time, over a variety of platforms, and so on, without introducing vulnerabilities, does seem to be impossible in C.
Almost always by super-human's, though. These people that can do in programming what most people can't do across the board. Including write C code with almost no defects.
Now, what about mere humans with average or above average intelligence? What about us!? We can't be basing our expectations of what most can do with garbage like C on what the mental elite can pull off.
This is the thing - it's NOT super human. It's not even difficult. It's nothing more than learned behavior. I, for example, just had the advantage of having employers pay me to learn this stuff on the job.
Debugging a C++ template crash is difficult. Finding out why the Windows TCP stack does certain things is difficult. Writing clean and non-memory-over-writey 'C' isn't even close to those.
I have no idea what kinds of apps you're writing where it's that easy. Most apps with widespread use do complex things with code integrated in from many styles and skill levels of programmer. They have to get code cranked out quickly to meet deadlines. In the process, someone slips up with a pointer, array, whatever.
This has been true for many projects done by experienced C programmers. Hence, if not superhumans, then writing safe/secure C in such circumstances takes unusual talent. Whereas, it's effortless for people using something like Modula-3 to avoid most of those problems. By design. And checking for fools that turned it off is easy to automate: text search for "UNSAFE."
Hi nick! I don't know how to describe what it is I do. For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines.
Shipping bugs is always an option. I'm pretty adamant about not doing that any more than I have to. And I work fast enough that this isn't a problem - most of that is that I know how to code & test very quickly. But there's furniture in the code to check for the usual 'C' bug suspects.
And yes - "hell is other people's code." This is why I try very very hard not to leave these sort of bugs around, build test fixtures and do other things to defend myself. I have used static analysis now and again. It's kind of nice.
Again, and again, and again, dysfunctional organizations abound and it's possible to avoid them altogether. But first you must earn to identify them.
It would be absolutely fascinating to work with a security pro to see how I'm doing. Right now, that's not in the cards.
"For lack of a better rubric - "embedded". Frequently, large things are involved, large things with diesel engines."
That's actually pretty cool as I'm gradually learning more about embedded systems. The problem with subversion and INFOSEC was the hardware on up. Got ASIC methodology done. Gotta learn embedded. You do control systems, CAN's, and dashboards for construction hardware and 18-wheelers or something? Generators at datacenters? Ok, I'm running out of ideas as I only think about diesels so much.
re rest
It looks like your an outlier in my overall claim. The reason is that you've picked a field and specific companies that let you do pretty custom work that's mostly your code at the quality level you prefer. Good for you. It just doesn't negate anything I said about getting C right in general. Your circumstances and effort just make you an exception to the rule. :)
We'd chatted before - for some reason your handle is mnemonic :)
I'd just as soon not be specific if you don't mind. And in the past it's been wireless, data collecting, even point of sale. Longer past, databases and such.
Your last paragraph is spot on. I'm a tiny mote in the overall cost structure, there's a healthy risk aversion and lead times favor good practice. The downside is - I don't have much cover when things don't work.
I'm sympathetic to the plight of people dealing with this, and have the conceit ( probably misplaced ) that I can offer encouragement.
"We'd chatted before - for some reason your handle is mnemonic :)"
I figured but memory looses stuff. I tried to make my email handle mnemonic for lay people and technical alike. Rare success. It was accidental if it happened for nickpsecurity handle.
"I'd just as soon not be specific if you don't mind. And in the past it's been wireless, data collecting, even point of sale."
Wireless collection of emissions for Volkswagon[1]. Yes, I understand the need for confidentiality and keeping emails from the person giving the orders. We'll move along.
"there's a healthy risk aversion and lead times favor good practice."
Well, that's good. The lead times being an enabler for software QA is a good thing to remember. The "release early, release often" companies might be harder to get onboard with QA. Don't need glacial cycles but at least a few months to work out bugs on significant features.
Come on, if it were that easy we wouldn't have so many security bugs that can be directly traced to some memory corruption issue.
Do you think that for example the Firefox developers are either too stupid to do it right or that they just don't care about security or maybe that it's a harder problem than you claim it to be.
The Firefox developers are very good professionals that came to the conclusion that all the tools they devised to write memory safe C and C++ aren't enough for writing a safe browser and a new start in the form of Rust and Servo is needed.
The Firefox roadmap already has plans for incrementally add code written in Rust.
That's good news as I still use Firefox. Btw, are there any good docs or blog articles on how it integrates into C or C++ code so well? I don't often see that in new languages. Leads me to wonder if there's lessons to learn there for another project.
A lot of it is simply that Rust has an equivalent amount of runtime to C and C++, so you don't have two runtimes fighting with each other. For example, when Rust had green threads, interop was much worse, due to needing to switch to a C stack, as well as the actual initialization of the runtime itself. Without it, it's as straightforward as https://news.ycombinator.com/item?id=11622257
That's what I'm saying. I refuse to call people that build things like Firefox incompetent. Apparently, there's intrinsic difficulty to using the language both productively and carefully at the same time.
Note: Firefox is coded in C++, though. Rather than contradictory, that what you say is still true given C++ is a safer, more organized C they still can't use safely.
I am prepared to call anyone who ships bad code incompetent. We are ALL incompetent at some level, and perhaps on some days.
Narrow is the way. You have to look them in the eye and say "It's not ready. You can force me, but you will first provide documentary evidence of that force ( an email prints off just fine ) and by the way here's what you're risking and do try to keep up."
And I am dead serious, folks. This is what it will take. It will take each and every contributor making it his/her personal mission as if it was their Klingon honor. The culture right now doesn't even know how to ask for that.
Right now, it looks like we can barely even have a conversation about it.
Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting.
> each and every contributor making it his/her personal mission as if it was their Klingon honor
> Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting.
I'm curious to know why you apparently think the logistics of the first are feasible but the logistics of the latter daunting. To me there's a clear winner in logistical feasibility, and it's definitely not what you're suggesting.
I may be completely wrong, but the mental picture I have is all thse Linux distros and Windows installs in the whole world, and switching them over to OpenRustSSL from OpenSSL.
I'll stick with the Klingon honor thing - which is fully intended to be utterly hyperbolic. That's just what you can do personally - really polish that thing before it escapes. I know it's painful. But you have to tell your ego to sit that one out.
Well, at least Microsoft is doing their little bit by making C++ and .NET Native the way to go forward in the UWP world, with driver verification tools derived from theorem provers (Z3).
Apple by pushing Swift down developer throats that wish to target their platform (last year only Objective-C specific talks had Objective-C code on their slides).
Google, by making the Android NDK so anemic, that unless one really needs to use it for portable code or that extra performance step missing from ART, no one does it.
But I do concede that this will take a few decades to sort out, even if the IT world suddenly decided to go Ada/Spark/Rust today.
See my comment to parent with Astrobe link. That company put Oberon and IDE into embedded systems. Aside from integration with C libraries, it seems that a combo of rapid compiles, better safety, and better interface checks would lead to less cost in development and easier maintenance. Wait, we already know that with the likes of Go: a modernized Oberon. :)
"We are ALL incompetent at some level, and perhaps on some days."
I lost my memory in an accident. I can relate to the statement. Last time I tried to code something I cheated by defaulting to a subset of FreeBASIC with Cleanroom-style development. It worked the first time it ran. I didn't feel very competent, though, as I saw plenty of room for improvement. :)
""It's not ready. You can force me, but you will first provide documentary evidence of that force ( an email prints off just fine ) and by the way here's what you're risking and do try to keep up.""
Hell yeah! I've got piles of THAT. You can believe it. I try not to even do it coercively. More like telling them it's going to be a problem we can avoid together. It will be a mess if it happens. If forced, I want it in writing so the source of the problem is clear. Otherwise, just let me do it the right was as cost-effective as I can. As usual.
Something like that... can't remember...
"Right now, it looks like we can barely even have a conversation about it."
We can. It's just that the conversation has shifted. It was originally how likely a person could make arbitrary C applications probably sourcing 3rd-party components in haste without severe bugs coming from language weaknesses. That's kind of the default outside some jobs like yours. I was arguing it wasn't going to happen outside super-humans or at least high talent.
This tangent is about what a C programmer with a reasonable scope or chance of high-quality code can do in certain situations to make quality happen. We can have that conversation esp as each embedded person develops on tricks and tooling to eliminate problems. I'd be interested in any resources you have in terms of books, guides, or tools on robust C or embedded systems. I keep lists to pass along to people here and elsewhere that need them along with small chance I might use them.
"Id love to see Modula-<n>, or Rust, or anything else used. But the logistics of that are daunting."
Ada and SPARK already have serious, long-term deployment. Link below that's good even if you don't use them as it shows many problem areas in systems programming along with their solution. Many can be emulated in C with effort. The other is a port of Oberon to embedded systems with ARM Cortex MCU's and Oberon's benefits of course. Be interested in what you think of it at a glance or with hands-on trial to assess if more tools like that should be built. One person even put Ocaml on PIC's. Have fun with these. :)
I am very sorry to hear about your accident. That's terrible.
In your case, I'm sure it's in an advisory capacity/collegial and not an "or else." Just saying - don't ship until youre sure. The cost-gods favor it.
I should probably think about compiling a set of book-style resources to recommend. Seems a bit pretientious, though.
I do think the embedded community should embrace better tools. But I dunno. This will be difficult - sort of a "science only improves one funeral at a time" thing...
> I do think the embedded community should embrace better tools. But I dunno. This will be difficult - sort of a "science only improves one funeral at a time" thing...
To add to the list from nicksecurity, there are other vendors that keep Basic and Pascal compilers alive all the way down to PICs.
"I am very sorry to hear about your accident. That's terrible."
Appreciate it. Totally sucks. Oh well. I'm at least helpful here and elsewhere if not fully operational in INFOSEC market. Working in that direction.
"I should probably think about compiling a set of book-style resources to recommend. Seems a bit pretientious, though."
Ganssle's Embedded Muse has been my main source. He's published a few of my recommendations like I/O coprocessors (or MCU cores) to aid real-time by soaking up interrupts. A few others suggested some books I got. One person made a nice list of blog posts covering various entries. It's really scattered.
So, I wouldn't say pretentious if you were merely sharing resources that helped you in case they help others. Along with what specifically was helpful about each one.
They're not incompetent, they're just developing a web browser. Which means using all kinds of gnarly bleeding-edge optimization techniques that introduce massive complexity just to get Twitter to display 140-byte messages with reasonable performance, not to mention dozens of nasty parsers for nasty data formats. Basically, what I'm saying is that the web sucks. I think web browsers are probably more complex than operating systems at this point.
I totally agree. That's the kind of complexity and BS that developers often have to deal with which I'm referring to. Hard to imagine an unsafe by default language not breaking eventually.
> is pretty good proof that nobody can write secure C.
I came to that same conclusion. I used to almost romanticize C programmers years ago, but years and years of reading things like this have changed my mind.
That doesn't look like a C specific error to me. In the release notes CVE-2016-2107 is listed as a padding oracle attack. Padding oracles are a logic/design error that is not easily caught by any language feature.
CVE-2016-2108 on the other hand looks like a typical C style memory corruption bug.
