Rasmus Lerdorf:
> So how about something like this:
>
> generator function f() {
> echo "Hello World";
> }
>
> generator function f() {
> return 1;
> }
>
> generator function f($arg) {
> if(f!$arg) yield 1;
> else if($arg<0) return 1;
> else return;
> }
>
> What does the generator key
Rasmus Lerdorf:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 6/23/10 6:56 AM, Wietse Venema wrote:
> > Stas Malyshev:
> >> Hi!
> >>
> >>> could anybody tell me why also for every single php file engine must lstat
> >>> all path?
> &g
Stas Malyshev:
> Hi!
>
> > could anybody tell me why also for every single php file engine must lstat
> > all path?
> > Why php engine don't simply try to open directly the file?
>
> There are some places where PHP engine has to know "true" name of the
> file - i.e. filename that would be the sa
Rasmus Lerdorf:
> The ABNF for an HTML5 valid email field is:
>
> 1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )
>
> which means there must be a . in the domain part, so HTML5 doesn't think
> a...@b is valid either. The left-hand side looks wrong though. It seems
> to me it should be:
>
>
Joey Smith wrote:
> 3) I don't have an Apple platform for testing, what will happen on
> Mac if PHP_EOL is used as the separator for $additional_headers? I
> would like to change the documentation to say "Multiple extra
> headers should be separated with the PHP_EOL constant", but I'm not
> the lea
Joey Smith:
> On Fri, Aug 21, 2009 at 04:55:31PM +0100, Chris Smith wrote:
> >
> > I've encountered difficulties utilising the mail() function properly
> > under a NIX environments while conforming to RFC 2822. There two
> > specific issues, one is a code problem the other a documentation
> > issu
Pierre Joye:
> hi,
>
> On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal <[EMAIL PROTECTED]> wrote:
>
> > but now it's too late for such changes,
> > we have to put the old behavior back.
>
> Even if it may mean drop the new ini parser and features?
If you can allow both old and new behavior to co-
This is an update on my preliminary implementation of support for
tainted variables in PHP. To get more feedback from developers with
Windows systems, I have built Win32 binaries. These are available
in ZIP and Windows installer format from http://wiki.php.net/rfc/taint/
and are compatible with the
This is an update on my preliminary implementation of support for
tainted variables in PHP. To get more feedback from developers with
Windows systems, I have built Win32 binaries. These are available
in ZIP and Windows installer format from http://wiki.php.net/rfc/taint/
and are compatible with the
Hector Santos:
> Johannes Schl?ter wrote:
> > Hi,
> >
> > On Thu, 2008-05-15 at 00:49 -0400, Hector Santos wrote:
> >>- All that is needed with a source distribution or as a
> >> separate distribution, is a PHPMAKE package that
> >> might include a root folder:
> >>
> >> phpmake
Steph Fox:
> Hi Hector,
>
> > I can confirm that nmake v6 from VS C/C++ 6.00 did not exhibit the
> > problem. However nnake (v8) from VS 2005 does exhibit the problem.
> > Richard was using nmake v9 (VS 2008).
> >
> > The problem begins with having /cygwin/bin folder in the PATH statement
> > and
Richard Quadling:
> Effectively nmake is not respecting the shell to run internal commands.
>
> As you can see (hopefully), rmdir is a SHELL command, even if an
> executable exists with the same name and that executable is in the
> path.
>
> The issue is that nmake doesn't respect the shell comma
Steph Fox:
> Hi Wietse,
>
> > This is a bug in PHP Makefiles. You can use the depend.php script
> > that ships with my taint-for-PHP code. http://wiki.php.net/rfc/taint.
> >
> > To apply (on *n*x systems):
>
> That's not very helpful for Richard's Windows-specific query :)
Excuse me for trying
Richard Quadling:
> Hi.
>
> I'm new to compiling PHP on windows, so this may be a real newbie question.
>
> My expectation of make-like tools is that they describe the how to
> create targets from sources (in a nutshell).
>
> So, just for example, TSRM/readdir.h. I would expect that if I altered
FYI,
Taint support for PHP 5.2.5 has been updated. The 20080423 version
improves support for PCRE, and fixes a harmless read-after-free bug.
The primary goal of this code is to help PHP application programmers
find and eliminate opportunities for HTML script injection, SQL or
shell code injection
Kalle Sommer Nielsen:
> Hey Internals
>
> I've been wondering for quite some time why PHP doesn't allow you
> to access arrays when you assign it to a value like in Javascript:
In many languages you get such functionality for free, because their
parsers are written to accept:
expression '['
Johannes Schl?ter:
> Hi,
>
> On Fri, 2008-04-11 at 16:07 -0400, (Wietse Venema) wrote:
> > According statistics at nexen.net, PHP4 is now 68% of the installed
> > base (8 years of deployment) and PHP5 is 32% (almost 4 years). The
> > lesson I draw from this is that a
Lukas Kahwe Smith:
>
> On 11.04.2008, at 21:41, Ryan Panning wrote:
> > Lukas Kahwe Smith wrote:
> >> Native unicode is not big enough for you?
> >> regards,
> >> Lukas
> >
> > If you're looking for good PR and reviews, no. I think if you have
> > very limited new features, the people writing re
Rasmus Lerdorf:
> You can also choose to never store the raw single quote and always work
> with encoded data. Or, as I suggest, always filter it by default and in
> the places where you want the raw quote back or you want it filtered for
> a specific use, specify explicitly which filter you wa
Rasmus Lerdorf:
> Soenke Ruempler wrote:
> > Hi Rasmus,
> >
> > On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote:
> >
> >> This is what the filter extension is for. You should be working with
> >> escaped data by default and only poke a hole in your data firewall in
> >> the few places where you n
Stefan Walk:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Wednesday 30 January 2008 20:52:40 Stanislav Malyshev wrote:
> > > I don't think the 'FOO' syntax is very obvious either, but I can't think
> > > of a better one and if there isn't a commonly known syntax we can steal
> > > from an
Mark van der Velden:
> And how does this work with the Filter ( http://docs.php.net/filter )
> extension ?
SQL, HTML, shell, etc. have different quoting mechanisms. Taint
support can check whether the required quoting mechanism is used,
and is not limited to input from the web client.
W
I've uploaded a new version of taint support for PHP. You can find
all the files via:
ftp://ftp.porcupine.org/pub/php/index.html
This version supports PHP 5.2.5, and fixes one typo in mysqli
support (thanks Adam Gundy). Little has changed because I wanted
to catch up with the current PHP rele
Sorry for the noise. That was meant to be forwarded off-list.
Wietse
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
There's a lot of confusion on php-internals about a proposal for
type hinting, so someone did a writeup on related terminology,
including something called "popcorn WTF".
Wietse
- Forwarded message from Martin Alterisio -
Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2008 23:58
troels knak-nielsen:
> If taint-mode is intended for testing only, it would never be
> something, which was turned on per default. Then maybe a tool such as
> php-sat ( http://www.program-transformation.org/PHP/PhpSat ) is a
> better solution? It seems to me like there is a rather big overlap
> bet
Stefan Esser:
[ Charset ISO-8859-1 unsupported, converting... ]
> Wietse Venema schrieb:
> > Stefan Esser:
> >
> >> 2) Using mysql_real_escape_string() on user input does not make it safe
> >> for SQL. It only makes SQL strings safe.
> >&
Stefan Esser:
> 2) Using mysql_real_escape_string() on user input does not make it safe
> for SQL. It only makes SQL strings safe.
> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
> is NOT secure but will result in no taint warning
Can you give a specific example? I'd lik
Stefan Esser:
[ Charset ISO-8859-15 unsupported, converting... ]
> Hi Steph,
>
> >
> > In a preliminary release for feedback purposes you talk about wrong
> > assumptions? Surely this is the whole point of having a preliminary
> > release for feedback :)
> yes of course it is preliminary. But the
Christian Schneider:
> First of all: I've been playing around with it and it looks great!
>
> Some comments:
> 1) I added taint support to func_get_args() and func_get_arg(), a patch
> is attached.
Thanks. I will add a .phpt test script so that from now on it will
always work.
> 2) Maybe the fun
Wietse Venema:
> PHP compiles error-free with:
>
> $ fetch ftp://ftp.porcupine.org/pub/php/php-5.2.3-taint-20071103.tar.gz
> $ gzcat php-5.2.3-taint-20071103.tar.gz | tar xf -
> $ cd php-5.2.3-taint-20071103
> $ ./configure
And also with:
./configure --enable-taint
Cristian Rodriguez:
> 2007/11/3, Wietse Venema <[EMAIL PROTECTED]>:
>
> > OK, I have updated the apache2 module SAPI, a
>
> The CGI sapi. using this tarball
> ftp://ftp.porcupine.org/pub/php/php-5.2.3-taint-20071103.tar.gz
>
> does not compile
>
> /h
Tomas Kuliavas:
> make distclean
> ./configure --prefix=/somepath/php \
> --with-config-file-path=/somepath/config/ \
> --with-apxs2=/somepath/apache/bin/apxs \
> --enable-taint \
> --enable-mbstring --disable-mbregex \
> --with-gettext=/usr \
[17 more lines deleted]
OK, I have updated the ap
Tomas Kuliavas:
> > A preliminary implementation of PHP taint support is available from
> > ftp://ftp.porcupine.org/pub/php/ This code is released under version
> > 2.00 of the Zend license.
> >
> > Below are fragments from the README file. For the full text please see
> > ftp://ftp.porcupine.org/p
Nuno Lopes:
> Hi,
>
> It sounds cool, indeed.
> The obvious question now is: how it performs with real-world applications?
This is the main reason I asked for feedback from the list :-)
> Have you been able to identify security bugs (either new or already known)?
> I don't have time to perform
.README.html
This file also has information about using taint in real applications,
about run-time performance, and about changes within the PHP core.
Most of all, your feedback is welcome, so that I can make this code
as easy to use and as performant as possible.
Wietse Venema
IBM
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 defau
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
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
Wietse Venema:
> Rasmus Lerdorf:
> > Wietse Venema wrote:
> > > Rasmus Lerdorf:
> > >> Consider very common (abbreviated) code like this:
> > >>
> > >> $user_data = $_REQUEST['data'];
> > >> switch($output_fo
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 forma
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
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:
> >>>
> >>> &
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
David Wang:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 10/2/07, Wietse Venema <[EMAIL PROTECTED]> wrote:
> > Low-level implementation
> >
> >
> > Taint support is implemented with some of the unused bits in the
> > z
A while ago I posted a proposal to add support for tainted variables
to PHP, to alert programmers at run-time when they make the common
mistake of using uncleansed input with include, echo, system, open,
etc. A copy of the original post can be found on-line, for example,
at http://marc.info/?l=php-
Late last year I started a discussion on this list with a proposal
to add Perl/Ruby-like taint support to PHP - a feature that a
developer may turn on to find out where to insert explicit cleaning
operations to avoid code injection etc. vulnerabilities. With
applications that are explicitly writte
This 30-line script was originally written in Perl, but it didn't
seem proper etiquette to post non-PHP code on this list :-)
So I morphed it into PHP, admittedly with a Perl accent.
If I overlooked an already existing way to minimize PHP build time,
without the risk of using out-of-date .lo fil
[A quote that I might end up using somewhere]
> > Very well put/explained.
>
> If it was only about the input filtering, you can use (and should)
> ext/filter (filter.default=string with default flag strip low/high).
>
> And more generally since I use filter filter in my projects, I do not
> use
Zeev Suraski:
> My 2c on this piece is that tainting can be a nice helper tool to
> reduce the likelihood of security problems in your code. Nothing
> more and nothing less.
>
> I too fear the possibility of tainting becoming the new
> safe_mode. "Outsource your security to PHP, it'll take ca
Richard Lynch:
> On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> > Even if some taint check is to restrictive at some point in time,
> > the programmer can always overcome it with an explicit action.
>
> Would that require some sort of bogus string non-manipulation
Ilia Alshanetsky:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec().
You need a malicous code writer to have an exploit. As far as I
know, PHP is not a platform for
Ilia Alshanetsky:
> On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:
> > Ilia Alshanetsky:
> >> That means an additional element to a struct that has thousands of
> >> instances in most scripts, this will be the first overhead caused by
> >> the memory footprin
Ilia Alshanetsky:
>
> On 15-Dec-06, at 4:16 PM, Stanislav Malyshev wrote:
>
> >> Sounds awefuly like yet another safe_mode, something that
> >> proclaims security, yet being unable to provide it.
> >
> > Repeating my comments on that, I think that it can be done not like
> > safe_mode, if we
Ilia Alshanetsky:
> > - Each ZVAL is marked tainted or not tainted (i.e. we don't taint
> > individual characters within substrings). Black and white is all.
> > In some future, someone may want to explore the possibility of
> > more than two shades. But not now.
>
> That means an additiona
Please allow me to introduce myself briefly: I'm Wietse Venema from
IBM Research, also known as the creator of the open source Postfix
mail system, co-author of the Coroner's toolkit and SATAN, and the
original author of TCP Wrapper. That doesn't mean everything I touch
becomes
56 matches
Mail list logo
