Am 05.09.13 21:22, schrieb Lukasz Lenart:
> 2013/9/5 Christian Grobmeier <grobme...@gmail.com>:
>> Am 05.09.13 20:43, schrieb Lukasz Lenart:
>>> Guys,
>>>
>>> are you serious? are you blaming OGNL? the hammer? 100% of
>>> vulnerability related to OGNL was our - developers - fault. We did use
>>> (and still do) the hammer in inappropriate way. Changing hammer is not
>>> the solution!
>> The hammer is stuck at Apache Commons. Nobody of us Struts devs has
>> managed to make a release of it.
>> Honestely OGNL codebase is a mess and we are short on man power.
> Maybe a mess but anyway OGNL is very powerful - there was not enough
> rumour but I think with S3 ahead is the way to go. I think what's left
> to do is review all the TODOs and logging layer. TODOs are already on
> my list.
We may discuss this on the commons-dev list in depth. I already wrote 3
messages on ognl last week.
>
>> Maybe we use it wrong. Then please lets fix it. Still the problem
>> remains that we are using something which we don't control. It is also
>> unlikely that we fix it in Commons-land the next time.
> Nah... I have another pull-request to the old OGNL which was already
> solved in the Commons-OGNL - it just shows that the OGNL code base is
> very mature and ready to be released.
For me it doesn't say anything. I mean, yeah, we ahve made some
progress. But hey, we haven't ever made a release and its not 2 yrs or so.
Anyway i am willing to help with the OGNL release. But I can't do it
alone, because there are a few parts of OGNL i do not understand well.
If you have some time, we can team up.
My main concern: if we don't make a first release, it's getting more
unlikely and unlikely. We need to step ahead now or we have a
not-maintained component in code.
>> To stick with your nice analogy - do we really need to solve a problems
>> which requires a hammer? Or is something smaller efficient in the same
>> way and maybe safer by default?
> Maybe not, I don't know. But changing know hammer to unknown hammer
> isn't the way to go - as for me :-)
There is some truth in these wise words!
:-)
>
>>> Things related to ${} or %{} should be clarified - %{} is called an
>>> alternative syntax in the source ;-) It should be removed and we
>>> should stick just to ${} - maybe it can be useful in XMLs as far I
>>> know '$' isn't an allowed value - maybe something else can be used.
>> This would fix one problem of many. But the more serious question is:
>> how can we make Struts more secure? If we use it wrong, then lets try to
>> make it good. I will interview Rene on the security manager option which
>> was mentioned earlier in this thread.
> How? Use the Java SecurityManager :-) Really, that was the answer of
> one of the Tomcat's creator. If you want a fully secure Java based
> application stick with what Java provides - don't invent the wheel!
Yes, I meant the SecurityManager. Discussing with him on weekend, I
understood
the SecurityManager is a difficult beast. Also I understand better how
deeply tied OGNL is with Struts - not only from frontend perspective.
Not sure if we have the man power if we would move away from OGNL. Also
the question remains, if we can improve things with another expression
framework.
We should separate the frontend discussion from the "general OGNL"
discussion i think. For the frontend we can recommend easily something
else than OGNL - tis a documentation topic.
>From a security standpoint we may have the man power to improve things.
For example, if we manage to "disable static method" calls from OGNL we
would have a win already. If we manage to restrict the path of OGNL we
might have another win.
Cheers!
PS: I used the "hammer" analogy at the strutsathon presentations, i
really like it very much ;-)
>
> Kind regards
> Ł
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
