Hello!
The PHP development team announces the immediate availability of PHP
5.5.28. 12 security-related issues in PHP were fixed in this release.
All PHP 5.5 users are encouraged to upgrade to this version.
For source downloads of PHP 5.5.28 please visit our downloads page:
http://www.php.net/d
Hello!
The PHP development team announces the immediate availability of PHP
5.4.44. 11 security-related issues in PHP were fixed in this release.
All PHP 5.4 users are encouraged to upgrade to this version.
For source downloads of PHP 5.4.44 please visit our downloads page:
http://www.php.net/d
> On Aug 6, 2015, at 3:52 AM, Niklas Keller wrote:
>
> Scott, could you setup a RFC with a vote, so we can decide?
>
> Nikita proposed those two options:
>
>> 1) Error is to be used in cases where an error is attributable to
>> programmer mistake.
>>
>
>
>> 2) Error signifies a failure cond
On Fri, Aug 7, 2015 at 10:29 AM, Yasuo Ohgaki wrote:
> Even if there is identifier placeholder, SQL keyword remains.
> So to be perfect, you'll need another place holder for SQL keywords.
> There is no escaping for SQL keywords and it has to be validation.
> e.g. ORDER BY {$_GET['order']}
>
Oop
Hi Matt,
On Thu, Aug 6, 2015 at 12:46 PM, Matt Tait wrote:
> I'll take a few of your points in turn.
>
> With regards to the fact that not all SQL queries are directly
> parameterizable, this is true. Structural parts of a query, such as table
> names, column names and complex conditions are har
Thanks for the feedback Anthony,
This feature specifically addresses the points you raise; the feature allows
parameterized queries constructed with structural parts of the query inserted
from configuration variables, so long as the resulting query is a safe-const as
defined by this RFC.
If yo
Matt,
> You are of course welcome to disagree with the overwhelming body of security
> advice that parameterized queries are the correct, secure way to prevent SQL
> injection. In that case, you only need to not enable this feature. This
> feature is off-by-default, and only attempts to help secur
Hi all,
Is there zend_string usage guideline?
I'm wondering if zend_string is used where it is appropriate.
Once we release PHP7, adopting zend_string for PHPAPI functions become
difficult.
(We have to keep legacy API or it will be 3rd party module author's
headache if we
change this with minor v
Hi,
as we put several verification info into the announcement mails, and after
doing it a couple of times manually, I've invented this quick solution.
https://gist.github.com/weltling/2d2972aa5325ee3b530c
I would suggest to take it into the scripts/ and to adjust the corresponding
release proces
Hi,
The third beta for 7.0.0 was just released and can be downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains fixes for 33 reported bugs, 11 of which are security
related, and altogether over 200
commits
Hi Matt,
Am 06.08.2015 um 05:46 schrieb Matt Tait:
> With regards to the fact that not all SQL queries are directly
> parameterizable, this is true. Structural parts of a query, such as table
> names, column names and complex conditions are hard to parameterize with
> "vanilla" prepared statements
Hi Pierre,
- Original Message -
From: "Pierre Joye"
Sent: Thursday, August 06, 2015
On Aug 6, 2015 1:49 PM, "Matt Wilmas" wrote:
Hi Levi,
- Original Message -
From: "Levi Morrison"
Sent: Thursday, August 06, 2015
Don't know about Windows now... Visual Studio 2008 and 201
Scott, could you setup a RFC with a vote, so we can decide?
Nikita proposed those two options:
1) Error is to be used in cases where an error is attributable to
> programmer mistake.
>
2) Error signifies a failure condition that the programmer is discouraged
> (and unlikely to want) to handle.
Results for project php-src-nightly, build date 2015-08-06 10:30:35+03:00
commit: 2eaf28367dd5da282156f567f8dbc031a4dbb2c2
revision_date: 2015-08-05 12:04:26-07:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
On Thu, 6 Aug 2015 00:55 Scott Arciszewski wrote:
All,
I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are *the
worst*).
Here's a quick recap
Argument
On Aug 6, 2015 1:49 PM, "Matt Wilmas" wrote:
>
> Hi Levi,
>
>
> - Original Message -
> From: "Levi Morrison"
> Sent: Thursday, August 06, 2015
>
>>> Don't know about Windows now... Visual Studio 2008 and 2012 (not much
>>> difference) are NOT optimizing away the code (other times it was G
16 matches
Mail list logo
