4 ms·

> One of my coworkers fleshed out an important and complex component that absolutely had to be logically correct, by using TLA+ modelling. This is nothing to d

> One of my coworkers fleshed out an important and complex component that absolutely had to be logically correct, by using TLA+ modelling. This is nothing to do with you or your statement, but this is the pre-eminent issue in our industry. Everything absolutely has to be logically correct or we expose users to flaws in both security and stability that can in extreme cases be the difference between life or death and in regular cases be the difference between being cracked or not.

nickpsecurity 11y ago
That's an exaggeration by far: only the tiniest subset of systems can kill people if they fail. Hacks happen by the millions with headaches being the main result along with lost time and money. Even most security-critical systems are the same with the main targeting being done for espionage (data theft). High assurance security focuses on what can get people killed (esp military use) with an emphasis on tools such as these. I've never seen a mainstream FOSS or proprietary product show evidence of an EAL6+ development process, though. Even security community largely throws stuff together plus some code review. Best to keep it real about risks so your solutions match requirements. Most companies are happy to sell patches to broken software or offer software that passed many checklist items for compliance. They have lawyers for the rest.
- texthompson 11y ago
  Totally agree. Both correctness and security are important, but they're not the only concerns in developing useful software.
- socceroos 11y ago
  > That's an exaggeration by far: only the tiniest subset of systems can kill people if they fail. Hence calling it an extreme case. > Hacks happen by the millions with headaches being the main result along with lost time and money. ...which is a good reason to make software correct. However, I'm not arguing about the ROI and efficiency of attaining absolute correctness; my point is that software should be correct. Ideally. We're happy to settle for somewhere on the low side of correctness, but I don't think that is necessarily healthy or good for the industry.
  - nickpsecurity 11y ago
    I agree that ideally we should set our baseline much higher. It's why I promote low-defect methodologies, code reviews, static analysis, and languages (eg Ada, Haskell) that prevent/catch most problems early. The few empirical studies done on such things show it actually saves money with occasional productivity boost for one reason: huge reduction of debug time. And the satisfied customer effect can't be ignored. ;)

nickpsecurity 11y ago

That's an exaggeration by far: only the tiniest subset of systems can kill people if they fail. Hacks happen by the millions with headaches being the main result along with lost time and money. Even most security-critical systems are the same with the main targeting being done for espionage (data theft). High assurance security focuses on what can get people killed (esp military use) with an emphasis on tools such as these. I've never seen a mainstream FOSS or proprietary product show evidence of an EAL6+ development process, though. Even security community largely throws stuff together plus some code review. Best to keep it real about risks so your solutions match requirements. Most companies are happy to sell patches to broken software or offer software that passed many checklist items for compliance. They have lawyers for the rest.

texthompson 11y ago
Totally agree. Both correctness and security are important, but they're not the only concerns in developing useful software.
socceroos 11y ago
> That's an exaggeration by far: only the tiniest subset of systems can kill people if they fail. Hence calling it an extreme case. > Hacks happen by the millions with headaches being the main result along with lost time and money. ...which is a good reason to make software correct. However, I'm not arguing about the ROI and efficiency of attaining absolute correctness; my point is that software should be correct. Ideally. We're happy to settle for somewhere on the low side of correctness, but I don't think that is necessarily healthy or good for the industry.
- nickpsecurity 11y ago
  I agree that ideally we should set our baseline much higher. It's why I promote low-defect methodologies, code reviews, static analysis, and languages (eg Ada, Haskell) that prevent/catch most problems early. The few empirical studies done on such things show it actually saves money with occasional productivity boost for one reason: huge reduction of debug time. And the satisfied customer effect can't be ignored. ;)