Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82323
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.42 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54D94FB4.6090004@gmail.com>
References: <CAH8MpnncAZ1UAaWyPaU8ZL7yDMXbas39X2sssK0yUONGTXxL6Q@mail.gmail.com>
 <CAGa2bXa6ERO4RJO2ujWGVUMOJxz8NRfpkg_F69An_bp4Yt4=JQ@mail.gmail.com> <54D94FB4.6090004@gmail.com>
Date: Tue, 10 Feb 2015 09:47:39 +0900
Message-ID: <CAGa2bXbyNTY69ju1PZBdKPJazsbnEJPm-BVb3pkK=vYHij2EfA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11337bfc35026e050eb13ec0
Subject: Re: [PHP-DEV] Re: Design by Contract
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11337bfc35026e050eb13ec0
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Tue, Feb 10, 2015 at 9:24 AM, Stanislav Malyshev <smalyshev@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
yohgaki@ohgaki.net

--001a11337bfc35026e050eb13ec0--