Florian Weimer wrote:
> * Henrique de Moraes Holschuh:
>
> > I think not only we should do it, we should also make a big fuss
> > about it, so that some of the PHP people out there at least have a
> > chance to get the clue.
>
> Unlikely to work. Just look at how almost all PHP developers reject
* Henrique de Moraes Holschuh:
> I think not only we should do it, we should also make a big fuss
> about it, so that some of the PHP people out there at least have a
> chance to get the clue.
Unlikely to work. Just look at how almost all PHP developers reject a
proactive approach to SQL injecti
> > While all config files are accessible via the web, they
> have .php and are a no-op when executed seperately.
>
> What if for whatever reason the PHP module isn't enabled at some point
> in time?
> I'd rather have those files become unavailable then being server as
> plain text.
Also, if the
> While all config files are accessible via the web, they
have .php and are a no-op when executed seperately.
What if for whatever reason the PHP module isn't enabled at some point
in time?
I'd rather have those files become unavailable then being server as
plain text.
--
Olaf van der Spek
http:/
On Mon, 02 May 2005, Thijs Kinkhorst wrote:
> Your viewpoint requires shell access for webmasters and that creates extra
Why? It is not too difficult to make your PHP scripts use ../include/foo for
their includes, and that is all it takes to get the crap out of the exported
tree.
> dependencies m
On Sat, April 30, 2005 14:54, Martin Schulze wrote:
>> "Simple makefile" doesn't match the typical person installing a web
>> application. A .tar.gz may already be too difficult, they want to be able
>> to ftp their files to their provider and it should work. Also, this
>
> Such people should stay
Jeroen van Wolffelaar wrote:
> > Having /usr/share/$package for the include files and
> > /var/lib/$package for the executable PHP scripts that should be linked
> > into the web server.
>
> Eh, that's now how squirrelmail works. All stock php files are in
> /usr/share/$package, and that's also wha
On Sat, Apr 30, 2005 at 07:55:31AM +0200, Martin Schulze wrote:
> Hans Spaans wrote:
> > Martin Schulze wrote:
> > > Hey!
> > >
> > > What do people on this list think about fixing PHP include files in a
> > > DSA that are accessible via HTTP as well and contain one bug or
> > > another as they ar
On Thu, Apr 28, 2005 at 03:45:48PM +0200, Jeroen van Wolffelaar wrote:
> It'd be wise for those projects to take the extra precaution by allowing
> (and the Debian maintainer to do so) include files outside the web root,
> but to DSA for such a thing when there might not even be a vulnerability
> a
Martin Schulze schrieb:
> No. Include files should be vhost-agnostic. If they aren't, a lot
> has gone wrong during implementation. It should be sufficient to just
> install the accessible PHP files a second time and maybe adjust the
> database or other local storage, i.e. a differend config fi
Jeroen van Wolffelaar wrote:
> > What do people on this list think about fixing PHP include files in a
> > DSA that are accessible via HTTP as well and contain one bug or
> > another as they are not supposed to be accessible via HTTP but
> > accidently are.
> >
> > I'm rather annoyed by the lack o
Hans Spaans wrote:
> Martin Schulze wrote:
> > Hey!
> >
> > What do people on this list think about fixing PHP include files in a
> > DSA that are accessible via HTTP as well and contain one bug or
> > another as they are not supposed to be accessible via HTTP but
> > accidently are.
>
> Patching
On Fri, April 29, 2005 1:42, Javier Fernández-Sanguino Peña said:
> On Thu, Apr 28, 2005 at 10:04:00PM +0200, Hans Spaans wrote:
>> Is this going to solve the problems? Don't get me wrong, because I love
>> your goal but I don't believe that what you suggesting right now is
>> going to solve the pr
On Thu, Apr 28, 2005 at 10:04:00PM +0200, Hans Spaans wrote:
> Is this going to solve the problems? Don't get me wrong, because I love
> your goal but I don't believe that what you suggesting right now is
> going to solve the problems with PHP at this moment. Maybe its an idea
> to get in contact w
Hans Spaans a Ãcrit :
It may be a better idea to start with PHP itself and ask during
installation of the users wants to install a secure or insecure version
of php4.ini. The same is done with setuid issues for example.
Great idea! And I would suggest to have multiple choices,
depending on the leve
Martin Schulze wrote:
> Hey!
>
> What do people on this list think about fixing PHP include files in a
> DSA that are accessible via HTTP as well and contain one bug or
> another as they are not supposed to be accessible via HTTP but
> accidently are.
Patching them like Squirrelmail has fixed thi
On Thu, 28 Apr 2005, Martin Schulze wrote:
> What do people on this list think about fixing PHP include files in a
> DSA that are accessible via HTTP as well and contain one bug or
> another as they are not supposed to be accessible via HTTP but
> accidently are.
I think not only we should do it,
On Thu, Apr 28, 2005 at 03:15:08PM +0200, Martin Schulze wrote:
> Hey!
>
> What do people on this list think about fixing PHP include files in a
> DSA that are accessible via HTTP as well and contain one bug or
> another as they are not supposed to be accessible via HTTP but
> accidently are.
>
>
Hey!
What do people on this list think about fixing PHP include files in a
DSA that are accessible via HTTP as well and contain one bug or
another as they are not supposed to be accessible via HTTP but
accidently are.
I'm rather annoyed by the lack of comptence of some PHP coders who
manage their
19 matches
Mail list logo
