F2FS Hit By Three Security Vulnerabilities: Memory Corruption, Possible Code Execution

[caligula]

no. The answer is make decent automated testing suites and running them very often and fix up the shit that crops up.

Rust is better than C but you need automated testing anyway.

Instead of automated testing, people should learn property based testing. It's like automated testing on steroids. Instead of 10 or 100 test cases you make one and the system deduces how many are needed. It's like build time fuzz testing, yet much cheaper like all static analysis methodologies.

[caligula]

This is interesting right. Rust will prevent some errors but not them all. Even with rust we will need static analysis tools.

The truth is, people wrote buggy code, people are writing buggy code as we speak, people will write even more buggy code in the future. There is a constant flow of new bugs as old software becomes obsolete and new stuff hits the shelves. This process is broken by design. Better languages and static analysis tools are pretty much the only hope we have unless this "cowboy coding" style will stop and people begin to expect formal methods from any normal sw project. Types are a lightweight version of formal methods. Developers should learn to embrace them.

[oiaohm]

The truth is, people wrote buggy code, people are writing buggy code as we speak, people will write even more buggy code in the future. There is a constant flow of new bugs as old software becomes obsolete and new stuff hits the shelves. This process is broken by design. Better languages and static analysis tools are pretty much the only hope we have unless this "cowboy coding" style will stop and people begin to expect formal methods from any normal sw project. Types are a lightweight version of formal methods. Developers should learn to embrace them.

New languages for what. Sel4 uses C for it code and new language for writing formal proofs to make sure the C code contains no defects. There is the question of do we need to leave C or do we just need way more solid development processes. Sel4 says that more solid development processes can work and that means not having to dump the mountains of legacy code just fix the legacy code up.

I do give sel4 and other data61 works as examples of how formal mathematically secure development can be done. Looking to a programming language as a magic bullet to problems is wrong. Looking to have high quality testing and formal proofs of quality should be the goal. Even using rust you should still have formal proofs of the logic in your for the code to be secure. Reality you can choose any program language you like as long as you do the formal proofs and the proper testing the resulting program will be secure and bug free.

This is what pisses me off about people saying why don't use rust. Rust is a very limit solution and if you depend on rust and don't do the formal proofs and testing time will go forwards and rust code will become the new home to bugs like C has been. End result change very little.

Now if we change people mind set to doing software development so they do it right then we will get somewhere.

[bug77]

no. The answer is make decent automated testing suites and running them very often and fix up the shit that crops up.

Rust is better than C but you need automated testing anyway.

Is there ever time for proper or even decent automated testing?

[linuxgeex]

Is there ever time for proper or even decent automated testing?

ROFL, well said.

There's an expression, when it comes to software development you can have fast, good, and cheap: pick any two.

OSS project maintainers usually have to pick "good" and "cheap" because they don't have the money to ensure the manpower or the skill sets which could make development fast on their budget. Ensuring "cheap" is pretty easy when you have a $0 budget. So then ensuring "good" becomes their primary responsibility. All languages are equally secure if we take the time to design, implement, and test. Picking a language with a crutch such as automatic type safety doesn't ensure "good". Test Driven Development ensures "good". Specifying that the project shall have a comprehensive test suite and no code shall be merged which doesn't extend and pass that test suite appropriately. People generally don't naturally enjoy double checking their work. If you have some enthusiastic contributors who really don't understand the processes and value of TDD, then the maintainer is going to have to mentor/encourage their contributors, or the maintainer is going to have to do the testing themselves, which is typical. I remember acutely, and with some embarrassment, how much I relied on Hans de Goode when I first began contributing to one of his projects in the mid 90's. Luckily his patience matched my enthusiasm. :-)

Automated testing is a crutch too. Just because something passes lint and build and a test suite doesn't mean it doesn't have backdoors or errors. There's no substitution for vigilance.

[garegin]

No one said to throw code away. Rust is a good idea if you are starting a new project. no one is holding their hand from using testing tools. C apologists are like people who drive a Ford Pinto and say that we need safer driving.

[bug77]

ROFL, well said.

There's an expression, when it comes to software development you can have fast, good, and cheap: pick any two.

That's not about software development, that's management's iron triangle: https://en.wikipedia.org/wiki/Projec...ement_triangle

As for your other arguments, I deal with the "we have tests that can be run on demand, thus we must have unit tests" or "it's too expensive to do code review" mentality way too often to want to think about it again.

[linuxgeex]

That's not about software development, that's management's iron triangle: https://en.wikipedia.org/wiki/Projec...ement_triangle

As for your other arguments, I deal with the "we have tests that can be run on demand, thus we must have unit tests" or "it's too expensive to do code review" mentality way too often to want to think about it again.

I first heard this from 'fortune', googled it, and found the Arthur C Clarke reference, which was about software development. Handily today I can also find that on Wikipedia.

There's also this:


captioned "The First Law of Software Development". And it goes on to make all the same points you and I are making, lol.

One of the best analogies I enjoy is the programmer turning to the project manager and saying "I'm your doctor. I've diagnosed you with malignant testicular cancer, you have 2 months to live if it isn't removed immediately. My intern can try it this week, or you can book me for next week. Oh, you'd like a discount? I think I might have a free spot 3 months from now."

[linuxgeex]

No one said to throw code away. Rust is a good idea if you are starting a new project. no one is holding their hand from using testing tools. C apologists are like people who drive a Ford Pinto and say that we need safer driving.

LOL. They're not wrong, we do need safer driving, and safety is the responsibility of everyone on the road, but yeah some people deserve to win a Darwin Award as a result of their choices, I just hope they don't take me with them.

[garegin]

The point is that we are already "being responsible". The big names like MS, Google and HP are already running every fuzz test and memory profiler and we still have security holes. All things being equal we need safer languages. C fans are strawmanning Rust advocates that we think safer languages are a cure all. They are NOT. About 70% of holes are memory errors. The rest are probably not gonna be caught with static analysis.
We are forgetting that not every dev is a security nut/programming enthusiast. My aunt has been programming in C++ since late 80s and didn't even know what lint is. The testing is probably done by a different team.
there's also gonna be trashy code written for some Taiwanese webcam. In fact most code is of subpar quality.