2012/3/7 Ángel González
> On 07/03/12 00:04, Adam Jon Richardson wrote:
> > It would be the responsibility of the framework or CMS or application
> > to protect against this type of attack (which they do quite well.)
> > When you can force a plugin to work through your API, you can take
> > appro
On 03/12/2012 05:52 PM, Yasuo Ohgaki wrote:
> I always set all parameters for htmlentities/htmlspecialchars, therefore
> I haven't noticed this was changed from 5.3. They may be migrating from
> 5.2 or older. (RHEL5 uses 5.1)
No, like I showed, moving from 5.3 to 5.4 breaks because the new default
2012/3/13 Rasmus Lerdorf :
> On 03/12/2012 03:05 AM, Yasuo Ohgaki wrote:
>> I thought default_charset became UTF-8, so I was expecting
>> following HTTP header.
>>
>> content-type text/html; charset=UTF-8
>>
>> However, I got empty charset (missing 'charset=UTF-8').
>> So I looked up to source and
Hi!
Still, that API is likely wrong: a library function written by someone
completely unrelated to the main application shouldn't be echoing
anything through the output. And if it's not generating the html, the
htmlspecialchars is better done from the return at the calling
application (probably
On 12/03/12 22:30, Stas Malyshev wrote:
> Hi!
>
>> If you are a framework developer, and really want to shield against a
>> bad php.ini setting, you could ini_set() to your prefered charset at the
>> beginning of the request.
>
> That assuming "the request" is completely processed by your framework
Hi1
The autom4te.cache and *.orig files originally mentioned are included in
php.net's php-5.4.0.tar.bz2
I.e. this is a valid issue.
Definitely seems to be a bug in the makedist script, since these files
are not in the SVN but appear when packaging.
--
Stanislav Malyshev, Software Architect
On Mon, Mar 12, 2012 at 5:08 PM, Richard Lynch wrote:
> On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote:
>
> Security by blacklist almost always isn't security...
>
> You're bound to miss one of the functions you should have blacklisted,
> but didn't.
>
Agreed. The approach I'm developi
On Mon, Mar 12, 2012 at 23:06, Alexey Shein wrote:
> 13 марта 2012 г. 3:00 пользователь Stas Malyshev
> написал:
>> Hi!
>>
>>> are they in svn? I can't see them in 5.4
>>
>>
>> They are not in SVN, but at least for autom4te.cache ones they seem to be
>> generated when configure script is generate
On 03/12/2012 03:06 PM, Alexey Shein wrote:
13 марта 2012 г. 3:00 пользователь Stas Malyshev
написал:
Hi!
are they in svn? I can't see them in 5.4
They are not in SVN, but at least for autom4te.cache ones they seem to be
generated when configure script is generated, and the packing scri
13 марта 2012 г. 3:00 пользователь Stas Malyshev
написал:
> Hi!
>
>> are they in svn? I can't see them in 5.4
>
>
> They are not in SVN, but at least for autom4te.cache ones they seem to be
> generated when configure script is generated, and the packing script happily
> picks them up. I have no id
Hi!
are they in svn? I can't see them in 5.4
They are not in SVN, but at least for autom4te.cache ones they seem to
be generated when configure script is generated, and the packing script
happily picks them up. I have no idea how orig files got there...
--
Stanislav Malyshev, Software Arch
hi!
are they in svn? I can't see them in 5.4
Or which release did have them?
On Mon, Mar 12, 2012 at 10:52 PM, Ondřej Surý wrote:
> Hi guys,
>
> could you please remove this cruft:
>
> dpkg-source: warning: ignoring deletion of file
> ext/standard/var_unserializer.c.orig
> dpkg-source: warning:
On 12/03/12 20:36, Richard Lynch wrote:
> On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
>> This doesn't look good. Documentation does say the @ prefix exists,
>> but
>> it has very high potential of creating security holes for unsuspecting
>> people. open_basedir would help limit the impact,
Hi guys,
could you please remove this cruft:
dpkg-source: warning: ignoring deletion of file
ext/standard/var_unserializer.c.orig
dpkg-source: warning: ignoring deletion of file
ext/standard/url_scanner_ex.c.orig
dpkg-source: warning: ignoring deletion of file ext/date/lib/parse_date.c.orig
dpkg-
On 2012-03-12, Arvids Godjuks wrote:
> --f46d0442880e02b97f04bb0b432b
> Content-Type: text/plain; charset=UTF-8
>
> I think that the "null issue" is not an issue. Strictly speaking if you
> want null or an int - leave out the type hint and use generic argument that
> will accept anything.
> I thin
Hi!
If you are a framework developer, and really want to shield against a
bad php.ini setting, you could ini_set() to your prefered charset at the
beginning of the request.
That assuming "the request" is completely processed by your framework
and you never call any outside code and any outsi
On 12/03/12 20:51, Stas Malyshev wrote:
> Hi!
>
>> But you can't necessarily hardcode the encoding if you are writing
>> portable code. That's a bit like hardcoding a timezone. In order to
>> write portable code you need to give people the ability to localize it.
>
> No, it's not like timezone at a
On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote:
Security by blacklist almost always isn't security...
You're bound to miss one of the functions you should have blacklisted,
but didn't.
Something like Drupal would be crippled by this because major
extensions used by all rely on access t
hi Rasmus,
On Mon, Mar 12, 2012 at 9:12 PM, Rasmus Lerdorf wrote:
> If everything was UTF-8 we wouldn't have any of these issues.
> Unfortunately that isn't the case. The question is what to do with apps
> that need to deal with non UTF-8 data. Are we going to provide any help
> to them beyond j
On Thu, March 8, 2012 5:13 am, Alain Williams wrote:
> On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote:
>> > Type hints are meant to
>> > filter input from external sources
>>
>> Correction, it should read like this:
>> Type hints are _not_ meant to filter input from external sources
On 03/12/2012 12:51 PM, Stas Malyshev wrote:
> Hi!
>
>> But you can't necessarily hardcode the encoding if you are writing
>> portable code. That's a bit like hardcoding a timezone. In order to
>> write portable code you need to give people the ability to localize it.
>
> No, it's not like timezo
I can't recommend any blogs, per se, but Sara's book or even her
articles on Zend.com as well as the php.net manual about internals at
the end are a "must read" for understanding the internals...
On Thu, March 8, 2012 6:22 am, adit adit wrote:
> Let's try to stick only to the internals blogs, ok?
Hi!
But you can't necessarily hardcode the encoding if you are writing
portable code. That's a bit like hardcoding a timezone. In order to
write portable code you need to give people the ability to localize it.
No, it's not like timezone at all. I have to support all timezones in a
global app
On Fri, March 9, 2012 5:58 pm, John Crenshaw wrote:
> The reason you have to validate the input type in this case is because
> even though it is a reference, we don't ACTALLY know that it isn't
> supposed to contain an input (even though that would be against all
> sane rules most of the time).
La
On 03/12/2012 12:40 PM, Stas Malyshev wrote:
> Hi!
>
>> And yes, it may very well be dangerous to use the wrong charset and now
>> that we have better support for GB2312 and other asian charsets in the
>> entities functions in 5.4 it is even more prudent to choose the right
>> one so we should pro
On Fri, March 9, 2012 2:51 am, Nikita Popov wrote:
> On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky
> wrote:
>> Anthony,
>>
>> My concern with this type of patch is that what you are proposing
>> are
>> not really hints, they are forced casts. As such they modify the
>> data
>> potentially leadi
Hi!
And yes, it may very well be dangerous to use the wrong charset and now
that we have better support for GB2312 and other asian charsets in the
entities functions in 5.4 it is even more prudent to choose the right
one so we should provide some way to help people get it right short of
changing
On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
> Hi!
>
>> I'd sure like a PHP extension that didn't have this obvious and
>> nasty bug:
>>
>> https://bugs.php.net/bug.php?id=46439
>
> This doesn't look good. Documentation does say the @ prefix exists,
> but
> it has very high potential of cre
On Mon, March 12, 2012 1:49 am, Rasmus Lerdorf wrote:
> What we really need is what we added in PHP 6. A runtime encoding ini
> setting that is distinct from the output charset which we can use
> here.
The usual argument against another php.ini setting, other than "too
many already" is the difficu
Thank you for the confirmation.
What I am saying here is that, although this behavior was fine for objects,
it is not enough for scalars. One of the main arguments in favor of the
adoption of this syntax was that null was the only possible default value
for objects anyway. This obviously is not th
I think the ini directive, while adding another to the list, may be the
most unobtrusive method to address this issue, at least for developers.
I definitely agree with Rasmus that this could be one of the bigger
headaches in transitioning to 5.4 (for non-UTF8 sites) and unless we can
come up with
On 03/12/2012 03:05 AM, Yasuo Ohgaki wrote:
> Hi
>
> I think following PHP 5.4.0 NEWS entry is misleading.
>
> . Changed default value of "default_charset" php.ini option from ISO-8859-1
> to
> UTF-8. (Rasmus)
Yes, I have fixed that now.
> I thought default_charset became UTF-8, so I was
Hello Arvids,
The patch of Anthony, clearly states that this is accepted:
function foo ( int $bar = null ) { }
And this is what I called an int|null.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Arvids Godjuks
> 2012/3/12 Lazare Inepologlou
>
>> > I'm not sure about you, but I don't wa
Lazare,
> The patch of Anthony, clearly states that this is accepted:
>
> function foo ( int $bar = null ) { }
>
> And this is what I called an int|null.
Yup, it does. Because that's the current behavior with array and
object casting. If you default it to null in the declaration, null is
a vali
2012/3/12 Lazare Inepologlou
> > I'm not sure about you, but I don't wanna see that kind of thing
> eventually making it's way into the language
>
> Me neither. All I am saying is that, since int|null is already here from
> the back door, I think it should be properly supported.
>
There is no in
> I'm not sure about you, but I don't wanna see that kind of thing
eventually making it's way into the language
Me neither. All I am saying is that, since int|null is already here from
the back door, I think it should be properly supported.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/12 Arvid
Hello Simon,
First of all, none of your examples cover the case I mentioned, and so, my
concerns are still valid.
Secondly, you make some wrong assumptions about how this specific POC
works. For example, you write:
> function foo(int $d = 20) { var_dump($d); }
> foo(null); // This should then al
I think that the "null issue" is not an issue. Strictly speaking if you
want null or an int - leave out the type hint and use generic argument that
will accept anything.
I think it's over-engineering to try and push a special treatment for the
null. If function/method argument accepts anything but
On Mon, Mar 12, 2012 at 6:21 PM, Yasuo Ohgaki wrote:
> Hi,
>
> I think motivation of
>
> /* Default is now UTF-8 */
> if (charset_hint == NULL)
> return cs_utf_8;
>
> is for better performance and I think it's good for better performance.
> Alternative of my suggestion is
2012/3/12 Lazare Inepologlou
>
> function set_check_box_state( bool state = false ) { ... }
> set_check_box_state( null ); // null will be converted to false here...
>
> Therefore, this cannot work, unless the default value becomes null, which
> is against the requirements. What I suggest is some
Hello Anthony,
I will raise once again the question about accepting null. According to
your POC, null is an acceptable value if it is also declared as a default
value. This is problematic for the scalar types, because they can very well
have a different default value.
An example: There is a check
Arvids,
> Yea, that part looks confusing.
> What I wanted to say is that I would like to get E_RECOVERABLE_ERROR and I
> was voicing my opinion on that earlier in the threads. But I could live with
> E_WARNING and E_NOTICE if community decides it to be less strict - I will
> clean up my code not t
>
>
> > What is consistent and exists on the internal language layer
> > not necessarily good for the user-land. I'm kind'a surprised no one
> thought
> > of that.
> > As I said I can live with the throwing notices and warnings (and not
> > E_RECOVERABLE_ERROR as I personally wanted), but returning
Arvids,
On Mon, Mar 12, 2012 at 4:39 AM, Arvids Godjuks
wrote:
> I should point out that returning false on param parsing failure on the
> language level is one thing (not to mention it's not ok to do that in the
> first place by my taste), but forcing that behavior on the user-land level
> is ki
Hi,
I think motivation of
/* Default is now UTF-8 */
if (charset_hint == NULL)
return cs_utf_8;
is for better performance and I think it's good for better performance.
Alternative of my suggestion is introduce new php.ini entry as Rusmus
mentioned.
The name may be "
Hi
I think following PHP 5.4.0 NEWS entry is misleading.
. Changed default value of "default_charset" php.ini option from ISO-8859-1 to
UTF-8. (Rasmus)
I thought default_charset became UTF-8, so I was expecting
following HTTP header.
content-typetext/html; charset=UTF-8
However, I go
I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the user-land level
is kind'a too much.
Consider how the code will become much more complicated -
On 03/12/2012 12:52 AM, Stas Malyshev wrote:
> Hi!
>
>> Ignoring 5.4 for a second, if you in 5.3 do this:
>>
>> echo htmlspecialchars($string);
>> echo htmlspecialchars($string, NULL, "ISO-8859-1");
>> echo htmlspecialchars($string, NULL, "UTF-8");
>>
>> You will see that the first two output the
On Mon, Mar 12, 2012 at 3:52 AM, Stas Malyshev wrote:
> Hi!
>
>
> Ignoring 5.4 for a second, if you in 5.3 do this:
>>
>> echo htmlspecialchars($string);
>> echo htmlspecialchars($string, NULL, "ISO-8859-1");
>> echo htmlspecialchars($string, NULL, "UTF-8");
>>
>> You will see that the first two
Hi!
Ignoring 5.4 for a second, if you in 5.3 do this:
echo htmlspecialchars($string);
echo htmlspecialchars($string, NULL, "ISO-8859-1");
echo htmlspecialchars($string, NULL, "UTF-8");
You will see that the first two output the escaped string with the
GB2312 bytes intact within it and the UTF-
On 03/12/2012 12:41 AM, Rasmus Lerdorf wrote:
> $string = $string = "$gb2312";
Sorry typo there obviously. Just one $string
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 03/12/2012 12:10 AM, Stas Malyshev wrote:
> Hi!
>
>> What we really need is what we added in PHP 6. A runtime encoding ini
>> setting that is distinct from the output charset which we can use here.
>> That would allow people to fix all their legacy code to a specific
>> runtime encoding with a
On Mon, Mar 12, 2012 at 3:10 PM, Stas Malyshev wrote:
> Hi!
>
>
>> What we really need is what we added in PHP 6. A runtime encoding ini
>> setting that is distinct from the output charset which we can use here.
>> That would allow people to fix all their legacy code to a specific
>> runtime encod
On Mon, Mar 12, 2012 at 3:10 PM, Stas Malyshev wrote:
> Hi!
>
>
>> What we really need is what we added in PHP 6. A runtime encoding ini
>> setting that is distinct from the output charset which we can use here.
>> That would allow people to fix all their legacy code to a specific
>> runtime encod
Hi!
What we really need is what we added in PHP 6. A runtime encoding ini
setting that is distinct from the output charset which we can use here.
That would allow people to fix all their legacy code to a specific
runtime encoding with a single ini setting instead of changing thousands
of lines o
On Mon, Mar 12, 2012 at 2:49 AM, Rasmus Lerdorf wrote:
> What we really need is what we added in PHP 6. A runtime encoding ini
> setting that is distinct from the output charset which we can use here.
> That would allow people to fix all their legacy code to a specific
> runtime encoding with a s
56 matches
Mail list logo