Here is a patch for bug 41822. The expand_filepath() function will not
work in Solaris if a non-root user attempts to read a file under a
directory with only (--x) permissions.
Currently expand_path() returns NULL and no FD is opened, although the
file is readable. This patch adds a last-ditch
On 05.10.2007 11:09, Rob Thompson wrote:
> Here is a patch for bug 41822. The expand_filepath() function will not
> work in Solaris if a non-root user attempts to read a file under a
> directory with only (--x) permissions.
>
> Currently expand_path() returns NULL and no FD is opened, although th
On Thu, 4 Oct 2007, Larry Garfield wrote:
> On Tuesday 02 October 2007, Alexey Zakhlestin wrote:
> > On 10/1/07, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > > Sorry to bother, I have a few questions on this matter.
> > > How will this impact on the SPL ArrayAccess and related interfaces and
>
I have added information on how I fixed #42637 to the ticket:
http://bugs.php.net/bug.php?id=42637
It's a one-line fix. I'd be interested in others testing this in their
environment and a developer reviewing it. It'd be nice to see it
checked in for 5.2.5
--
Bill Moran
Collaborative Fusion In
Hi,
I updated the 5.3 todo list [1] yesterday evening. I also just
spotted a minor mistake. I put the visibility patch under todo items,
where it should have gone under future releases. We should also
revisit the 5.2 todo list [2] and see if the items there are not yet
done and if they wi
No, no and no!
The gcc 4 -fvisibility patch wasn't rejected. It's a no-op and although it
is only useful for gcc 4 users, it brings many benefits for them!
So please keep that in the PHP 5.3 TODO.
Nuno
- Original Message -
Hi,
I updated the 5.3 todo list [1] yesterday evening. I al
(Wietse Venema) wrote:
To give an idea of the functionality, consider the following program
with an obvious HTML injection bug:
With default .ini settings, this program does exactly what the
programmer wrote: it echos the contents of the username request
attribute, including all the malici
Hi Antony,
Antony Dovgal wrote:
> Rob, I believe you're looking into wrong place.
> You should be patching virtual_file_ex() in TSRM/tsrm_virtual_cwd.c, the root
> of
> all evils is there as this function is used by expand_filepath() and in all
> other places.
Ok, originally was going to try
snaps.php.net doesn't have 5.3 yet.
will it appear there?
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
laurent jouanneau:
> (Wietse Venema) wrote:
> > To give an idea of the functionality, consider the following program
> > with an obvious HTML injection bug:
> >
> > > $username = $_GET['username'];
> > echo "Welcome back, $username\n";
> > ?>
> >
> > With default .ini settings, t
(Wietse Venema) wrote:
laurent jouanneau:
(Wietse Venema) wrote:
To give an idea of the functionality, consider the following program
with an obvious HTML injection bug:
With default .ini settings, this program does exactly what the
programmer wrote: it echos the contents of the username
M. Sokolewicz:
> (Wietse Venema) wrote:
> > laurent jouanneau:
> >> (Wietse Venema) wrote:
> >>> To give an idea of the functionality, consider the following program
> >>> with an obvious HTML injection bug:
> >>>
> >>> >>> $username = $_GET['username'];
> >>> echo "Welcome back, $user
Wietse Venema wrote:
> M. Sokolewicz:
>> (Wietse Venema) wrote:
>>> laurent jouanneau:
(Wietse Venema) wrote:
> To give an idea of the functionality, consider the following program
> with an obvious HTML injection bug:
>
> $username = $_GET['username'];
> e
Rasmus Lerdorf:
> Consider very common (abbreviated) code like this:
>
> $user_data = $_REQUEST['data'];
> switch($output_format) {
Question: where is the output format feature documented?
Once I know the output format is not HTML, then I know
that applying HTML-style restrictions is not appropr
Wietse Venema wrote:
> Rasmus Lerdorf:
>> Consider very common (abbreviated) code like this:
>>
>> $user_data = $_REQUEST['data'];
>> switch($output_format) {
>
> Question: where is the output format feature documented?
>
> Once I know the output format is not HTML, then I know
> that applying HT
Rasmus Lerdorf:
> Wietse Venema wrote:
> > Rasmus Lerdorf:
> >> Consider very common (abbreviated) code like this:
> >>
> >> $user_data = $_REQUEST['data'];
> >> switch($output_format) {
> >
> > Question: where is the output format feature documented?
> >
> > Once I know the output format is not
Wietse Venema wrote:
> Rasmus Lerdorf:
>> Wietse Venema wrote:
>>> Rasmus Lerdorf:
Consider very common (abbreviated) code like this:
$user_data = $_REQUEST['data'];
switch($output_format) {
>>> Question: where is the output format feature documented?
>>>
>>> Once I know the out
Wietse Venema wrote:
Rasmus Lerdorf:
Wietse Venema wrote:
Rasmus Lerdorf:
Consider very common (abbreviated) code like this:
$user_data = $_REQUEST['data'];
switch($output_format) {
Question: where is the output format feature documented?
Once I know the output format is not HTML, then I kn
Stut wrote:
> Wietse Venema wrote:
>> Rasmus Lerdorf:
>>> Wietse Venema wrote:
Rasmus Lerdorf:
> Consider very common (abbreviated) code like this:
>
> $user_data = $_REQUEST['data'];
> switch($output_format) {
Question: where is the output format feature documented?
Rasmus Lerdorf wrote:
Stut wrote:
Wietse Venema wrote:
Rasmus Lerdorf:
Wietse Venema wrote:
Rasmus Lerdorf:
Consider very common (abbreviated) code like this:
$user_data = $_REQUEST['data'];
switch($output_format) {
Question: where is the output format feature documented?
Once I know the
Alexey,
On Fri, 2007-10-05 at 19:36 +0400, Alexey Zakhlestin wrote:
> snaps.php.net doesn't have 5.3 yet.
> will it appear there?
We know of the need and will get snaps one of the following days - once
Edin configured all the pieces for yet another branch. Thanks for your
patience. :-)
johannes
Rasmus Lerdorf:
> > I don't think it's unreasonable to require scripts outputting content
> > other than HTML to include a line that modifies the default behaviour.
> > Surely the benefits far outweigh that cost.
>
> That's already there. They set the content-type. The problem becomes
> when the
Stut:
> > That's already there. They set the content-type. The problem becomes
> > when they set it vs. when output goes out. It's also very common to
> > turn on output buffering and buffer a bunch of stuff and then set the
> > content-type just before flushing the buffer.
>
> Maybe it's enoug
Wietse Venema:
> Rasmus Lerdorf:
> > Wietse Venema wrote:
> > > Rasmus Lerdorf:
> > >> Consider very common (abbreviated) code like this:
> > >>
> > >> $user_data = $_REQUEST['data'];
> > >> switch($output_format) {
> > >
> > > Question: where is the output format feature documented?
> > >
> > >
Hello Rasmus,
could you please approve this account?
regards,
Derick
On Fri, 7 Sep 2007, Yiduo (David) Wang wrote:
> Implementing and maintaining the reference cycle garbage collector (GSoC '07)
> for the Zend engine.
>
>
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xd
Developing PEAR Mail_MIME package.
Suggested by [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Not likely, since get_class already contains namespace.
Michael Gauthier wrote:
With PHP 5.3 will there be a get_namespace($object) function equivalent
to get_class($object)?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PR
(Wietse Venema) wrote:
> Rasmus Lerdorf:
>>> I don't think it's unreasonable to require scripts outputting content
>>> other than HTML to include a line that modifies the default behaviour.
>>> Surely the benefits far outweigh that cost.
>> That's already there. They set the content-type. The pro
So it's okay to discuss implementation of esoteric features like class
posing, but something as basic as a string/array slice operation still
gets a knee-jerk reaction? Double standards my friends, double standards..
It's OK to discuss anything about PHP here, I guess. And if you like me
to be
IMO, the point, here, is that, if the requested class starts with
'PEAR2', by convention, this name space is reserved and cannot be
resolved by another handler. So, it is legitimate to want the PEAR2
Then loader should be able to tell the engine that it shouldn't try
another handler.
--
Stanis
Greg Beaver:
[ Charset ISO-8859-1 unsupported, converting... ]
> (Wietse Venema) wrote:
> > Rasmus Lerdorf:
> >>> I don't think it's unreasonable to require scripts outputting content
> >>> other than HTML to include a line that modifies the default behaviour.
> >>> Surely the benefits far outweigh
31 matches
Mail list logo
