On 15 March 2015 at 13:17, Pádraic Brady padraic.br...@gmail.com wrote:
Were folk to use random_int() by default, it would be actually be
considerably better than the situation today where many reach for
mt_rand() without really considering the use case. Using a strong
source of ints instead
On 15 March 2015 at 19:24, Zeev Suraski z...@zend.com wrote:
I don't think you understand the meaning of unity, but I'll let internals
be
the judge of that.
Judging.. judging..
https://www.youtube.com/watch?v=bjEmHAeE4DYt=1158
On 15 March 2015 at 22:56, Stanislav Malyshev smalys...@gmail.com wrote:
if
running PRNG for too long is dangerous, wouldn't we already have much
more serious problem with encryption routines based on them which
basically do it all the time?
Indeed we would, it's the kind of issue that
On 15 March 2015 at 21:09, Admin Admin ad...@codeangel.org wrote:
I'll need some help with the patch. I took a look at it once, and since my
C skills are abhorant, I found myself scratching my head at all the places
that seem to throw the error message above and what each of them did. So if
oppose the RFC simply on this issue alone.
Cheers,
Leigh.
On 13 March 2015 at 17:24, Marcio Almada marcio.w...@gmail.com wrote:
Hi,
2015-03-13 12:45 GMT-03:00 Anthony Ferrara ircmax...@gmail.com:
All,
[...]
I respectfully ask Zeev to retract his current proposal as it's
currently failing
On Mar 13, 2015 10:36 PM, Pierre Joye pierre@gmail.com wrote:
So law is firm when it fits your goal but flexible when not? We have
relatively strict rules for this exact reason: nk double standard. Stop
playing with the rules and stand as someone willing to find compromises.
Totally with
On 14 March 2015 at 02:50, Rasmus Lerdorf ras...@lerdorf.com wrote:
The problem there is what does without dataloss mean? At which precision do
you consider there to be no dataloss?
-Rasmus
without dataloss would mean you can go from typeA - typeB - typeA'
and typeA === typeA'
--
PHP
On 11 March 2015 at 18:46, Eli e...@eliw.com wrote:
Benoit ... actually Anthony's original proposal specifically was
designed to be live at the same time as this alternative proposal. And
it's even mentioned in the proposal (stating that it would stay open
until the 13th or when the
On 1 March 2015 at 11:29, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it
On 3 March 2015 at 11:56, Alexander Lisachenko lisachenko...@gmail.com wrote:
Good morning!
I have cleaned https://wiki.php.net/rfc/parser-extension-api and restricted
it's scope only to the parsing API. Extension API can be implemented later
+1
on top of
On 1 March 2015 at 03:32, Stanislav Malyshev smalys...@gmail.com wrote:
I don't see why the first one needs any vote. It is supposed to be
implemented as an extension, so why not go and implement an extension,
and put it in PECL, and then propose it for core inclusion, if it proves
popular?
On 27 February 2015 at 21:14, Tom Worster f...@thefsb.org wrote:
1. You say it doesn't leave any room for interoperability but I'm
not sure I agree. I invite you again to look at the Cryptography lib
for Python.
There are countless applications/services that will do things their
own way, and
On 27 February 2015 at 08:20, Leigh lei...@gmail.com wrote:
Looking through git blames, this property has been protected for a long time.
Possibly related (although not at all sure), Dmitry made some changes
to zend_read_property()
https://github.com/php/php-src/commit
On 27 February 2015 at 08:06, Sebastian Bergmann sebast...@php.net wrote:
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
On 26 February 2015 at 15:37, Tom Worster f...@thefsb.org wrote:
On 2/26/15, 3:48 AM, Stanislav Malyshev smalys...@gmail.com wrote:
The custom is that the first word names the function group (yes, I know
old functions do not follow it, but this is new one). Unless we're going
to introduce a
On 26 February 2015 at 16:07, Stefan Esser stefan.es...@sektioneins.de wrote:
Hi,
libgcrypt does at least have a maintainer but it's poor
Werner Koch who is so destitute he lives on charity raised
on Kickstarter and has his work cut out just trying to deal
with GPG: http://is.gd/cbHCYO
On 26 February 2015 at 15:04, Tom Worster f...@thefsb.org wrote:
I actually started down this RFC path out of frustration on this very
point of needing secure random alphanumeric stings. The originally RFC
patch contained a `random_hex()` function that would convert bytes from
the CSPRNG into
result. An
example use-case brought up recently was in the case of online games,
where a bias could give players an upper hand if they knew the
subtleties of the underlying RNG.
Thank you for your feedback!
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Might as well mention it because it has been discussed OTR.
We've thrown the idea around that we could cater for other sources of
random via a PHP extension. (I.e. if someone has a particular hardware
RNG they want to use). We're concerned that this may be misused, or
even abused as a way of
On 25 February 2015 at 20:24, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
For example, the number of users that actually need to do something
better than read from /dev/urandom is small. A user that is concerned
Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
On 25 February 2015 at 09:09, Zeev Suraski z...@zend.com wrote:
Leigh,
There isn't a weak-only proposal on the table. There's the original one
(dual mode) and the coercive one. Both have both strict and dynamic
elements in them.
I think that what Anthony proposed about a week or so ago
On 25 February 2015 at 10:43, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Anyway, Zeev's proposal is much better. IMHO. Since we don't
have RFC owner for older proposal, we may only have vote for
Zeev's proposal.
Did I miss something? Pretty sure Anthony is still owning the proposal
he has put
On 24 February 2015 at 20:54, Pierre Joye pierre@gmail.com wrote:
On Feb 24, 2015 12:04 PM, Anthony Ferrara ircmax...@gmail.com wrote:
PERHAPS, it could be written in such a way that a PECL extension can
alter the RNG to accommodate that usecase. But I'd be wary of that and
core supporting
On 24 February 2015 at 10:55, Pierre Joye pierre@gmail.com wrote:
It should use the session.entropy_file setting as it aims to be the exact
same thing. It also allows custom entropy src (better ones for higher
demands) as well.
I disagree. We want to take responsibility away from the user
Leigh can say more about this if I'm missing something.
You're absolutely right, on modern releases of systems like OpenBSD
and OSX /dev/urandom is simply an alias of /dev/arandom. The problem
is, I'm not an expert in _every_ version of _every_ OS, and it might
not always be the case that this aliasing
On 23 February 2015 at 21:15, Albert Casademont Filella
albertcasadem...@gmail.com wrote:
I like it! That's what I proposed to Anthony (and Andrea before) before
Zeev presented their alternative, to held a double vote on the strict vs
weak feature. It was not met with much enthusiasm, hope they
I've been having a play around with the implementation, and it's been
behaving pretty solidly, nothing unexpected so far.
I've even gotten around my issue regarding no strict-by-default option
for those of us who want it.
Maybe this will sway a few voters. I'll put the source up if this
On 24 February 2015 at 19:23, Thomas Bley ma...@thomasbley.de wrote:
I think this is a huge bc break that will affect many applications. For
example:
// test.php
error_reporting(E_ALL ~E_NOTICE);
echo $_GET['value'];
curl http://.../test.php?value=foo // ok
curl
On 20 February 2015 at 08:47, Markus Fischer mar...@fischer.name wrote:
This sounds two-folded to me: very cool (albeit I can't see a use-case
right now) on one hand and utter magic on the other.
Inclined to agree.
@Joe what use-case prompted this feature?
--
PHP Internals - PHP Runtime
naming.
empty_expressions ... I'll give you an empty expression!
But overall +1 on functionality and patch.
Cheers!
Leigh.
On 21 February 2015 at 05:11, Thomas Punt tp...@hotmail.co.uk wrote:
Hello Internals!
The following RFC aims to make empty() have a variable arity:
https://wiki.php.net/rfc
On 19 February 2015 at 15:45, Pierre Joye pierre@gmail.com wrote:
Still, no announce for a discussion about this specific RFC. And
really, the content of the RFC is almost empty, pointing to the ML
archive is really not the right way :)
There was an RFC announce thread 3 days ago. I agree
On 18 February 2015 at 21:50, Anthony Ferrara ircmax...@gmail.com wrote:
Static Analysis Is Possible With Weak Declarations
The advocacy of allowing `accepts_float(returns_int());` doesn't help
the cause of static analysers in strict mode.
Java does exactly this and is statically analyzable.
On 18 February 2015 at 20:44, Anthony Ferrara ircmax...@gmail.com wrote:
Dear Internals,
Since the resignation of Andrea, the mixed-mode type hint (called
declaration in the proposal) proposal has been left abandoned.
Considering that the ending votes were 67/34 (66.3%) with several
no-votes
On 18 February 2015 at 13:18, Rowan Collins rowan.coll...@gmail.com wrote:
This leaves us in a state where some functions will have defined types
with their aggressive coersion rules and some will not, and we can't
expect users to remember which set of functions have been updated or
not.
On 18 February 2015 at 14:40, Lester Caine les...@lsces.co.uk wrote:
But my favourite is still
'\143\141\164' == \143\141\164 which is false, but I doubt many would
know why?
Pretty sure one of the first things PHP devs learn is that single
quoted strings only accept \' and \\ as escape
On 17 February 2015 at 22:03, Sara Golemon poll...@php.net wrote:
Based on conversations here and elsewhere on the internet, I'd like to
put forward a rough gameplan for scalar types which I hope addresses
most concerns. This is back-of-the-napkin and I'm not asking for a
committed yes/no,
On 18 February 2015 at 22:21, Albert Casademont Filella
albertcasadem...@gmail.com wrote:
So I propose 3 voting options: Yes (strict), Yes (weak), No. The Yes votes
combined need 2/3 of the votes. Then a simple majority of 50%+1 between the
different Yes votes is needed.
This is pretty flawed,
On 17 February 2015 at 05:48, Sara Golemon poll...@php.net wrote:
We can sigh and tut about this not being the PHP way, but the script
author was the one who chose to enter into a tight contract, and the
script author, not you, is the one who should have that authority over
their own
On 17 February 2015 at 11:46, Alexander Lisachenko
lisachenko...@gmail.com wrote:
Hello, internals!
I want to introduce a RFC for providing a userland API for accessing an
Abstract Syntax Tree of the source code and to provide userland parser
hooks for source code modification:
On 17 February 2015 at 17:35, Tim Bezhashvyly tim.bezhashv...@gmail.com wrote:
Dear PHP internals,
this is my first RFC proposal and I am not sure if in this email is supposed
to contain all RFC details or just a brief idea .. which is to drop PHP
constants in favour of “final immutable
On 17 February 2015 at 12:22, Alexander Lisachenko
lisachenko...@gmail.com wrote:
Yes, parser extensions will be called for all require/include/evals after
registration. This part is transparent for opcache, because opcache just
stores an opcodes for the file. AST is parsed only once for each
On 15 February 2015 at 02:46, Andrea Faulds a...@ajf.me wrote:
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this
RFC. The implementation isn’t finished, but the remaining work isn’t
impossible to surmount (though help would certainly be appreciated).
On 15 February 2015 at 13:51, Andrea Faulds a...@ajf.me wrote:
Extensions that deal with numbers are all going to need updating. So
probably every extension?
Anything accepting a zval rather than a long through zpp, but the changes are
quite small in most cases. It’s a much smaller change
On 14 February 2015 at 00:32, Benoit Schildknecht bensor...@neuf.fr wrote:
I don't think EngineException should inherit from Exception, it would be
very dangerous. I'm sure a lot of exceptions are handled like this by a lot
of devs, without creating custom exceptions :
Agreed, EngineException
I don't think there is time to get something finalised for 7.0, I
certainly wouldn't want anything cryptography related to be rushed, so
this is a pre-RFC discussion to gather ideas and opinions for
something we can work towards in PHP 7.1 and that can live as a PECL
extension between now and
On 10 February 2015 at 21:38, David Muir davidkm...@gmail.com wrote:
Does this mean PHP will be taking on the role of maintaining libmcrypt as
well?
That's not what it means, no.
If a security issue is found, what is the course of action?
Well, what happened when there was vulnerabilities
On 10 February 2015 at 23:29, Paul Dragoonis dragoo...@gmail.com wrote:
It's common sense that if something receives significant resistance then
there's usually a good reason for it and it shouldn't be ignored regardless
of how mathematically accurate it may seem to exclude it. Let's keep MSSQL
On 8 February 2015 at 17:03, Pierre Joye pierre@gmail.com wrote:
I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
keep it around for BC. I simply do not have the resources to make that
happen so someone has to jump on it (Derick?)
Are we happy to accept that we'll
On 6 February 2015 at 12:02, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
This RFC was renamed from script() and script_once().
Original proposal had defect. It wasn't perfect.
This RFC proposes script_path INI directive to eliminate
file/script inclusion at all via require().
On 5 February 2015 at 05:37, Adam Harvey ahar...@php.net wrote:
I'm not totally clear on what this RFC is proposing, honestly. Is the
new script statement meant to only include files that are entirely
wrapped in ?php and ? tags? Are files included that way assumed to
be PHP and don't require
On 5 February 2015 at 10:24, Pierre Joye pierre@gmail.com wrote:
I do understand what you try to achieve, from all point of view.
However I strongly disagree with this as a security improvement. I see
this more as yet another attempt to replace what should be done at the
OS level.
I'm
On 4 February 2015 at 11:02, Florian Margaine flor...@margaine.com wrote:
Because it is then the callee who decides, not the caller, whether or not he
wants strict typing.
And that is the way it should be.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
What was wrong with:
function x(int $y, string $z) { // strict
function x((int) $y, (string) $z) { // casting
This was the best suggestion I've seen that covers the requirements of
both camps, and is still very clear how data is going to be handled.
Authors who want their APIs to adhered to
On 4 February 2015 at 09:03, Stanislav Malyshev smalys...@gmail.com wrote:
I'd rather not mangle supplied data in such sensitive area. If it's
wrong, then it's wrong.
Agreed with this approach.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 3 February 2015 at 14:36, Andrea Faulds a...@ajf.me wrote:
I don’t know where you got that idea. The binary ops are consistent - they
aren’t constrained by register size like in previous PHP versions, but
they’re still completely consistent.
php -r 'var_dump(1 65);'
int(2)
Rotate left
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote:
Why would it be promoted?! The high bit is the 63rd bit. It fits within a
long.
I'm assuming your bigint implementation would want to respect signage.
When does it promote? 63rd to preserve signage?
4611686018427387904 // 1 62 -
On 3 February 2015 at 14:49, Andrea Faulds a...@ajf.me wrote:
It’s not “broken”, the behaviour is just different to account for it now
being an arbitrary-precision type.
That's pretty much the definition of a BC issue.
Also, the bigint changes only affect you if you’re dealing with large
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote:
Why would it be promoted?! The high bit is the 63rd bit. It fits within a
long.
because
On 3 February 2015 at 16:08, Andrea Faulds a...@ajf.me wrote:
$ sapi/cli/php -r '$x = 1 63; debug_zval_dump($x);'
Hi list,
How do we feel about a zero-fill right shift operator?
PHPs current right shift operator preserves signage, but this is not
always desirable.
I propose the same syntax as JavaScript for this:
php -r 'var_dump(-256 8);'
int(-1)
php -r 'var_dump(-256 8);'
int(16777215)
This will
On 3 February 2015 at 13:25, Andrea Faulds a...@ajf.me wrote:
Hmm, how would this interact with bigints? Does it rely on fixed-width
integers, as it appears to? :/
No idea. Personally I'm opposed to the bigints implementation because
of the implicit type auto-promotion.
--
PHP Internals -
This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7.
That should have been T_SRZF, and I suppose I would also have to add
= (T_SRZF_EQUAL) which looks nasty, but should be included for
completeness.
--
PHP Internals - PHP Runtime Development Mailing List
To
On 3 February 2015 at 13:54, Andrea Faulds a...@ajf.me wrote:
Hi Leigh,
On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote:
No idea. Personally I'm opposed to the bigints implementation because
of the implicit type auto-promotion.
Huh? There’s no type promotion from a userland
On 3 February 2015 at 23:26, Cesar Rodas ce...@rodas.me wrote:
Hi Guys,
I have a doubt, is it efficient include/require files from a source
different than the real file system a stream wrapper class? My
question is, would the op-code cache work as it would when reading a
file form the
I should have stated my intent more clearly in the original mail. I
would be targeting 5.5 and above for a core change, and would provide
a an extension to back-fill 5.3 and 5.4. I think people should be able
to use authenticated modes of operation _now_, not when PHP 7 is
released and / or when
On 2 February 2015 at 11:46, Jason Gerfen jason.ger...@gmail.com wrote:
According to documentation provided about the OCB mode of AES it says the
following:
Section 3: The scheme
The tag length is an integer τ ∈ [0 .. n]. ... As for the tag length, a
suggested default of τ = 64 is
On 2 February 2015 at 10:57, Leigh lei...@gmail.com wrote:
length (not sure how of
Not sure how often tag lengths aside from 16 are used.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1 February 2015 at 17:57, Jakub Zelenka bu...@php.net wrote:
Hey,
I have already implemented all of this in crypto ext (
https://github.com/bukka/php-crypto ) and also added support for streams
(e.g.
On 2 February 2015 at 14:30, Daniel Lowrey rdlow...@php.net wrote:
The extra params aren't really _that_ bad.
Okay, I'd like to reset the conversation a bit here. It's clear that the
current API does not fit the problem domain very well. Tacking on more
parameters only creates a bigger mess.
I missed the discussion on this entirely. I see it took place in a
non-obvious thread, in which Nikita asked:
On 10 January 2015 at 11:53, Nikita Popov nikita@gmail.com wrote:
When submitting an RFC, please open a separate thread. Otherwise people who
do not follow every single discussion
On 2 February 2015 at 17:00, François Laupretre franc...@tekwire.net wrote:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
This RFC adds support in str_replace() and str_ireplace() for the
combination of
(string needle, array replace). In this case, each occurrence of
to 3 more params
to these functions.
What do you guys and girls think is the best way of tackling this?
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 31 January 2015 at 16:13, Jason Gerfen jason.ger...@gmail.com wrote:
On Sat, Jan 31, 2015 at 8:53 AM, Leigh lei...@gmail.com wrote:
At the very basic end of the spectrum, we could have openssl_get_tag
and openssl_set_tag, or add an extra parameter to the end of
openssl_encrypt
On 31 January 2015 at 11:12, Bas van Beek b...@tobin.nl wrote:
Well the number 1440 itself is not so arbitrary as it's the amount of minutes
in a day. Maybe that's why the number popped up.
In the end 24 minutes does seem to be fine for the majority of people and
with people that care
On 30 January 2015 at 19:05, Patrick Schaaf p...@bof.de wrote:
Am 30.01.2015 19:43 schrieb Robert Williams rewilli...@thesba.com:
% php -r '$e=0;for($i=0;$i2500;$i++){$e=0$e;} gethostbyname($e);’
What a funny way to say gethostbyname(str_repeat(0, 2501));
does this indicate any problems
On 31 January 2015 at 00:09, Marcio Almada marcio.w...@gmail.com wrote:
Hi,
After a period of research along with part of the PHP community I'd
like to present this RFC which aims to improve PHP namespaces.
The RFC: https://wiki.php.net/rfc/group_use_declarations
Along with its pull
will
probably need some parameters passing anyway, so you still have to do
the work. I'm in the camp that thinks if you call a method that
doesn't exist, you've done something wrong (I particularly hate __call
too).
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 14 January 2015 at 00:16, Andrea Faulds a...@ajf.me wrote:
Good evening,
I’ve made some quite significant changes to my Scalar Type Hints RFC, and
bumped its version to 0.2.
Here: https://wiki.php.net/rfc/scalar_type_hints
This is a new thread because I’ve made a significant revision
On 9 January 2015 at 16:45, Anthony Ferrara ircmax...@gmail.com wrote:
Changing this fallback behavior to the correct error should happen.
However, this will likely break a number of live systems which are
currently relying on the incorrect behavior (likely without knowing
it).
I'd call this
I fail at reply to all.
On 12 January 2015 at 16:52, Leigh lei...@gmail.com wrote:
On 12 January 2015 at 09:31, Andrea Faulds a...@ajf.me wrote:
- To produce a repeatable sequence of random numbers (works, but only if you
and the sole user of the global random number generator, which
On 11 January 2015 at 17:27, Jakub Zelenka bu...@php.net wrote:
I feel that this was a bug in the new parser and we must conform to RFC
7159 !
I agree. +1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11 January 2015 at 22:12, Andrea Faulds a...@ajf.me wrote:
* Get rid of rand(), srand() and getrandmax()
* Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
getrandmax() but add mt_* aliases for backwards-compatibility
Also, this breaks all code currently using
On 11 January 2015 at 22:12, Andrea Faulds a...@ajf.me wrote:
* Get rid of rand(), srand() and getrandmax()
* Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
getrandmax() but add mt_* aliases for backwards-compatibility
* Make mt_srand() and srand() do nothing
/beta tags.
Regards,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1 January 2015 at 14:05, Nikita Popov nikita@gmail.com wrote:
While in favor of introducing scalar type annotations, I'm against this
proposal in particular. I've held a different position in the past, but by
now I'm thoroughly convinced that if we introduce scalar type declarations,
on this. I wasn't sure I had the willpower to
finish my patch for PHP7, it's nice to see you have the same idea.
Cheers,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23 December 2014 at 03:34, Leigh lei...@gmail.com wrote:
On 23 December 2014 at 00:32, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
...
...
I forgot that all important +1 :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 16 December 2014 at 08:34, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I'd like to initiate a vote on objects as keys RFC:
https://wiki.php.net/rfc/objkey
I know this is a holiday season but it was extensively discussed and I
think most people already formed their opinions. I've
On 12 December 2014 at 13:45, Julien Pauli jpa...@php.net wrote:
- If we go for 7.0 :
I wouldn't mind delaying its release to November(2015) if needed, its a
major, extra care should be taken. However, not later : our release process
status for 2 years of active life , if 7.0 were to be
On 12 December 2014 at 23:00, Andrea Faulds a...@ajf.me wrote:
I must disagree: 5.7 would only be trivially different from 5.6
(deprecations), the effort involved is only as much as continuing to maintain
5.6, and we have to do that anyway. So there’s no problem with working on
both.
I
On 11 December 2014 at 07:52, Sebastian Bergmann sebast...@php.net wrote:
Hi!
I just updated my notebook to Fedora 21 and am no longer able to
build PHP on it since I now have bison 3.0.2 instead of bison 2.7.
bison 3.0 is blacklisted in Zend/acinclude.m4. Is bison 3.0
incompatible
I need a christmas holiday project, I'll look into a
php7-mcrypt-compat ext backed by OpenSSL then, and see what is
possible and what is not.
I've actually found OpenSSL to be much faster than mcrypt in practice,
so hopefully we can get a performance boost out of this too.
P.S.
On 11 December 2014 at 15:38, Thomas Hruska thru...@cubiclesoft.com wrote:
To date, there still isn't a way to access CryptGenRandom() from userland
without an extension. Access to that Windows function depends on an
extension to expose php_win32_get_random_bytes() to userland.
On 10 December 2014 at 18:31, Andrea Faulds a...@ajf.me wrote:
It’s my understanding that ext/mcrypt is quite widely used. Would it not be
possible to update the lib to use OpenSSL or something on the backend, so
existing applications would not need changing?
Focusing on the or something.
I'm of the opinion, this:
On 26 November 2014 at 19:45, Anthony Ferrara ircmax...@gmail.com wrote:
The two mcrypt functions, IMHO **MUST** be made timing safe, no matter
what, since they **always** deal with sensitive information.
Extended to any crypto functions too.
But for everything
On 5 November 2014 10:57, Lester Caine les...@lsces.co.uk wrote:
Before you fall of your chairs let me expand on that ...
Many of the sites I'm supporting are being chased by the we want your
work mob, and being told they Must have apps to stay in business. Of
cause that means both an android
On 4 November 2014 18:14, Rowan Collins rowan.coll...@gmail.com wrote:
If anything, I think I would expect the keys of splatted arrays to be
discarded, since it seems most natural to use this in a list context, but I
can imagine always having to check in the manual.
I agree on this point.
On 4 November 2014 08:51, Stas Malyshev smalys...@sugarcrm.com wrote:
I don't see why
public Foo function bar() would be so much worse than public function
bar() : Foo
Because when you grep for function bar, in future you'd have to know
the return type too.
I like to think of it as:
function
On 3 November 2014 22:45, Chris Wright daveran...@php.net wrote:
Good evening list,
I'd like to open discussion a relatively simple and clear-cut RFC, either
people will like it or they won't, there isn't a lot more to say here than
what's in the RFC so please have a read.
On 3 November 2014 21:10, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I'd like to put to vote my proposal about the filtered unserialize():
https://wiki.php.net/rfc/secure_unserialize
It was discussed a number of times before and I think it is time to have
a decision on it. If you need
On 25 October 2014 12:00, Weinand Bob bobw...@hotmail.com wrote:
...
Thanks Bob.
So my question is: Obviously the phpdbg requirements do not map to
DBGp. However, can all of the requirements of DBGp be mapped to the
phpdbg XML?
Going forward does the XML protocol cover everything XDebug needs?
101 - 200 of 330 matches
Mail list logo
