[jira] [Commented] (VELTOOLS-170) Upgrade beanutils to 1.9.3 & supress access to class and Class
[
https://issues.apache.org/jira/browse/VELTOOLS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651164#comment-16651164
]
varsha j commented on VELTOOLS-170:
---
can anyone please tell me how we need to implement custom servlet filter to fix
cve-2014-0114?
> Upgrade beanutils to 1.9.3 & supress access to class and Class
> --
>
> Key: VELTOOLS-170
> URL: https://issues.apache.org/jira/browse/VELTOOLS-170
> Project: Velocity Tools
> Issue Type: Bug
> Components: Build
>Affects Versions: 2.0
>Reporter: Mark Symons
>Assignee: Claude Brisson
>Priority: Critical
> Fix For: 3.0
>
>
> Update dependency on commons-beanutils:commons-beanutils to v1.9.2 and
> mitigate CVE-2014-0114. See BEANUTILS-463 for fix info.
> Velocity Tools v2.0 currently uses bean-utils v1.7.0
> Whilst the CVE text references beanutils v1.8.0, Black Duck Hub threat
> analysis have updated affected versions to include 1.7.0.
> {quote}
> Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar
> in Apache Struts 1.x through 1.3.10 and in other products requiring
> commons-beanutils through 1.9.2, does not suppress the class property, which
> allows remote attackers to "manipulate" the ClassLoader and execute arbitrary
> code via the class parameter, as demonstrated by the passing of this
> parameter to the getClass method of the ActionForm object in Struts 1.
> {quote}
> h5.CVSS Version 2 Metrics:
> Access Vector: Network exploitable
> Access Complexity: Low
> Authentication: Not required to exploit
> Impact Type:
> * Allows unauthorized disclosure of information
> * Allows unauthorized modification
> * Allows disruption of service
> h3.Edit: 28th November 2016
> Sonatype Nexus IQ identifies beanutils as a threat as of v1.24 (late November
> 2016). From the vulnerability information provided (and highlighting in red
> the bit that applies to Velocity Tools):
> {quote}
> h4.Explanation
> Apache Commons BeanUtils is vulnerable to ClassLoader manipulation which can
> lead to Remote Code Execution (RCE). Access to the {{class}} and {{Class}}
> properties is not suppressed, exposing them by default. An attacker can
> construct malicious input using the {{class property}} in order to manipulate
> the {{ClassLoader}} potentially leading to arbitrary code execution.
> h4.Detection
> {color:red}If you are the calling application, you are vulnerable by running
> this component without filtering the property names {{class}} and
> {{Class}}{color}. If this is a transitive dependency, you will want to
> contact the parent project to ensure they have added a mitigating control.
> Note: If you are using the built-in implementation of
> {{SuppressPropertiesBeanIntrospector}} added in version 1.9.2 of
> {{commons-beanutils}} as your mitigation you are still vulnerable. Although
> the built-in implementation specifically suppresses the {{class}} properly,
> it does not also suppress {{Class}}.
> h4.Recommendation
> Although commons-beanutils offers a built-in implementation of
> SuppressPropertiesBeanIntrospector in version 1.9.2 that specifically
> suppresses the “class” properly, it does not also suppress “Class”. Due to
> this insufficient fix which is also not enabled by default, we recommend
> implementing your own custom mitigating control such as the one found here -
> https://community.hpe.com/t5/Security-Research/Protect-your-Struts1-applications/ba-p/6463188#.VCUfrhYvBaV.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650602#comment-16650602 ] Thomas Mortagne commented on VELOCITY-542: -- OK thanks [~claude] ! > minus sign in #set requires spaces to surround it > - > > Key: VELOCITY-542 > URL: https://issues.apache.org/jira/browse/VELOCITY-542 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Will Glass-Husain >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.1 > > > The following example: > #set($thisCampNumber = 10) > #set($nextCampNumber = $thisCampNumber+1) > #set($previousCampNumber = $thisCampNumber-1) > #set($previousCampNumberB = $thisCampNumber - 1) > 1: $thisCampNumber > 2: $nextCampNumber > 3: $previousCampNumber > 4: $previousCampNumberB > produces this result > 1: 10 > 2: 11 > 3: $previousCampNumber > 4: 9 > Note that using a minus sign in a #set statement does not work if there are > no spaces around it. (however, the same is not true for +). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-542) minus sign in #set requires spaces to surround it
[ https://issues.apache.org/jira/browse/VELOCITY-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650467#comment-16650467 ] Claude Brisson commented on VELOCITY-542: - FYI, the behavior with null macro arguments is now configurable via the velocimacro.preserve.arguments.literals configuration value, see [VELOCITY-904|https://issues.apache.org/jira/browse/VELOCITY-904]. > minus sign in #set requires spaces to surround it > - > > Key: VELOCITY-542 > URL: https://issues.apache.org/jira/browse/VELOCITY-542 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 >Reporter: Will Glass-Husain >Assignee: Claude Brisson >Priority: Minor > Fix For: 2.1 > > > The following example: > #set($thisCampNumber = 10) > #set($nextCampNumber = $thisCampNumber+1) > #set($previousCampNumber = $thisCampNumber-1) > #set($previousCampNumberB = $thisCampNumber - 1) > 1: $thisCampNumber > 2: $nextCampNumber > 3: $previousCampNumber > 4: $previousCampNumberB > produces this result > 1: 10 > 2: 11 > 3: $previousCampNumber > 4: 9 > Note that using a minus sign in a #set statement does not work if there are > no spaces around it. (however, the same is not true for +). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson resolved VELOCITY-904.
-
Resolution: Done
Fix Version/s: 2.1
Done in commit 1843909.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.1
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Created] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
Claude Brisson created VELOCITY-904:
---
Summary: Add a flag for better backward compatibility with null
macro arguments
Key: VELOCITY-904
URL: https://issues.apache.org/jira/browse/VELOCITY-904
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 2.0
Reporter: Claude Brisson
Assignee: Claude Brisson
See [this
comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
:
{code}
#macro(testmacro $parameter)
$parameter
#end
#testmacro($return)
{code}
bq. which used to print "$return" (when $return is null or undefined) and we
now get "$parameter".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650084#comment-16650084
]
Thomas Mortagne edited comment on VELOCITY-892 at 10/15/18 11:16 AM:
-
I'm not really talking about having two methods in the same class but simply
having methods taking something else than List or List as parameter.
Imagine the following use case:
{code}
public void foo(List parameter)
{
for (Integer value : parameter) {
// do stuff with the integer
}
}
{code}
{code}
$obj.foo("1, 2, 3, 4, 5")
{code}
It's impossible for the converter to know it should convert each element of the
list to Integer so at best you will write a converter which produce a
List and the method will crash with a ClassCastException.
was (Author: tmortagne):
I'm not really talking about having two methods in the same class but simply
having methods taking something else than List or List as parameter.
Imagine the following use case:
{quote}
public void foo(List parameter)
{
for (Integer value : parameter) {
// do stuff with the integer
}
}
{quote}
{quote}
$obj.foo("1, 2, 3, 4, 5")
{quote}
It's impossible for the converter to know it should convert each element of the
list to Integer so at best you will write a converter which produce a
List and the method will crash with a ClassCastException.
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650084#comment-16650084
]
Thomas Mortagne commented on VELOCITY-892:
--
I'm not really talking about having two methods in the same class but simply
having methods taking something else than List or List as parameter.
Imagine the following use case:
{quote}
public void foo(List parameter)
{
for (Integer value : parameter) {
// do stuff with the integer
}
}
{quote}
{quote}
$obj.foo("1, 2, 3, 4, 5")
{quote}
It's impossible for the converter to know it should convert each element of the
list to Integer so at best you will write a converter which produce a
List and the method will crash with a ClassCastException.
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-892) Method arguments conversions should be based on Type instead of Class
[
https://issues.apache.org/jira/browse/VELOCITY-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16650046#comment-16650046
]
Claude Brisson commented on VELOCITY-892:
-
{quote}for example if the parameter type is List it won't do the same
thing than if the type is List
{quote}
Since it's invalid in Java to have two methods with the same name and same
argument type *after* type erasure, this use case doesn't stand, does it? Or
can you be more explicit?
And if you have other typical use cases in mind where Velocity doesn't have the
proper behavior, can you share them?
> Method arguments conversions should be based on Type instead of Class
> -
>
> Key: VELOCITY-892
> URL: https://issues.apache.org/jira/browse/VELOCITY-892
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Thomas Mortagne
>Priority: Major
> Fix For: 2.0
>
>
> I was happy to see that method arguments conversion has been added to 2.0 so
> that I can remove the uberspector we have on XWiki side but unfortunately
> ConversionHandler is limited to classes which is way too restrictive for us
> (for example if the parameter type is List it won't do the same thing
> than if the type is List).
> Our uberspector can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java
> to see what we do exactly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-876) Support a Configurable EL within ${{...}} also $!{{...}} tags
[
https://issues.apache.org/jira/browse/VELOCITY-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649969#comment-16649969
]
Claude Brisson commented on VELOCITY-876:
-
I took a closer look at JEXP. And I'm having some doubts about the pertinence
of the feature.
Templating is not scripting and do not pursue the same goals. The spirit of
templating is to separate business logic from presentation, by providing a
simple language for the view layer. Scripting languages like JEXP are firstly
meant to provide an accessible and convenient way to model business logic.
Allowing ${\{ }} and #if( ${\{ }} ) inside Velocity templates doesn't seem to
be very orthodox from that perspective.
To my mind, the most natural link between JEXP and Velocity would be the other
way around: to let JEXP users merge Velocity templates (and that doesn't look
so hard). I even wonder why JEXP did provide its own string interpolation
mechanism instead of relying on Velocity, by the way.
> Support a Configurable EL within ${{...}} also $!{{...}} tags
> -
>
> Key: VELOCITY-876
> URL: https://issues.apache.org/jira/browse/VELOCITY-876
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.7
>Reporter: Terefang Verigorn
>Priority: Minor
> Fix For: 2.1.x
>
>
> Since Velocity2 is a Major version, why not start to support some new
> features?
> As of Velocity 1.x you can use ${ name } to refer to object "name" in the
> context, or use $!{ name } if you want "" for null values.
> How about using ${{ el-expression }} to evaluate and output the given
> "el-expression" in a configured el-engine with the current velocity context,
> same should hold for $!{{ el-expression }}.
> Some possible engines would be :
> commons-el, commons-jexl, ognl, mvel
> if using el/jexl ${{ name }} would be mostly the same as ${ name }.
> usage cases:
> the simple ${{ ... }} would allow more complicated expressions than present
> in the plain engine, especially if we look at the jexl2/3 features
> #if( ${{ ... }} ) -- would improve the boolean issue because the el could be
> used to wrap in "a?x:y"
> architecture:
> thru api abstraction, almost any el could be plugged in ( even groovy.eval or
> jsr223 )
> core engine could ship with the api and el or jexl as the reference impl,
> other bindings would be optional jars with thier own deps.
> brain storming:
> how about supporting non-outputting el/jsr223 between #{{ ... #}} tags, like:
> --
> #{{ /* jexl code */
> var = [ 1,2,3,4,5,6,7 ];
> #}}
> #foreach( $n in $var )
> $n
> #end
> --
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-850) modificationCheckInterval defaults to zero
[ https://issues.apache.org/jira/browse/VELOCITY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-850. - Resolution: Fixed Assignee: Claude Brisson Fix Version/s: 2.1 Fixed by commit 1843883: - Velocity now supports non-string values in the initial Properties - even if it is strongly discouraged to put something else than strings in Properties, if the calling code did so, better support it than fail on an NPE - the internal ExpProperties object (cloned from ExtendedProperties) now tries to do a better job at converting numbers > modificationCheckInterval defaults to zero > -- > > Key: VELOCITY-850 > URL: https://issues.apache.org/jira/browse/VELOCITY-850 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.7 > Environment: all >Reporter: Beat Durrer >Assignee: Claude Brisson >Priority: Minor > Labels: documentation, easyfix > Fix For: 2.1 > > > The base class ResourceLoader handles the loading of the > modificationCheckInterval property. However, if the property is not present, > or not of the correct type (long), it changes the default to zero. > This issue is amplified by the fact, that > ExtendedProperties#getLong(name,default) does not cast Integers to Long (But > it accepts a String property). > The type requirements should either be documented or the code should be > improved to support casts from Integer to Long. Neglecting this actually > disables cache refreshing and is hard to find for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-229) Velocity templates should be able to specify their own encoding
[ https://issues.apache.org/jira/browse/VELOCITY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649847#comment-16649847 ] Michael Osipov commented on VELOCITY-229: - Fully agree with Claude, we shouldn't fiddle with a pushback reader like XML adding unnecessary complexity. > Velocity templates should be able to specify their own encoding > --- > > Key: VELOCITY-229 > URL: https://issues.apache.org/jira/browse/VELOCITY-229 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.5 > Environment: Operating System: All > Platform: All >Reporter: Charles Morehead >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--Template.diff, > ASF.LICENSE.NOT.GRANTED--encoding-support.jar > > > Velocity templates should be able to specify their own encoding without > requiring external knowledge of the encoding before parsing (as least > for all ASCII-compatible encodings). Many other scripting/templating > systems (like JSP and python, for example) provide such a mechanism, > and find it helpful to users when creating multi-language (and encoding) > sites. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Resolved] (VELOCITY-229) Velocity templates should be able to specify their own encoding
[ https://issues.apache.org/jira/browse/VELOCITY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson resolved VELOCITY-229. - Resolution: Won't Do Ten years old, and still no CLA... Plus, not sure we want this in. > Velocity templates should be able to specify their own encoding > --- > > Key: VELOCITY-229 > URL: https://issues.apache.org/jira/browse/VELOCITY-229 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.5 > Environment: Operating System: All > Platform: All >Reporter: Charles Morehead >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--Template.diff, > ASF.LICENSE.NOT.GRANTED--encoding-support.jar > > > Velocity templates should be able to specify their own encoding without > requiring external knowledge of the encoding before parsing (as least > for all ASCII-compatible encodings). Many other scripting/templating > systems (like JSP and python, for example) provide such a mechanism, > and find it helpful to users when creating multi-language (and encoding) > sites. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Closed] (VELOCITY-229) Velocity templates should be able to specify their own encoding
[ https://issues.apache.org/jira/browse/VELOCITY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Brisson closed VELOCITY-229. --- > Velocity templates should be able to specify their own encoding > --- > > Key: VELOCITY-229 > URL: https://issues.apache.org/jira/browse/VELOCITY-229 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.5 > Environment: Operating System: All > Platform: All >Reporter: Charles Morehead >Priority: Minor > Attachments: ASF.LICENSE.NOT.GRANTED--Template.diff, > ASF.LICENSE.NOT.GRANTED--encoding-support.jar > > > Velocity templates should be able to specify their own encoding without > requiring external knowledge of the encoding before parsing (as least > for all ASCII-compatible encodings). Many other scripting/templating > systems (like JSP and python, for example) provide such a mechanism, > and find it helpful to users when creating multi-language (and encoding) > sites. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
