Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62934 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 11239 invoked from network); 10 Sep 2012 22:23:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Sep 2012 22:23:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:37903] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C5/B2-26944-6686E405 for ; Mon, 10 Sep 2012 18:23:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 86110802B1; Mon, 10 Sep 2012 18:23:31 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C7C6080366; Mon, 10 Sep 2012 18:23:30 -0400 (EDT) Message-ID: <504E6862.4080608@sugarcrm.com> Date: Mon, 10 Sep 2012 15:23:30 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Hannes Magnusson CC: Anthony Ferrara , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Add simplified password hashing API From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > The benefit is that it can be tested properly and bugs discovered and > ironed out first. > This is not the sort of thing you want to get security bug reports the > day after its released in core. > If your ego is big enough you can guarantee you have tested this > thoroughly and want it to become the recommended way.. You have to be > damn sure you don't fuck it up. > > This is exactly the sort of thing that doesn't need to be developed in > the core tree, but can later be merged in once proven successful. I see you point, and indeed, if we recommend something as a one-stop shop for security-sensitive area, we better be sure we do it right. But: are we really going to get enough testing if we put it out as PECL module? Also, we're not releasing 5.5 tomorrow, so we can have a lot of testing before. But if it's a non-core module, adoption would be much lower since apps could not rely on it being there even in 5.5. OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not everybody is going to upgrade to 5.5 soon, so having them participate would be good too. Maybe we could do it as a module and have it workable as PECL too for those who are not on 5.5? PHP solution is not really the same - if we have two separate codebases, nobody can be sure they actually do the same thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227