Hi Stas, On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> > constraints. Type check is one of them. There are many people argue "This > > language is secure and robust because it has _static_ types". > > These people are wrong. Languages can't really be secure or robust, only > code implemented in these languages can, and we have witnessed many > examples of vulnerable code written in pretty much any widely used > language. Having strict typing may protect against some very basic > errors, but in well-designed and well-tested software such errors would > be rare, and in badly designed software type strictness would not save you. > I agree partially. DbC encourages users to adopt secure coding best practices. Over all input/output must be controlled by programmers. This is secure programming best practice described in many security standards/guidelines. DbC encourages it. As you mentioned, well designed softwares do not have issues. DbC does not solve issues directly, but encourage good design. As a result, program becomes more secure/robust. If one have good design already, they don't have to adopt DbC for better design. > > > Here comes DbC, once we have contracts for pre/post conditions. We are > > safe from calling functions with invalid parameters during development, > yet > > we have optimum performance for production since there is zero contract > > checks > > with production mode including opcode. > > That assumes perfect test coverage in development, both code-wise and, > more importantly, data-wise. Which is impossible. While having assert > primitives that can be turned on and off looks like a useful concept to > me, I don't think it is some kind of magic solution that will change > everything. Over all input/output controls are important for all application. This is "MUST requirement" for DbC design to be successful. With DbC, functions called in deep call chains will not check input validity in production mode. Therefore, DbC adopters must control over all inputs at appropriate place (right after input was available to programmers) which is security best practice. Misuse of DbC increase risks in fact. DbC requires good design, too. It's not an automatic solution as you describe. Thank you for bring this topic. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
