hi,
On Thu, Apr 12, 2012 at 2:23 AM, lijiu zhang wrote:
> Hi
>
> I am curious who is committer of PHP project? Or is there committer? where
> can I check it?
http://www.ohloh.net/p/php/contributors
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PH
Rasmus Lerdorf wrote:
If you think it costs too much still, please let me know.
Pretty much all of the code I have ever written would break. I use
PHP-based templating everywhere and include my templates with
include/require. How exactly can I fix this with 3 lines of code?
Nice to hear that I
On Thu, Apr 12, 2012 at 02:23, lijiu zhang wrote:
> Hi
>
> I am curious who is committer of PHP project? Or is there committer? where
> can I check it?
https://github.com/php/php-src/contributors
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
Hi!
> In summary: should abstract protected constructors be inaccessible by
> siblings, as is true of __clone and __destruct? Should __construct, __clone
> and __destruct always be accessible in relatives, as is true of other
> methods? Depending on the answers, there could be a documentation issu
On Apr 11, 2012, at 9:20 PM, Stas Malyshev wrote:
> Hi!
>
>> On that note Mr. Malyshev has indicated (in addition to several other
>> threads on the internals list) that no new features will be added in
>> 5.3 or 5.4 branches.
>
> 5.3 is out of the question, I think, but for 5.4 small self-cont
Hi!
> On that note Mr. Malyshev has indicated (in addition to several other
> threads on the internals list) that no new features will be added in
> 5.3 or 5.4 branches.
5.3 is out of the question, I think, but for 5.4 small self-contained
additions - like adding a couple of functions here and th
On Apr 11, 2012, at 8:39 PM, Yasuo Ohgaki wrote:
> Hi
>
> 2012/4/12 Stas Malyshev :
>> Hi!
>>
>>> There really doesn't seem to be much interest in this proposed patch.
>>> Should I continue development efforts on closing this feature request?
>>
>> Can't say anything here - I don't use these
On Apr 11, 2012, at 8:49 PM, Stas Malyshev wrote:
> Hi!
>
>> You might want to do something like
>>
>> USE_ZEND_ALLOC=0 ZEND_DONT_UNLOAD_MODULES=1
>> TEST_PHP_EXECUTABLE=./sapi/cli/php php ./run-tests.php -m ext/openssl/
I am glad I asked as I was not aware of this. Is there a comprehensive gu
Hi,
2012/4/12 Yasuo Ohgaki :
> Hi,
>
> 2012/4/12 Chris Stockton :
>> Hello,
>>
>> On Wed, Apr 11, 2012 at 4:42 PM, Yasuo Ohgaki wrote:
>>>
>>> Making sure how it behaves.
>>> include $_GET['filename'];
>>> gave free pass to system, right?
>>>
>>> Regards,
>>>
>>
>> Why on earth do you insist on c
Hi,
2012/4/12 Chris Stockton :
> Hello,
>
> On Wed, Apr 11, 2012 at 4:42 PM, Yasuo Ohgaki wrote:
>>
>> Making sure how it behaves.
>> include $_GET['filename'];
>> gave free pass to system, right?
>>
>> Regards,
>>
>
> Why on earth do you insist on continually posting that horrid snippet
> of cod
Hi!
> You might want to do something like
>
> USE_ZEND_ALLOC=0 ZEND_DONT_UNLOAD_MODULES=1
> TEST_PHP_EXECUTABLE=./sapi/cli/php php ./run-tests.php -m ext/openssl/
Also I would advise adding tests that test failure conditions - right
now the test seem to only test "OK" conditions but not failures
Hi
2012/4/12 Stas Malyshev :
> Hi!
>
>> There really doesn't seem to be much interest in this proposed patch. Should
>> I continue development efforts on closing this feature request?
>
> Can't say anything here - I don't use these APIs personally, but maybe
> other people need them. No idea :)
>
Hi,
2012/4/12 John LeSueur :
>
>
> On Wed, Apr 11, 2012 at 6:55 PM, Rasmus Lerdorf wrote:
>>
>> On 04/11/2012 10:38 AM, John Crenshaw wrote:
>> > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>> >> I guess he is saying that it prevents:
>> >>
>> >> Random bytes
>> >>
>> >> More rando
Hi!
> There really doesn't seem to be much interest in this proposed patch. Should
> I continue development efforts on closing this feature request?
Can't say anything here - I don't use these APIs personally, but maybe
other people need them. No idea :)
> I do also have a few questions regardi
On Wed, Apr 11, 2012 at 6:55 PM, Rasmus Lerdorf wrote:
> On 04/11/2012 10:38 AM, John Crenshaw wrote:
> > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> >> I guess he is saying that it prevents:
> >>
> >>Random bytes
> >>
> >>More random bytes
> >>
> >> Where random bytes might be
Hi,
2012/4/12 Rasmus Lerdorf :
> On 04/11/2012 02:10 PM, Yasuo Ohgaki wrote:
>> It's also very easy to write backward compatible code also.
>> The 3 lines of changes to adopt this RFC do not bother
>> old PHP.
>>
>> No compatibility issue for existing code
>> Just 3 lines of change to adopt
>> Ful
There really doesn't seem to be much interest in this proposed patch. Should I
continue development efforts on closing this feature request?
I do also have a few questions regarding standards adherence, and memory leak
methods of detection.
I ask about the memory leak detection as passing test
On 04/11/2012 02:10 PM, Yasuo Ohgaki wrote:
> It's also very easy to write backward compatible code also.
> The 3 lines of changes to adopt this RFC do not bother
> old PHP.
>
> No compatibility issue for existing code
> Just 3 lines of change to adopt
> Full backward compatibility for OLD systems
Hi!
> handler, which is why it behaves differently from normal methods. In the
> time that I looked, I couldn't find where the access behavior for
> __construct and __destruct was controlled in the source code.
Access for functions is defined by zend_check_protected() and in
zend_std_get_method()
On 04/11/2012 10:38 AM, John Crenshaw wrote:
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>> I guess he is saying that it prevents:
>>
>>Random bytes
>>
>>More random bytes
>>
>> Where random bytes might be an image file so finfo_file() might identify it
>> as a valid image
>
>
Hi
I am curious who is committer of PHP project? Or is there committer? where
can I check it?
Regards,
Lijiu Zhang
Hello,
On Wed, Apr 11, 2012 at 4:42 PM, Yasuo Ohgaki wrote:
>
> Making sure how it behaves.
> include $_GET['filename'];
> gave free pass to system, right?
>
> Regards,
>
Why on earth do you insist on continually posting that horrid snippet
of code lol? I can't help but to laugh and suspect that
Hi,
I'm curious about CLI/CGI.
Are you going enforce file extension as a file type?
It is not a UNIXish way. IMHO.
Making sure how it behaves.
include $_GET['filename'];
gave free pass to system, right?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mai
I'm writing an extension that uses Google's V8 engine. I'm getting a
segfault after my module has been unloaded.
Here is what I get when running PHP:
DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 /phpdev/bin/php -f
/Server/www/localhost/test.php
dyld: loaded: /phpdev/lib/php/extensions/debug-zts-20090626/v8
> I'm using the line:
>
> PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD)
>
> Where the path is /phpdev/lib. But my extension is actually linking to
> /v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even though
> /v8/out/x64.release no longer exists.
>
Hi,
please read http://php.net/git.php
Thanks,
johannes
On Wed, 2012-04-11 at 15:55 -0700, Yader Hernandez wrote:
> Hello,
>
> Is there a reason why the github repo doesn't contain configure file? I
> would have thought that I could do something like:
>
> git clone https://github.com/php/php-s
2012/4/11 Yader Hernandez
> Hello,
>
> Is there a reason why the github repo doesn't contain configure file? I
> would have thought that I could do something like:
>
> git clone https://github.com/php/php-src.git
>
> cd php-src
>
> ./configure
>
> make && make install
>
> The only way to get conf
On Thu, Apr 12, 2012 at 12:55 AM, Yader Hernandez
wrote:
> Hello,
>
> Is there a reason why the github repo doesn't contain configure file? I
> would have thought that I could do something like:
>
> git clone https://github.com/php/php-src.git
>
> cd php-src
>
> ./configure
>
> make && make instal
Hello,
Is there a reason why the github repo doesn't contain configure file? I
would have thought that I could do something like:
git clone https://github.com/php/php-src.git
cd php-src
./configure
make && make install
The only way to get configure is through downloading at php.net
Hi all,
I think my RFC confused people on this list due to improper descriptions
and too much information. Sorry for the confusion. I revised the RFC so
that most important points can be understood at a glance.
https://wiki.php.net/rfc/nophptags
Please read again if you've read already and give
Most people would probably use this for libraries at first, when
working with frameworks that are not designed to have all their code
explosed in the document root anyway. Adoption for direct execution on
the webserver would happen more gradually.
On Wed, Apr 11, 2012 at 4:14 PM, Luke Scott wrote
2012/4/12 Yasuo Ohgaki :
> Hi,
>
> 2012/4/12 Kris Craig :
>>
>>
>> On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki wrote:
>>>
>>> Hi,
>>>
>>> 2012/4/12 Chris Stockton :
>>> > Hello,
>>> >
>>> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig
>>> > wrote:
>>> >> I can't help but question whether we sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 10.04.2012 20:28, schrieb Kris Craig:
> On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang
> wrote:
>
It always amuses me when PERL developers go on their little
soapboxes about how "real" programmers all think PHP is
stupid lol.
>
> It
Taints actually got implemented and released as a PECL package. I allready
use them on our dev server and they really help to find and fix issues with
data escaping all over the place, even though we pay a lot of attention to
this stuff. The only sad thing is that there is no noise at the moment
ab
On Wed, 2012-04-11 at 19:44 +0100, Lester Caine wrote:
> Anthony Ferrara wrote:
> > Even with PDO and older versions of MySQL, you could inject into
> > prepared statements quite easily (assuming charset settings):
> >
> > $var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
> >
> > $pdo = new PDO('mysq
Hi,
2012/4/12 Kris Craig :
>
>
> On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki wrote:
>>
>> Hi,
>>
>> 2012/4/12 Chris Stockton :
>> > Hello,
>> >
>> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig
>> > wrote:
>> >> I can't help but question whether we should even be worrying about
>> >> LFI/RFI
>
On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/12 Chris Stockton :
> > Hello,
> >
> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig
> wrote:
> >> I can't help but question whether we should even be worrying about
> LFI/RFI
> >> to begin with. Personally, I would *never* ch
Hi,
2012/4/12 Chris Stockton :
> Hello,
>
> On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig wrote:
>> I can't help but question whether we should even be worrying about LFI/RFI
>> to begin with. Personally, I would *never* check-off on code that in any
>> way used $_GET or $_POST directly in an inc
On Apr 11, 2012, at 12:02 PM, Chris Stockton wrote:
> Hello,
>
> On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott wrote:
>>
>> The .php extension really isn't used by PHP, but it's used by a web server
>> to identify PHP code and send it to the interpreter. Any mention of file
>> extensions in the R
Hello,
On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott wrote:
>
> The .php extension really isn't used by PHP, but it's used by a web server
> to identify PHP code and send it to the interpreter. Any mention of file
> extensions in the RFC would have to be nothing more than a recommendation.
> I do
On 4/11/12 11:27 AM, "Chris Stockton" wrote:
>Hello,
>
>On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell wrote:
>> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
>> wrote:
>>> I have read the RFC and I although from what I gather it seems that
>>> .phpp is a recommendation and not a requirement,
Anthony Ferrara wrote:
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):
$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM f
Hello,
On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell wrote:
> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
> wrote:
>> I have read the RFC and I although from what I gather it seems that
>> .phpp is a recommendation and not a requirement, but I want to make
>> absolutely sure.
>
>
> That is c
On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton
wrote:
> I have read the RFC and I although from what I gather it seems that
> .phpp is a recommendation and not a requirement, but I want to make
> absolutely sure.
That is correct, it is not a requirement. However if you know of any
reason why .p
Hello,
On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig wrote:
> I can't help but question whether we should even be worrying about LFI/RFI
> to begin with. Personally, I would *never* check-off on code that in any
> way used $_GET or $_POST directly in an include/require statement! It's
> just pla
On Wed, Apr 11, 2012 at 5:07 AM, Tom Boutell wrote:
> I had no goal of making sure code "remains pure" in this rfc, only the
> goal of being allowed to write pure code (no opening establishing a way to encourage pure code in the scope of individual class
> files (disallowing ?> in individual pur
On Wed, Apr 11, 2012 at 10:38 AM, John Crenshaw wrote:
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> > I guess he is saying that it prevents:
> >
> >Random bytes
> >
> >More random bytes
> >
> > Where random bytes might be an image file so finfo_file() might identify
> it as a v
Hello,
On Tue, Apr 10, 2012 at 4:53 PM, Tom Boutell wrote:
> Please see:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> After following the discussion I have updated the RFC with the
> following major changes:
>
> * Forbade the use of ?> entirely in "pure PHP" files (without
>
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> I guess he is saying that it prevents:
>
>Random bytes
>
>More random bytes
>
> Where random bytes might be an image file so finfo_file() might identify it
> as a valid image
Right, but anyone can trivially construct a fully valid b
On Wed, Apr 11, 2012 at 8:45 AM, Rasmus Lerdorf wrote:
> On 04/11/2012 08:12 AM, Luke Scott wrote:
> > Tom has a "similar" RFC that has two modes:
> >
> > - Template mode - how it is now
> > - Code (or pure code) mode - > optional. ?> is disallowed.
> >
> > Tom's RFC calls for template mode to r
Lester,
Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):
$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?')
Ralph Schindler wrote:
Hey Lester,
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not
need 'prepared statements', just parameters ). One of the first things I
implement on any code that I'm porting. Does away with any agro over
escaping
Hey Lester,
On 4/11/12 3:29 AM, Lester Caine wrote:
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not
need 'prepared statements', just parameters ). One of the first things I
implement on any code that I'm porting. Does away with any ag
On 04/11/2012 08:12 AM, Luke Scott wrote:
> Tom has a "similar" RFC that has two modes:
>
> - Template mode - how it is now
> - Code (or pure code) mode - optional. ?> is disallowed.
>
> Tom's RFC calls for template mode to remain the default, but allow you
> to add a flag to require/include to
I do agree with a lot of what was being said. But what can you do?
These are mostly quirks of the language. You learn to live with them.
I don't make excuses for it. It is what it is.
The only thing that infuriates me is the ternary operator being left
associative. I want that fixed - screw bc on
Hey Rasmus,
Here are my thoughts:
On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf wrote:
> On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>>> Therefore, it should not be misunderstood as perfect LFI
>>> countermeasure even if I stressed on security meanings.
>>> I'm stressing security because this ac
On 04/11/2012 12:59 AM, Stas Malyshev wrote:
>> Therefore, it should not be misunderstood as perfect LFI
>> countermeasure even if I stressed on security meanings.
>> I'm stressing security because this actually helps PHP being
>> much safer than now.
>
> I don't see how it is "much safer". Exactl
I had no goal of making sure code "remains pure" in this rfc, only the goal of
being allowed to write pure code (no opening in
individual pure mode files). I think an easy, obvious bc mechanism is
essential, making it harder to use legacy code is not something people would
vote for, and more p
Hi,
2012/4/11 Stas Malyshev :
> Hi!
>
>> template_mode=on is not a actual security measure, but a
>> switch for language mode. template_mode=on has side
>> effect that makes PHP as safe as other scripting languages
>> or even better!
>
> PHP is as safe as other scripting languages right now. And y
Stas Malyshev wrote:
PHP could be stronger against LFI compare to scripting languages
> as I described in previous mail.
PHP is as strong as any other language right now - if you include
user-supplied code, you lost, don't do it - no problem.
> With this RFC, infamous reputation of LFI can b
Yasuo Ohgaki wrote:
Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...
That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not need
'prepared statements', just pa
Stopped reading after encountered "E_ACTUALLY_ALL", "for ($foo as &$bar)" -
these things required me to google or to refer to docs to ensure I was not
missing something. And, yes, I should have stopped after the words "don’t
tell me anything!". People who refuse to listen do not deserve to be heard
Hi!
> template_mode=on is not a actual security measure, but a
> switch for language mode. template_mode=on has side
> effect that makes PHP as safe as other scripting languages
> or even better!
PHP is as safe as other scripting languages right now. And you are using
security talk to promote thi
You can register for your own free github account at http://github.com
and follow the instructions to setup git.
Once you've done that you can fork the php-src tree from
http://github.com/php/php-src
Then you can submit your patches by sending a pull request to php.
On Wed, Apr 11, 2012 at 3:45
2012/4/11 lijiu zhang :
> Hello everyone:
>
> I am a mater student of Australia National University. I have used PHP for
> several years, I want to join in the PHP development and contribute some
> patch.
> The git account need to User ID and Requested Password, how can I get them?
>
> Sincerely,
>
On Wed, Apr 11, 2012 at 9:45 AM, lijiu zhang wrote:
> Hello everyone:
>
> I am a mater student of Australia National University. I have used PHP for
> several years, I want to join in the PHP development and contribute some
> patch.
> The git account need to User ID and Requested Password, how ca
Hello everyone:
I am a mater student of Australia National University. I have used PHP for
several years, I want to join in the PHP development and contribute some
patch.
The git account need to User ID and Requested Password, how can I get them?
Sincerely,
LijiuZhang
**
Hi,
It was fun to read. I understand he just don't like PHP.
His article may be good for novice users to understand how PHP will behave.
I guess he learned PHP a lot, but he lists framework feature as
missing. I wander why. He seems to like Python, but Python's multibyte
support was awful until r
68 matches
Mail list logo
