Hi,
All extensions in php-src are PHP 3.01 Licensed
(libs may, of course, have different license)
Is there any strong rule about this ?
Or is it OK to have a BSD Licensed extension ?
Context: see sodium PR
https://github.com/php/php-src/pull/2560
IMHO, make sense to have only PHP Licensed ext.
2017-06-13 7:20 GMT+02:00 Sebastian Bergmann :
> Thinking about https://github.com/sebastianbergmann/environment/issues/21
> it just occured to me that PHP_OS_FAMILY currently contains "OSX".
>
> Apple renamed (last year?) their "OS X" to "macOS". Should PHP_OS_FAMILY
> not contain "macOS" then? N
Thinking about https://github.com/sebastianbergmann/environment/issues/21
it just occured to me that PHP_OS_FAMILY currently contains "OSX".
Apple renamed (last year?) their "OS X" to "macOS". Should PHP_OS_FAMILY
not contain "macOS" then? Now would be the time to make that change
without breaking
Results for project PHP master, build date 2017-06-11 19:24:08-07:00
commit: f6ac96b
previous commit:f2bf00b
revision date: 2017-06-11 17:27:32+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Despite providing class whitelisting [1] and documentation about warnings
about security impacts [2], we continue to see vulnerable uses of
unserialize() in Drupal modules [3] and partially effective attempts to
mitigate vulnerabilities from user-supplied, serialized data [4].
Whitelisting legal c
Hi everyone,
proposed PR https://github.com/php/php-src/pull/2080 was rebased before
variance patch and adjusted to current master implementation.
Currently waiting for merge.
Thanks everyone for voting.
regards,
--
Michał Brzuchalski
2017-06-03 12:54 GMT+02:00 Nikita Popov :
> On Wed, May 17,
Hi, I'm David Strauss (with wiki username dts). I'm a member of various
Drupal teams, including the security team, and I'd like to create an RFC to
provide additional mitigation options for vulnerabilities related to
unserializing data. I perform other work related to PHP internals, but it's
mostly
