On Sun, 18 Aug 2002, Edin Kadribasic wrote:
Exactly right. During the last release cycle, Derick made elaborate test
cases, etc. but the result was not very promising. Very few people actually
took part in the QA process and as a result 4.2.0 was released with some
serious bugs in it.
I
At 10:12 19/08/2002, [EMAIL PROTECTED] wrote:
I'd like to hear Stig's opinion on 4.3.0 first, and I tend to agree that
we need a 4.2.3 too. I can even find time to do the release process and
manage QA, providing there is any feedback to the RC.
I would actually like to do that once, if you don't
On Mon, 19 Aug 2002, Zeev Suraski wrote:
At 10:12 19/08/2002, [EMAIL PROTECTED] wrote:
I'd like to hear Stig's opinion on 4.3.0 first, and I tend to agree that
we need a 4.2.3 too. I can even find time to do the release process and
manage QA, providing there is any feedback to the RC.
I
At 10:15 19/08/2002, [EMAIL PROTECTED] wrote:
I would actually like to do that once, if you don't mind :)
I don't mind at all... but what is the reason for this? :)
Well, first it's been a while since I did, but I'd also like to see it
working in the 'new way' once, with the automated QA...
On Mon, 19 Aug 2002, Zeev Suraski wrote:
At 10:15 19/08/2002, [EMAIL PROTECTED] wrote:
I would actually like to do that once, if you don't mind :)
I don't mind at all... but what is the reason for this? :)
Well, first it's been a while since I did, but I'd also like to see it
working
Rasmus Lerdorf wrote:
Ok, then that is a bug that needs to be fixed before 4.3.
This is one of the current session module behavior that I worry.
We need at least strlen. (and char range check)
I check them both in my save handler. (Not published session_pgsql,
but my private session save
At 10:22 19/08/2002, [EMAIL PROTECTED] wrote:
On Mon, 19 Aug 2002, Zeev Suraski wrote:
At 10:15 19/08/2002, [EMAIL PROTECTED] wrote:
I would actually like to do that once, if you don't mind :)
I don't mind at all... but what is the reason for this? :)
Well, first it's been a while
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 9:20 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3
At 10:22 19/08/2002, [EMAIL PROTECTED] wrote:
On Mon,
Dan Kalowsky wrote:
Hi Kevin
On Sun, 18 Aug 2002, Kevin Gordon wrote:
The first two functions return resource and the second two functions
return int. Is there any difference?
In this case, not really. I think I should probably update some of the
documentation it seems.
Using
On Sun, Aug 18, 2002 at 11:48:03PM +0300, Andi Gutmans wrote:
At 07:50 PM 8/18/2002 +0200, Thies C. Arntzen wrote:
On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote:
I don't think we should stop people from tweaking ZE1. ZE2 is probably
more than a year away from realistically
At 11:36 19/08/2002, Thies C. Arntzen wrote:
my apache 2.0 thing got misinterpreted a bit - let me
clearify: apache2.0 is ready, it works and it's even better
than 1.3 (the httpd itself). but ppls don't upgrade all
threir servers immediatly. as rasmus mentioned, the same
traceroute to synacor1.php.net (208.210.50.162), 30 hops max, 40 byte
packets
[...]
3 pos8-1.hsipaccess1.Frankfurt1.Level3.net (212.162.47.93) 3 ms 3 ms 4
ms
4 unknown.Level3.net (195.122.136.34) 4 ms 4 ms 4 ms
5 so-3-0-0.mp2.London1.Level3.net (212.187.128.57) 18 ms 18 ms 18 ms
6
On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote:
How often do you call a function that gives you your current backtrace in
C? In my many years of C experience, I would have to say that the accurate
answer is -0- times. You really should compare apples with apples...
you
At 13:30 19/08/2002, Thies C. Arntzen wrote:
On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote:
How often do you call a function that gives you your current backtrace in
C? In my many years of C experience, I would have to say that the
accurate
answer is -0- times. You
Stanislav Malyshev wrote:
stasSun Aug 18 08:22:28 2002 EDT
Modified files:
/php4/ext/standard var_unserializer.re
Log:
ZE2 compatibility fix
## In ZE2 the hash contains zend_class_entry *!
Please commit an updated version of the re2c output as well.
--
SB /php4/ext/standard var_unserializer.re
SBLog:
SBZE2 compatibility fix
SB## In ZE2 the hash contains zend_class_entry *!
SB
SB Please commit an updated version of the re2c output as well.
OK, did so.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]
Hi,
I've been trying to convert my latest code (heavily object orientated with a
lot of referencing) to get it ready for Zend 2 but there are problems! Both
these problems come from the Smarty template code so if these are changes
instead of bugs I will post this message on the Smarty board.
1)
Hello,
I need to link some external libs statically into a shared php extension.
If I compile this extension statically with php, all external libs also
linked statically in, the extension can be used.
I can't figure out how I have to modify the many configuration files to get
the additional
On Mon, 19 Aug 2002, Ron Lange wrote:
Hello,
I need to link some external libs statically into a shared php extension.
If I compile this extension statically with php, all external libs also
linked statically in, the extension can be used.
I can't figure out how I have to modify the
Hi list
I am looking for credit card processing scripts. How can I validate credit
card limits?
Does anybody know some solutions?
Toni
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two session-related things I'd
like to see
hi,
this patch fix bug #18654 by extending the nvexp definition.
The diff contains the resulting re2c var_unserializer.c.
Index: var_unserializer.c
===
RCS file: /repository/php4/ext/standard/var_unserializer.c,v
retrieving
Hi
I started coding a WebDAV Server in userlan php. Unfortunately it needs
patching of the PHP-Sources, 'cause php does not accept http OPTIONS and
HTTP_RAW_POST_DATA for other http-directives than POST, which a WebDAV
server needs.
The patch can be found at http://trash.chregu.tv/webdav.diff
Stanislav Malyshev wrote:
OK, did so.
/usr/src/php4/ext/standard/var_unserializer.c:1: parse error before ''
token
In file included from /usr/include/bits/types.h:143,
from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/include/stdio.h:45,
from
SB /usr/src/php4/ext/standard/var_unserializer.c:1: parse error before ''
SB token
I fear that has something to do with your CVS checkout... There's no 's
in CVS version (and yes, it compiles just fine).
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Hi David,
David Eriksson wrote:
Use PHP_ADD_LIBRARY_WITH_PATH or PHP_ADD_LIBRARY in your config.m4
Already done...
My config.m4:
Note: IndiComm, ndr and mmem have to be statically linked into this module!
--
INDI_PROJECT_PATH=/home/ron/INDI
You cannot audit a credit card for an available
limit. Think of the implications for fraud on that!
Someone would be able to ask how much they can spend
on this stolen credit card number?! That's obsurd!
Now if you want credit card processing, you can use
a software solution like MCVE
Hi,
We are working on porting PHP for NetWare.
We have a question here: Has PHP been tested on any 64-bit Operating System?
Thanks,
Ananth.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Absolutely,
PHP is used on production servers in many 64 bit Operating Systems.
I use it myself on our production SPARC solaris servers.
Also, you may note that PHP has been ported to Novell Netware in the
past:
http://developer.novell.com/ndk/leadedge.htm#le169
However, it seems to be a beta
Hi Christian,
I'm interested in this, so that I can export a virtual filesystem from
a big web application.
I think Rasmus did some work on something in CVS in a branch called
APACHE_HOOKS or something; it we do integrate your patch, it's probably
worth combining your work with that code.
I'm a web developer start using PHP since 1999. I'm also the board master
of PHP discussion group of Netease.com BBS - one of the largest BBS in
China.
There are a very large amount of PHP users in China, but most of them have
difficulty in reading English documents, which restrict their
Well, the stuff I did in the apache_hooks branch shows how you can hook
into other stages of the request chain and, for example, define a PHP
script to be called at the url translation stage or the auth stage. The
latter would allow you to perform PHP-based auth on all files, not just
PHP files,
-Original Message-
From: Ananth Kesari [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 5:37 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP tested on 64-bit OS?
We are working on porting PHP for NetWare.
We have a question here: Has PHP been tested on any 64-bit
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, the stuff I did in the apache_hooks branch shows how you can hook
into other stages of the request chain and, for example, define a PHP
script to be called at the url translation stage or the auth stage. The
latter would allow you to perform
nope. OPTIONS is not handled at all by PHP at the moment, therefore i made
this change with accept_options (OPTIONS is explicitely blocked right
now). The other primitives which have POST data (see
http://asg.web.cmu.edu/rfc/rfc2518.html for the details)
PROPFIND
PROPPATCH
PUT
MOVE
COPY
On Mon, 19 Aug 2002, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
I don't think that's the way to do it at all. In theory, it's no
problem to track whether changes were made to the session data, and
perform the write at the end of the request, only if we tracked a
change. That's only in
But there are still a lot of cases where not writing the session data
at
the end of a request will simplify things quite a bit and also be much
more efficient. I am not too concerned about not writing based on
whether
or not data changed, I'd like the user to be able to specify that it
shouldn't
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
nope. OPTIONS is not handled at all by PHP at the moment, therefore i made
this change with accept_options (OPTIONS is explicitely blocked right
now). The other primitives which have POST data (see
http://asg.web.cmu.edu/rfc/rfc2518.html for the
The apache_hooks looks like it's a lot more involved than your nice and
simple patch. Your patch looks good to me, although I'm not an apache guru.
I wouldn't have any objections to applying it to HEAD and having it in 4.3.
--Wez.
On 08/19/02, Wez Furlong [EMAIL PROTECTED] wrote:
I think
Yeah, they are. That's why they are on a branch and haven't really gone
anywhere. They are destabilizing and I don't have the free time required
to integrate them and test them properly at this point.
-Rasmus
On Mon, 19 Aug 2002, Wez Furlong wrote:
The apache_hooks looks like it's a lot
Perhaps I just haven't looked hard enough, but I can't find any
information on how PECL software is supposed to be compiled (in CVS).
Most PECL packages just have a config.m4 and a Makefile.in, but no
configure.in, build.sh, etc. I'm adding a new PECL package and would
like it to play nicely with
run phpize in the extension's dir
On 19 Aug 2002, Dan Helfman wrote:
Perhaps I just haven't looked hard enough, but I can't find any
information on how PECL software is supposed to be compiled (in CVS).
Most PECL packages just have a config.m4 and a Makefile.in, but no
configure.in,
You could also use the latest version of the PEAR installer, of course.
-Tal
Original Message
From: Rasmus Lerdorf [EMAIL PROTECTED]
To: Dan Helfman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] PECL compilation
Date: Mon, 19 Aug 2002 13:01:20 -0700 (PDT)
Thanks.. I didn't realize the PEAR installer worked on PECL packages
currently.
On Mon, 2002-08-19 at 13:46, Tal Peer wrote:
You could also use the latest version of the PEAR installer, of course.
-Tal
Original Message
From: Rasmus Lerdorf [EMAIL PROTECTED]
To: Dan
Hi all,
Following on from the recent debug_backtrace discussion, and the discussion
about just what we are releasing next and so on, I'd just thought I would
make a couple of comments about PHP 4.3 and about what I think (IMHO)
should be the goals of PHP 5.
I'm currently reviewing the streams
Rasmus Lerdorf wrote:
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two
Rasmus Lerdorf wrote:
No, I think the check we need here is one that checks to see if the
session specified in the user-supplied PHPSESSID exists. If it does not
exist, toss that session id and replace it with a PHP-generated one.
Perhaps Sascha has some thoughts on these two
Rasmus Lerdorf wrote:
On Mon, 19 Aug 2002, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
I don't think that's the way to do it at all. In theory, it's no
problem to track whether changes were made to the session data, and
perform the write at the end of the request, only if we tracked a
change.
Well, more worrisome would be if a bad guy tricks you into clicking on a
link or simply sends you an image in an email that makes a request to my
server with a valid-looking session id. Then if you go to this site (that
I've debunked that scenario already a few times. The net
result
Well, while it is true that it is impossible to completely prevent, our
current setup doesn't do anything at all to prevent it which makes the
attack much simpler. There is currently no need for the attacker to visit
the site to be attacked at all and thus he doesn't need any keepalive
stuff to
maybe you should implement a dynamic_sid flag, which would make SID behave
in the following way
page.php?sid=sidvaluekey
after you would visit that page, you would get all url's in the page encoded
with
page.php?sid=newvaluekey
so basically, the SID value expires (or should i say mutates) on
matching ip limits the number of session hijackings to atleast the same
network you are on (behind a fw/router which does nat), and the users who
use the same http proxy as you (in case you use one)
so its either expire/generate (rotate,morph,mutate) SID on each pageload, or
the more
Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to completely prevent, our
current setup doesn't do anything at all to prevent it which makes the
attack much simpler. There is currently no need for the attacker to visit
the site to be attacked at all and thus he doesn't
I noticed that make test runs (or skips) some tests in
ext/skeleton. It should probably skip that dir.
Also, the array tests are failing because they expect output
like -0.33 but are getting -.33. (no leading
0 before the decimal point).
Could someone who knows what they are
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to completely prevent, our
I've been through this argument a couple of times and I don't
plan to spend more time on it.
If you want your site to be safe, enable
session.use_only_cookies and
But could you at least answer the question? What is the advantage of
allowing user-supplied new session ids? I see no reason not to add a
check for this.
On Tue, 20 Aug 2002, Sascha Schumann wrote:
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
Well, while it is true that it is impossible to
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
But could you at least answer the question? What is the advantage of
allowing user-supplied new session ids? I see no reason not to add a
check for this.
For example, I have a set of C programs for IRCG load
testing. It uses a simple FSM
On Mon, 19 Aug 2002, Rasmus Lerdorf wrote:
But could you at least answer the question? What is the advantage of
allowing user-supplied new session ids? I see no reason not to add a
check for this.
For example, I have a set of C programs for IRCG load
testing. It uses a
On Monday, August 19, 2002, at 07:56 PM, Rasmus Lerdorf wrote:
To conclude: Don't trade useful features for pseudo security.
Removing this feature just increases the feeling of having a
'secure' site and decreases the desire to protect oneself by
activating
To play devil's advocate, pure cookie based authentication is not a
panacea. If you allow users to put things like javascript on your site,
or if you have users who exploit ie bugs like the about: cookie domain
bug from last year, cookies can be stolen and session hijacked. pure
cookie
Wouldn't it make more sense to display ONLY those tests which
fail, and nothing else? It would be much easier to spot those
which matter most..
--Jani
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I think it would be hard to distinguish when a positive test result is not
important. For example, the SAPI module checks we would want to see the
'yes' result and not all the 'no' results since they are meaningless.
What I would like to see is a nice summary at the end that gives some
useful
yeah, it works :-)
(tested win98, xp)
--- old_readdir.h 2000-07-02 23:46:52.0 +
+++ readdir.h 2002-08-20 01:50:20.0 +
-38,7 +38,7
struct dirent *readdir(DIR *);
int readdir_r(DIR *, struct dirent *, struct dirent **);
int closedir(DIR *);
-void rewinddir(DIR
(I might have sent this one twice again...)
--
why not simply allow a maximum amount of time a session can exist (let's say, 25
minutes).
This could be customised or even disabled by the administrator so it won't be a flea
to regular users, and even though it won't be bulletproof, it
This is not the issue we are discussing. PHP already times out inactive
sessions, and in this particular case the session has even been created
yet, so there is nothing to time out.
-Rasmus
On Mon, 19 Aug 2002, Xavier Spriet wrote:
(I might have sent this one twice again...)
--
why not
On Monday, August 19, 2002, at 10:24 PM, Xavier Spriet wrote:
(I might have sent this one twice again...)
--
why not simply allow a maximum amount of time a session can exist
(let's say, 25 minutes).
This could be customised or even disabled by the administrator so it
won't be a
I was not refering to a way to timeout inactive session but instead to allow the
administrator
to override this policy by a stricter one and allow a maximum active session time if
he decides to implement it.
Which means a user may do what they have to do on your site for x amount of minutes
Again, this is a good step, but is not at all effective against an
attacker motivated to compromise your site.
You are right. However, it could be an acceptable policy to improve overall
security.
The problem is, while this
Thank you Gentlemen for the information.
Well, it is our team that ported PHP for NetWare and released the beta version. We are
now working further on it to release the FCS version. We will also be merging our
souces completely into the CVS tree.
Thanks,
Ananth.
Sebastian Nohn [EMAIL
On Mon, 19 Aug 2002, Ron Lange wrote:
Hi David,
David Eriksson wrote:
Use PHP_ADD_LIBRARY_WITH_PATH or PHP_ADD_LIBRARY in your config.m4
Already done...
My config.m4:
Note: IndiComm, ndr and mmem have to be statically linked into this module!
70 matches
Mail list logo
