Hi all,
Few years ago, I have proposed strict session.
It seems PHP 5.4 and php-src don't have protection against session
adoption yet.
Since there will be many TLDs, session adoption attack will be
very easy for some domains until browsers support them.
Even without new TLDs, attacker may place
On Fri, Nov 4, 2011 at 12:21 AM, Ferenc Kovacs wrote:
>
>
> On Fri, Nov 4, 2011 at 12:20 AM, Stefan Marr wrote:
>
>> Hi:
>>
>> On 04 Nov 2011, at 00:12, Ferenc Kovacs wrote:
>>
>> > I almost forget to mention, but the email notification also supports
>> defining different recipients for each eve
On Fri, Nov 4, 2011 at 12:20 AM, Stefan Marr wrote:
> Hi:
>
> On 04 Nov 2011, at 00:12, Ferenc Kovacs wrote:
>
> > I almost forget to mention, but the email notification also supports
> defining different recipients for each event, so for example the commiters
> could still get the notification f
Hi:
On 04 Nov 2011, at 00:12, Ferenc Kovacs wrote:
> I almost forget to mention, but the email notification also supports defining
> different recipients for each event, so for example the commiters could still
> get the notification for each of their commits/builds until the build is back
> t
On Thu, Nov 3, 2011 at 11:58 PM, Rasmus Lerdorf wrote:
> On 11/03/2011 03:47 PM, Ferenc Kovacs wrote:
> > A, it will report every test failure, but we fix all of our tests so we
> > are cool. (my preference)
>
> But even if we do that, when a test does fail, it may take a couple of
> days to fix
On 11/03/2011 03:47 PM, Ferenc Kovacs wrote:
> A, it will report every test failure, but we fix all of our tests so we
> are cool. (my preference)
But even if we do that, when a test does fail, it may take a couple of
days to fix it. It would be nice if we didn't get an internals email for
every c
On Thu, Nov 3, 2011 at 11:33 PM, Rasmus Lerdorf wrote:
> On 11/03/2011 02:26 PM, Ferenc Kovacs wrote:
> > We could set up the email notification any time, we would just have to
> > agree where to send (internals, php-qa, creating a dedicated mailing
> list?)
> > and when to send (as I added to th
On 11/03/2011 02:26 PM, Ferenc Kovacs wrote:
> We could set up the email notification any time, we would just have to
> agree where to send (internals, php-qa, creating a dedicated mailing list?)
> and when to send (as I added to the RFC, having failing tests can be a
> problem from the notificatio
The first release candidates of 5.3.9 was just released for testing and
can be downloaded here:
http://downloads.php.net/johannes/php-5.3.9RC1.tar.bz2 (md5sum:
5e8564008606edfab6a81137c1daf354)
The windows binaries are available at: http://windows.php.net/qa/
This is the first step in the releas
On Thu, Nov 3, 2011 at 10:25 PM, Klaus Silveira
wrote:
> Yes, it's a wonderful setup. Great work, Ferenc! :D
>
> This does give a nice motivation to write more tests and increase the code
> coverage, doesn't it?
>
Yes, and first of all, to fix the currently failing tests.
We also had a discussion
On Thu, Nov 3, 2011 at 10:22 PM, Felipe Pena wrote:
> 2011/11/3 Ferenc Kovacs :
> > On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira <
> cont...@klaussilveira.com>wrote:
> >
> >> That's kind of a general setup, Stefan. Sending an email to the commiter
> >> that broke the build with details of the b
Yes, it's a wonderful setup. Great work, Ferenc! :D
This does give a nice motivation to write more tests and increase the code
coverage, doesn't it?
On Thu, Nov 3, 2011 at 7:22 PM, Felipe Pena wrote:
> 2011/11/3 Ferenc Kovacs :
> > On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira <
> cont...@klau
2011/11/3 Ferenc Kovacs :
> On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira
> wrote:
>
>> That's kind of a general setup, Stefan. Sending an email to the commiter
>> that broke the build with details of the build process, as well sending an
>> email to a mailing list.
>>
>> I'll be looking into thi
2011/6/27 guilhermebla...@gmail.com :
> Hannes,
>
> There's a RFC covering this. There's a patch also.
>
> https://wiki.php.net/rfc/splclassloader
I do have a few remarks:
1. That is not a *class* loader, that is a loader (also for
interfaces), hence my suggestion s/SplClassLoader/SplLoader/
2. PS
On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira wrote:
> That's kind of a general setup, Stefan. Sending an email to the commiter
> that broke the build with details of the build process, as well sending an
> email to a mailing list.
>
> I'll be looking into this Jenkins issue (JENKINS-5931). Maybe
On Thu, Nov 3, 2011 at 8:33 PM, Stefan Marr wrote:
> Hi:
>
> On 03 Nov 2011, at 20:15, Ferenc Kovacs wrote:
>
> > The usual setup is that you have a mailing list/alias which always gets
> a mail about the build results (which can also be customized in detail,
> when to mail, etc.) and optionally
That's kind of a general setup, Stefan. Sending an email to the commiter
that broke the build with details of the build process, as well sending an
email to a mailing list.
I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an
access control based on IRC operators and voices?
On
Hi:
On 03 Nov 2011, at 20:15, Ferenc Kovacs wrote:
> The usual setup is that you have a mailing list/alias which always gets a
> mail about the build results (which can also be customized in detail, when to
> mail, etc.) and optionally you can notify the person whose commit break the
> build.
On Thu, Nov 3, 2011 at 7:43 PM, Stefan Marr wrote:
> Hi Ferenc:
>
> On 03 Nov 2011, at 19:01, Ferenc Kovacs wrote:
>
> > Of course there are ways to improve the current setup, I listed those
> ideas
> > at https://wiki.php.net/rfc/jenkins#future_plans
>
> Very nice.
> I don't know Jenkins, but wo
Wouldn't you consider spl_autoload_register an interoperability solution? Only
your defined autoloading function would then need to know how your file system
is structured, there'd be no need for include_path declarations and you
wouldn't have to explicitly declare paths for each class.
On Nov
On Thu Nov 3 11:19 AM, Anthony Ferrara wrote:
>
> But that's besides the point. I just want to emphasize the point that
> performance should not be a criteria for justifying it going into the
> core...
>
There also seems to be the perception among some php devs that autoloading
is now the pre
Yes, it is. But not only email notifications are possible, other
interesting integrations are possible. For example, Jabber.
https://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin
On Thu, Nov 3, 2011 at 4:43 PM, Stefan Marr
Hi Ferenc:
On 03 Nov 2011, at 19:01, Ferenc Kovacs wrote:
> Of course there are ways to improve the current setup, I listed those ideas
> at https://wiki.php.net/rfc/jenkins#future_plans
Very nice.
I don't know Jenkins, but would it be possible to mail the author of a change
in case it breaks s
Paul,
I wasn't saying whether it should be included or not. I was saying
that performance should not be a justification for it being included.
It may be a benefit, but it's a very small side benefit as opposed to
a primary one.
Additionally, I wholeheartedly disagree with one of your points ther
On Thu, Nov 3, 2011 at 6:10 PM, Klaus Silveira wrote:
> What are the current obstacles in a possible Jenkins implementation for
> the PHP codebase?
>
>
> --
> Klaus Silveira
> (011) 8564-2492
> www.klaussilveira.com
>
Sorry, I don't really follow you.
As I mentioned in my previous email and the R
On Thu, 2011-11-03 at 18:17 +0100, Nikita Popov wrote:
> On Thu, Nov 3, 2011 at 6:15 PM, Klaus Silveira
> wrote:
>
> > Apache is mirroring their GIT to github, not actually "using" Github. This
> > is also a good thing.
> PHP is mirroring too:
> https://github.com/php/php-src
>
Better to simply
On Thu, Nov 3, 2011 at 6:15 PM, Klaus Silveira
wrote:
> Apache is mirroring their GIT to github, not actually "using" Github. This
> is also a good thing.
PHP is mirroring too:
https://github.com/php/php-src
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
I hate to bring this discussion again, but with the future move to Git,
moving to Github would be a nice idea. I wanted to propose a discussion of
the pros and cons and possibly create an RFC.
Apache is mirroring their GIT to github, not actually "using" Github. This
is also a good thing.
--
Kla
What are the current obstacles in a possible Jenkins implementation for the
PHP codebase?
--
Klaus Silveira
(011) 8564-2492
www.klaussilveira.com
On Thu, Nov 3, 2011 at 1:46 AM, Ferenc Kovacs wrote:
>
>
> On Wed, Sep 7, 2011 at 11:29 AM, Hannes Magnusson <
> hannes.magnus...@gmail.com> wrote:
>
>> On Wed, Sep 7, 2011 at 03:53, Ferenc Kovacs wrote:
>> > On Wed, Sep 7, 2011 at 3:29 AM, Stas Malyshev
>> wrote:
>> >> Hi!
>> >>
>> >> Since we
On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara wrote:
> Can I make a point here.
>
> Why the heck are we caring about the performance of the autoloader at
> all here? The filesystem operations necessary (at least the stat()
> call) will greatly dominate any string function. And considering that
On Thu, Nov 3, 2011 at 4:19 PM, Anthony Ferrara wrote:
> Can I make a point here.
>
> Why the heck are we caring about the performance of the autoloader at
> all here? The filesystem operations necessary (at least the stat()
> call) will greatly dominate any string function. And considering tha
I couldn't agree more with Anthony. In conjunction with that, I would continue
to question the full benefit to the community. How many existing code
bases/frameworks out there would implement this in favor of their existing
solution?
Will
On Nov 3, 2011, at 11:19 AM, Anthony Ferrara wrote:
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least the stat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classe
On Thu, Oct 27, 2011 at 4:30 AM, Laruence wrote:
> 2011/10/26 André Rømcke :
> > On Tue, Oct 25, 2011 at 4:39 AM, guilhermebla...@gmail.com <
> > guilhermebla...@gmail.com> wrote:
> >
> >> Hi internals,
> >>
> >> For all those interested, I have updated the RFC with better
> >> explanation, inclu
Hi Gustavo,
Thanks for reply.
As long as bison didn't understand multibyte chars, parser would not
work well with them.
Your reply is exactly what I expected.
Thank you for clarification.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Thu, Nov 3, 2011 at 8:07 PM, Gustavo Lopes wrote:
> Em Thu, 03 No
Em Thu, 03 Nov 2011 10:31:47 -, Yasuo Ohgaki
escreveu:
One last quick question.
Zend/tests/multibyte/multibyte_encoding_001.phpt sets
mbstring.internal_encoding=SJIS.
Does PHP 5.4+ suppose to work with SJIS(or other similar encoding)
internal_encoding?
No. What matters is that the par
$ sapi/cli/php -d zend.multibyte=1 -d zend.script_encodinSJIS -d
mbstring.internal_encoding=UTF8 -d mbstring.output_encoding=UTF8 sjis.php
表
Too many different encodings :)
Thanks. Dmitry.
On 11/03/2011 01:38 PM, Yasuo Ohgaki wrote:
Oops, I thought "?" was due to terminal encoding, but I d
One last quick question.
Zend/tests/multibyte/multibyte_encoding_001.phpt sets
mbstring.internal_encoding=SJIS.
Does PHP 5.4+ suppose to work with SJIS(or other similar encoding)
internal_encoding?
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Hi Gutavo,
Now I see what is going on. I thought string is treated as just a
bunch of data once
is was compiled and passed through.
$ ./sapi/cli/php -d zend.multibyte=1 -d zend.script_encoding=SJIS -d
mbstring.internal_encoding=utf-8 sjis.php 表
Thanks for your time.
May be I should document thi
Em Thu, 03 Nov 2011 09:38:11 -, Yasuo Ohgaki
escreveu:
Oops, I thought "?" was due to terminal encoding, but I double checked
with
redirecting to a file.
$ ./sapi/cli/php -d zend.multibyte=1 -d zend.script_encoding=SJIS
sjis.php > tt
It became "?" instead of "表"..
It seems somethin
Oops, I thought "?" was due to terminal encoding, but I double checked with
redirecting to a file.
$ ./sapi/cli/php -d zend.multibyte=1 -d zend.script_encoding=SJIS sjis.php > tt
It became "?" instead of "表"..
It seems something wrong.
Thanks for you time.
--
Yasuo Ohgaki
yohg...@ohgaki.net
On
Hi Dimity,
Now it seems working as it supposed. Thanks.
$ ./sapi/cli/php -d zend.multibyte=1 -d zend.script_encoding=SJIS sjis.php?
(? is due to my terminal encoding. It sets to UTF-8)
It seems LEAK problem was gone with PHP 5.4, too.
[yohgaki@dev php-src-5.4]$ TEST_PHP_EXECUTABLE=./sapi/cli/ph
I suppose PHP can't autodetect SJIS encoding and needs a hint
for 5.4
$ php -d zend.multibyte=1 -d zend.script_encoding=SJIS sjis.php
5.3 must be compiled with --enable-zend-multibyte, then
$ php -d mbstring.script_encoding=SJIS for 5.3
(I've just tested 5.4 but not 5.3. Just don't have 5.3 c
Hi Dimity & Rui,
I was trying to see if PHP 5.4 and trunk was also affected by this bug report.
--with-zend-multibyte and --enable-debug reports LEAK with run-test.php
https://bugs.php.net/bug.php?id=60194
So I configured as "./configure --enable-debug"
Sorry for being a lazy reader. I could tu
Hi Yasuo,
how did you see that "Zend Multibyte Support" weren't enabled?
$ sapi/cli/php -d zend.multibyte=1 -i | grep -i multibyte
Zend Multibyte Support => provided by mbstring
zend.multibyte => On => On **
Multibyte Support => enabled
Multibyte string engine => libmbfl
Multibyte (japanese
46 matches
Mail list logo
