You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Robert Zeigler <ro...@scazdl.org> on 2010/04/08 22:20:38 UTC
Next 5.1 release?
What's the status on the next 5.1 release? I've been out of the loop
for the last six months; I know I contributed the assetpathdispatcher
stuff, which most people seemed to agree with (in terms of the idea),
until it was actually in, and then there was a huge amount of
pushback. I'm amenable to pulling out the AssetProtectionDispatcher
and putting in a "proper" fix (ie something directly in
AssetDispatcher), but was this issue already resolved?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by Christian Riedel <cr...@googlemail.com>.
Now that 5.2.4 is almost final, don't forget about the bugfix release for 5.1! :-) Too many apps out there don't implement the workaround for the asset problem...
Am 20.04.2010 um 14:44 schrieb Sebastian Hennebrueder:
> I don't believe that there is something like well known configuration files or most likely public viewable images. We cannot know all existing nor upcoming libraries and configuration files. For images the same is true. May be the images are top secret and only delivered to logged in users. You can never know.
>
> As a consequence, by default nothing should be public. It is just a security best practise: Protect by default
>
> We should only mark things that should be public or alternatively follow the JSF 2 approach to put resources into a dedicated folder. In JSF 2 this is WEB-INF/resources/
> the latter would allow a simple approach to language specific JavaScript and CSS as well.
>
> Yes, I know that it will break backward compatibility.
>
> Best Regards
>
> Sebastian Hennebrueder
>
> Am 09.04.10 08:26, schrieb Alex Kotchnev:
>> I actually liked how the AssetDispatcher stuff worked - secured by default
>> and only allowing the stuff that was explicitly makred as public on the
>> classpath (e.g. css, images, etc). It seems to me that the default-open is a
>> slippery slope from a security standpoint : today I might forget that I
>> added some config file w/ a weird extension and tomorrow when I deploy, my
>> configuration would be widely readable by the world. Not cool.
>>
>> I liked the idea that was discussed previously, where if possible anything
>> marked as an Asset would be available, everything else wouldn't; however, it
>> seemed like there was no good technical solution for that.
>>
>> Regards,
>>
>> Alex K
>>
>> On Fri, Apr 9, 2010 at 2:15 AM, Joachim Van der Auwera<jo...@progs.be>wrote:
>>
>>> Just protecting all files in the classpath may be a bit too strict. Why not
>>> allow all graphics types (png/gif/jpeg) from everywhere? This makes the
>>> integration of component libraries easier.
>>> For example for using chenillekit in 5.2 you need to contribute a
>>> RegexAuthorizer to see the images referred from the css files.
>>>
>>> Kind regards,
>>> Joachim
>>>
>>>
>>> Thiago H. de Paula Figueiredo wrote:
>>>
>>>> On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship<hl...@gmail.com>
>>>> wrote:
>>>>
>>>> What should be available by default? My opinion, anything in the context,
>>>>>> except WEB-INF.
>>>>>> What should not be available by default? My opinion, anything in the
>>>>>> classpath.
>>>>>>
>>>>>
>>>>> And that's where I disagree; maybe any non .class file outside of a
>>>>> controlled package should be protected? If we remove the malicious
>>>>> user's ability to "hunt' for files and protect the ones that may be
>>>>> important (.class, etc.) then we're good.
>>>>>
>>>>
>>>> Configuration files are very sensitive and are usually located in the
>>>> classpath in known places. I would consider most files in the classpath as
>>>> something that aren't meant to be publicly accessible unless explicitly
>>>> allowed.
>>>>
>>>>
>>>
>>> --
>>> Joachim Van der Auwera
>>> PROGS bvba, progs.be
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>
>
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
> -----
> Software Developer and Trainer for Hibernate / Java Persistence
> http://www.laliluna.de
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
I don't believe that there is something like well known configuration
files or most likely public viewable images. We cannot know all existing
nor upcoming libraries and configuration files. For images the same is
true. May be the images are top secret and only delivered to logged in
users. You can never know.
As a consequence, by default nothing should be public. It is just a
security best practise: Protect by default
We should only mark things that should be public or alternatively follow
the JSF 2 approach to put resources into a dedicated folder. In JSF 2
this is WEB-INF/resources/
the latter would allow a simple approach to language specific JavaScript
and CSS as well.
Yes, I know that it will break backward compatibility.
Best Regards
Sebastian Hennebrueder
Am 09.04.10 08:26, schrieb Alex Kotchnev:
> I actually liked how the AssetDispatcher stuff worked - secured by default
> and only allowing the stuff that was explicitly makred as public on the
> classpath (e.g. css, images, etc). It seems to me that the default-open is a
> slippery slope from a security standpoint : today I might forget that I
> added some config file w/ a weird extension and tomorrow when I deploy, my
> configuration would be widely readable by the world. Not cool.
>
> I liked the idea that was discussed previously, where if possible anything
> marked as an Asset would be available, everything else wouldn't; however, it
> seemed like there was no good technical solution for that.
>
> Regards,
>
> Alex K
>
> On Fri, Apr 9, 2010 at 2:15 AM, Joachim Van der Auwera<jo...@progs.be>wrote:
>
>> Just protecting all files in the classpath may be a bit too strict. Why not
>> allow all graphics types (png/gif/jpeg) from everywhere? This makes the
>> integration of component libraries easier.
>> For example for using chenillekit in 5.2 you need to contribute a
>> RegexAuthorizer to see the images referred from the css files.
>>
>> Kind regards,
>> Joachim
>>
>>
>> Thiago H. de Paula Figueiredo wrote:
>>
>>> On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship<hl...@gmail.com>
>>> wrote:
>>>
>>> What should be available by default? My opinion, anything in the context,
>>>>> except WEB-INF.
>>>>> What should not be available by default? My opinion, anything in the
>>>>> classpath.
>>>>>
>>>>
>>>> And that's where I disagree; maybe any non .class file outside of a
>>>> controlled package should be protected? If we remove the malicious
>>>> user's ability to "hunt' for files and protect the ones that may be
>>>> important (.class, etc.) then we're good.
>>>>
>>>
>>> Configuration files are very sensitive and are usually located in the
>>> classpath in known places. I would consider most files in the classpath as
>>> something that aren't meant to be publicly accessible unless explicitly
>>> allowed.
>>>
>>>
>>
>> --
>> Joachim Van der Auwera
>> PROGS bvba, progs.be
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by Alex Kotchnev <ak...@gmail.com>.
I actually liked how the AssetDispatcher stuff worked - secured by default
and only allowing the stuff that was explicitly makred as public on the
classpath (e.g. css, images, etc). It seems to me that the default-open is a
slippery slope from a security standpoint : today I might forget that I
added some config file w/ a weird extension and tomorrow when I deploy, my
configuration would be widely readable by the world. Not cool.
I liked the idea that was discussed previously, where if possible anything
marked as an Asset would be available, everything else wouldn't; however, it
seemed like there was no good technical solution for that.
Regards,
Alex K
On Fri, Apr 9, 2010 at 2:15 AM, Joachim Van der Auwera <jo...@progs.be>wrote:
> Just protecting all files in the classpath may be a bit too strict. Why not
> allow all graphics types (png/gif/jpeg) from everywhere? This makes the
> integration of component libraries easier.
> For example for using chenillekit in 5.2 you need to contribute a
> RegexAuthorizer to see the images referred from the css files.
>
> Kind regards,
> Joachim
>
>
> Thiago H. de Paula Figueiredo wrote:
>
>> On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship <hl...@gmail.com>
>> wrote:
>>
>> What should be available by default? My opinion, anything in the context,
>>>> except WEB-INF.
>>>> What should not be available by default? My opinion, anything in the
>>>> classpath.
>>>>
>>>
>>> And that's where I disagree; maybe any non .class file outside of a
>>> controlled package should be protected? If we remove the malicious
>>> user's ability to "hunt' for files and protect the ones that may be
>>> important (.class, etc.) then we're good.
>>>
>>
>> Configuration files are very sensitive and are usually located in the
>> classpath in known places. I would consider most files in the classpath as
>> something that aren't meant to be publicly accessible unless explicitly
>> allowed.
>>
>>
>
> --
> Joachim Van der Auwera
> PROGS bvba, progs.be
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Next 5.1 release?
Posted by Joachim Van der Auwera <jo...@progs.be>.
Just protecting all files in the classpath may be a bit too strict. Why
not allow all graphics types (png/gif/jpeg) from everywhere? This makes
the integration of component libraries easier.
For example for using chenillekit in 5.2 you need to contribute a
RegexAuthorizer to see the images referred from the css files.
Kind regards,
Joachim
Thiago H. de Paula Figueiredo wrote:
> On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship
> <hl...@gmail.com> wrote:
>
>>> What should be available by default? My opinion, anything in the
>>> context,
>>> except WEB-INF.
>>> What should not be available by default? My opinion, anything in the
>>> classpath.
>>
>> And that's where I disagree; maybe any non .class file outside of a
>> controlled package should be protected? If we remove the malicious
>> user's ability to "hunt' for files and protect the ones that may be
>> important (.class, etc.) then we're good.
>
> Configuration files are very sensitive and are usually located in the
> classpath in known places. I would consider most files in the
> classpath as something that aren't meant to be publicly accessible
> unless explicitly allowed.
>
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 08 Apr 2010 22:13:32 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
>> What should be available by default? My opinion, anything in the
>> context,
>> except WEB-INF.
>> What should not be available by default? My opinion, anything in the
>> classpath.
>
> And that's where I disagree; maybe any non .class file outside of a
> controlled package should be protected? If we remove the malicious
> user's ability to "hunt' for files and protect the ones that may be
> important (.class, etc.) then we're good.
Configuration files are very sensitive and are usually located in the
classpath in known places. I would consider most files in the classpath as
something that aren't meant to be publicly accessible unless explicitly
allowed.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 08 Apr 2010 22:15:43 -0300, Christian Edward Gruber
<ch...@gmail.com> wrote:
> On Apr 8, 2010, at 9:13 PM, Howard Lewis Ship wrote:
>
>> And that's where I disagree; maybe any non .class file outside of a
>> controlled package should be protected? If we remove the malicious
>> user's ability to "hunt' for files and protect the ones that may be
>> important (.class, etc.) then we're good.
>
> That seems a good balance.
Oops, just now I understood what Howard meant (facepalm) and I agree with
him. We just have to be careful about what should be protected, of course.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by Christian Edward Gruber <ch...@gmail.com>.
On Apr 8, 2010, at 9:13 PM, Howard Lewis Ship wrote:
> And that's where I disagree; maybe any non .class file outside of a
> controlled package should be protected? If we remove the malicious
> user's ability to "hunt' for files and protect the ones that may be
> important (.class, etc.) then we're good.
That seems a good balance.
Christian.
Re: Next 5.1 release?
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Thu, Apr 8, 2010 at 5:11 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Thu, 08 Apr 2010 19:54:03 -0300, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
>> In terms of a solution: simpler API, assume that most resources are
>> available unless explicitly told not to (i.e., .class and hibernate
>> properties files, etc.).
>
> What should be available by default? My opinion, anything in the context,
> except WEB-INF.
> What should not be available by default? My opinion, anything in the
> classpath.
And that's where I disagree; maybe any non .class file outside of a
controlled package should be protected? If we remove the malicious
user's ability to "hunt' for files and protect the ones that may be
important (.class, etc.) then we're good.
>
> Anyway, I think we shouldn't prevent users to define the availability of not
> of a given URL/resource/whatever. There will always be scenarios where some
> files of a type or location should be available or other not. That's why I
> like the asset protection filter configured as a pipeline, each part of it
> receiving an URL (better yet, a Request instance) to analyze.
>
>> Key things: some kind of check to prevent directory listings,
>
> I think directory listings of virtual and classpath assets should be denied,
> but listings of context folders should be configurable (denied os default).
>
>> and
>> properly enforce the extra MD5 checksum for protected resources
>> (.class file, etc.).
>
> +1
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, software architect and developer, Ars Machina Tecnologia da
> Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 08 Apr 2010 19:54:03 -0300, Howard Lewis Ship <hl...@gmail.com>
wrote:
> In terms of a solution: simpler API, assume that most resources are
> available unless explicitly told not to (i.e., .class and hibernate
> properties files, etc.).
What should be available by default? My opinion, anything in the context,
except WEB-INF.
What should not be available by default? My opinion, anything in the
classpath.
Anyway, I think we shouldn't prevent users to define the availability of
not of a given URL/resource/whatever. There will always be scenarios where
some files of a type or location should be available or other not. That's
why I like the asset protection filter configured as a pipeline, each part
of it receiving an URL (better yet, a Request instance) to analyze.
> Key things: some kind of check to prevent directory listings,
I think directory listings of virtual and classpath assets should be
denied, but listings of context folders should be configurable (denied os
default).
> and
> properly enforce the extra MD5 checksum for protected resources
> (.class file, etc.).
+1
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Next 5.1 release?
Posted by Howard Lewis Ship <hl...@gmail.com>.
I keep trying to find the time to come up with a simple, unified
approach to assets, library mappings, and asset protection. Maybe on
my flight out to London :-)
In terms of a solution: simpler API, assume that most resources are
available unless explicitly told not to (i.e., .class and hibernate
properties files, etc.).
Key things: some kind of check to prevent directory listings, and
properly enforce the extra MD5 checksum for protected resources
(.class file, etc.).
On Thu, Apr 8, 2010 at 1:20 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> What's the status on the next 5.1 release? I've been out of the loop for the
> last six months; I know I contributed the assetpathdispatcher stuff, which
> most people seemed to agree with (in terms of the idea), until it was
> actually in, and then there was a huge amount of pushback. I'm amenable to
> pulling out the AssetProtectionDispatcher and putting in a "proper" fix (ie
> something directly in AssetDispatcher), but was this issue already resolved?
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org