On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>
> Am 13.08.2013 00:51, schrieb coderaptor:
>> On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>>>> ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks otherwise should fly in an aircraft running
>>>> his own designed software. Knowledgeable Admins are not an alternative to secure defaults, rather I'd prefer both.
>>>
>>> *define what is secure* and make sure you define it by context
>>>
>>> unlink('file_my_script_wrote'); is fine
>>> unlink($_GET['what_ever_input']): is a security hole
>>>
>>> so do we now disable unlink();
>>
>> Why not?
>
> because it is plain stupid
You think so. Not everyone shares your opinion.
> you even statet that you did not realize that others are talking
> about PHP and you not knew the context of 'disable_functions'
> and so stop trying to be a smartass in topics you are clueless
Please no personal insults.
>>> hey in this case you need also to disable fopen(), file_put_contents()
>>> and whatever function can open and overwrite a file - now you could
>>> come and argue "but the permissions should not allow" - well, your
>>> config should also not allow any random script to create symlinks
>>>
>>> on a internal application which is not accesable from the web
>>> symlink() is harmless and may be used for good reasons
>>>
>>> so you should realize that security is not black and white
>>
>> Go ahead and disable all 1330 functions if the need be, and let the
>> Administrator figure out which ones he should carefully enable
>
> please stop making yourself *that* laughable
I don't care.
>>> if you nned 100% secure defaults do not allow CGI and script interpreters
>>> and go back to static sites because you have to realize that *any*
>>> scripting lanuguage is a security risk per definition - period
>>
>> Just for the sake of argument? Which sane framework provides 1330
>> functions? Security is surely not black and white, but this argument
>> should not justify poor design choices. Anyways, no matter what one
>> does, using a framework with 1330 functions is poor security decision
>
> please be quite and come back after you understood the difference
> between a programming language and a framework
>
> hint:
>
> * PHP: programming language
> * Ruby: programming language
>
> * Zend Framework, Symfony: Framework
> * Ruboy On Rails: Framework
>
Does it matter if I call at a framework, programming language, or
dancing donkey? It doesn't change the reality.
Just because you have an opinion does not make it more right than
others. PHP sucks with 1300 functions (what programming language
requires 1300 functions? The one that is designed poorly), that's a
fact. And you aren't helping it suck less. I may be clueless about how
the apache + php glue and php work, but I am now very sure that I
won't use PHP. And will probably stick with my OpenBSD implementation
of chrooted apache - apache is fit to be in a jail.
I rest my case.
-coderaptor
