Helgi (cvsuser dufuz) said to apply for an account here. I'm taking over
maintainance of the following packages:
pear/SQL_Parser
pear/DBA
pear/DBA_Relational
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
> I personally think it can hurt the PHP project to have expose_php turned
> off by default. A lot of PHP's push has been thanks to the Netcraft
> numbers.
I think a PHP worm would do far more harm, but then again I am not an
marketing expert :-). IMHO the push behind PHP is du
Jasper Bryant-Greene wrote:
> If someone asks me a PHP question on a newsgroup or forum, and I need to
> know their version, I ask them for it. If they don't know how, I tell
> them to run php -V
Too true, in most cases you'd actually want to see their phpinfo() page,
since settings can often expl
Leave it alone. I vote we just drop this discussion. :)
We have lot of more important things to talk about than
about something like this..
--Jani
On Thu, 10 Nov 2005, Wez Furlong wrote:
Turning off expose_php is just security by obscurity; a determined
hacker can still probe
Turning off expose_php is just security by obscurity; a determined
hacker can still probe for problems even if that setting is turned
off.
My vote is to leave it as-is; leave it to the administrator to decide
if they want to turn it off.
--Wez.
On 11/10/05, Marcus Boerger <[EMAIL PROTECTED]> wro
Marcus Boerger wrote:
agreed, also we are doing very much work on security. Thus new and regular
updated systems shouldn#t have a problem with exposing this. And we cannot
do anything for unmaintained systems anyway. Therefore i think we or any
user should not be ashamed or fear having php bein
Hello Andi,
agreed, also we are doing very much work on security. Thus new and regular
updated systems shouldn#t have a problem with exposing this. And we cannot
do anything for unmaintained systems anyway. Therefore i think we or any
user should not be ashamed or fear having php being exposed.
I personally think it can hurt the PHP project to have expose_php
turned off by default. A lot of PHP's push has been thanks to the
Netcraft numbers.
Andi
At 10:56 AM 11/10/2005, Wolfgang Drews wrote:
> > I don't think it would reduce the number of attacks turning the
> > version information
sorry list,
this discussion is going into a totally wrong direction. To make my
point clear once again:
>> it's all just a question of user-perception! <<
there is definitely NO NEED to discuss any security-items in this place
- instead i wanted to make the right people think about chang
Peter Brodersen wrote:
On Thu, 10 Nov 2005 14:08:29 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alshanetsky) wrote:
I don't think it would reduce the number of attacks turning the
version information off. But it would be more cumbersome to help
people with php issues as the php version is n
On Thu, 10 Nov 2005 14:08:29 -0500, in php.internals [EMAIL PROTECTED]
(Ilia Alshanetsky) wrote:
>> I don't think it would reduce the number of attacks turning the
>> version information off. But it would be more cumbersome to help
>> people with php issues as the php version is not directly avail
Markus Fischer wrote:
> Wolfgang Drews wrote:
>
I don't think it would reduce the number of attacks turning the
version information off. But it would be more cumbersome to help
people with php issues as the php version is not directly available.
>>>
>>>
>>> Right, that was my point
Wolfgang Drews wrote:
I don't think it would reduce the number of attacks turning the
version information off. But it would be more cumbersome to help
people with php issues as the php version is not directly available.
Right, that was my point too.
yes, but in the end it is more a problem
The expose_php setting is an option, something each admin can make their
own mind upon. Some will prefer not to waste bandwidth and tell the
world what they are running, while others prefer to advertise PHP.
Either approach is fine, but from security perspective you want to tell
a potential attacke
> > I don't think it would reduce the number of attacks turning the
> > version information off. But it would be more cumbersome to help
> > people with php issues as the php version is not directly available.
>
> Right, that was my point too.
yes, but in the end it is more a problem of user-pe
On Thu, 10 Nov 2005, Peter Brodersen wrote:
> Those targeting specific web sites might be able to figure out the
> approximate version otherwise. The major version of php could be
> determined in a couple of other ways, such as checking what animal
> (sorry Thies :-) is present, e.g.:
> http://www
On Wed, 2005-11-09 at 10:03 +0200, Jani Taskinen wrote:
> Anyway, it might be the time to cleanup the API of this extension
> and make it simpler. It's pretty confusing as it is.
> The returned arrays are also weird with their "count" fields and such.
OK, Jani.
I've removed those "
On Thu, 10 Nov 2005 16:13:34 +0100, in php.internals [EMAIL PROTECTED]
("Wolfgang Drews") wrote:
>my suggestion would be, to simply shorten the string that gets
>exposed to "php" - and not show any version numbers (or maybe leave
>it to the user, say 0 for "no exposure", 1 for "only php" and 2 for
> my suggestion would be, to simply shorten the string that
> gets exposed to "php" - and not show any version numbers (or
> maybe leave it to the user, say 0 for "no exposure", 1 for
> "only php" and 2 for "php with version number".
At least it would be interesting to know about the spread of
hi list,
i just came back from phpconference in frankfurt and had some nice
talks there with Ilia and Derick. They told me to send my following
thoughts to internals, so that you maybe can find a wise solution for
it.
as security gets more and more recognized by many people, they do
follow all th
On 11/9/05, Marco Bambini <[EMAIL PROTECTED]> wrote:
> ZEND_FUNCTION(rsql_disconnect)
> {
> ...
> ZEND_FETCH_RESOURCE2(rsqldb, void*, theConnectionParameter, -1,
> kConnIDString, rsql_connection, rsql_pconnection);
> if (rsqldb) zend_list_delete(Z_LVAL_PP(theConnectionParame
Hi,
I have made two patches for two open bugs of the sockets extension.
I would like to ask if someone can review/commit them:
http://bugs.php.net/bug.php?id=35062 - bogus warning produced
http://bugs.php.net/bug.php?id=21197 - php_read() doesn't work on windows
Thanks,
Nuno
--
PHP Internals
Hello Mike, Thies,
i can only agree here, we just invented another inconsistency to violate
the beloved KISS approach once more for no particular reason. And this also
contradicts the arguments we use elsewhere.
marcus
Thursday, November 10, 2005, 1:35:56 AM, you wrote:
> The problem does not
23 matches
Mail list logo