Nabble - Velocity - Dev

[GUMP@vmgump]: Project velocity-texen-test (in module velocity-texen) failed

2008-07-04T03:47:26Z

To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@....

Project velocity-texen-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 25 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- velocity-texen-test : Texen is a general purpose text generating utility based on ...

Full details are available at:
http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
-INFO- Failed with reason build failed

The following work was performed:
http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/gump_work/build_velocity-texen_velocity-texen-test.html
Work Name: build_velocity-texen_velocity-texen-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Ddeprecation=false -Dversion=04072008 -Dskip.jar.loading=true test
[Working Directory: /srv/gump/public/workspace/velocity-texen/build]
CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/velocity-texen/bin/test-classes:/srv/gump/public/workspace/velocity-texen/bin/test:/srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath.jar:/srv/gump/public/workspace/velocity-texen/bin/texen-04072008.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-04072008.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lan
g-04072008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-04072008.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/packages/werken-xpath/werken-xpath-0.9.4.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-04072008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-04072008.jar:/srv/gump/public/workspace/velocity-anakia/bin/anakia-04072008.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar
---------------------------------------------

test-jar:
[mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test
[jar] Building jar: /srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath.jar

test:
[mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test-reports
[junit] Running org.apache.texen.ExtendedTexenTestCase
[junit] Template results directory does not exist
[junit] Created template results directory
[junit] Generating to file bin/test/texen-generator/report
[junit] Comparing result file 'bin/test/texen-generator/TurbineWeather.java' with compare file 'test/texen/compare/TurbineWeather.java'
[junit] Comparing result file 'bin/test/texen-generator/TurbineWeatherService.java' with compare file 'test/texen/compare/TurbineWeatherService.java'
[junit] Comparing result file 'bin/test/texen-generator/WeatherService.java' with compare file 'test/texen/compare/WeatherService.java'
[junit] Comparing result file 'bin/test/texen-generator/book.txt' with compare file 'test/texen/compare/book.txt'
[junit] Comparing result file 'bin/test/texen-generator/Text.txt' with compare file 'test/texen/compare/Text.txt'
[junit] Template results directory does not exist
[junit] Created template results directory
[junit] Using classpath
[junit] Generating to file bin/test/texen-generator-classpath/report
[junit] org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'Control.vm'
[junit] at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:452)
[junit] at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
[junit] at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1342)
[junit] at org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:419)
[junit] at org.apache.texen.Generator.getTemplate(Generator.java:321)
[junit] at org.apache.texen.Generator.parse(Generator.java:451)
[junit] at org.apache.texen.Texen.execute(Texen.java:342)
[junit] at org.apache.texen.ExtendedTexenTestCase.testExtendedTexenClasspath(ExtendedTexenTestCase.java:176)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:154)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:118)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
[junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768)
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.776 sec

BUILD FAILED
/srv/gump/public/workspace/velocity-texen/build/build.xml:520: Test org.apache.texen.ExtendedTexenTestCase failed

Total time: 4 seconds
---------------------------------------------

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/rss.xml
- Atom: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/atom.xml

============================== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 01010004072008, vmgump:vmgump-public:01010004072008
Gump E-mail Identifier (unique within run) #25.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[GUMP@vmgump]: Project velocity-engine-test (in module velocity-engine) failed

2008-07-04T03:18:37Z

To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@....

Project velocity-engine-test has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 25 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- velocity-engine-test : Velocity Templating engine

Full details are available at:
http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
-INFO- Failed with reason build failed

The following work was performed:
http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/gump_work/build_velocity-engine_velocity-engine-test.html
Work Name: build_velocity-engine_velocity-engine-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 49 secs
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Djar.oro.dir=/srv/gump/public/workspace/jakarta-oro -Ddeprecation=false -Djar.commons-collections.version=04072008 -Dskip.jar.loading=true -Djar.commons-lang.dir=/srv/gump/public/workspace/apache-commons/lang/dist -Dversion=04072008 -Djar.commons-collections.dir=/srv/gump/public/workspace/apache-commons/collections/build -Djar.commons-lang.version=04072008 -Djar.oro.name=jakarta-oro -Djar.oro.version=04072008 test
[Working Directory: /srv/gump/public/workspace/velocity-engine/build]
CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/velocity-engine/test:/srv/gump/public/workspace/velocity-engine/bin/test-classes:/srv/gump/public/workspace/velocity-engine/test/cpload/test1.jar:/srv/gump/public/workspace/velocity-engine/test/texen-classpath/test.jar:/srv/gump/public/workspace/velocity-engine/test/multiloader/test1.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-04072008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-04072008.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/s
rv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/avalon-logkit/avalon-logkit-2.1.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-04072008.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lang-04072008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-04072008.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-04072008.jar:/srv/gump/packages/werken-xpath/werken-xpath-0.9.4.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-04072008.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-04072008.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar:/srv/gump/public/workspace/hsqldb/lib/hsqldb.jar
---------------------------------------------
[junit] method = doException
[junit] throwable = java.lang.NullPointerException
[junit] exception = null
[junit] Caught MIE (good!) :
[junit] reference = woogie
[junit] method = getFoo
[junit] throwable = java.lang.Exception: Hello from getFoo()
[junit] exception = Hello from getFoo()
[junit] Caught MIE (good!) :
[junit] reference = woogie
[junit] method = getFoo
[junit] throwable = java.lang.Exception: Hello from getFoo()
[junit] exception = Hello from getFoo()
[junit] Caught MIE (good!) :
[junit] reference =
[junit] method = foo
[junit] throwable = java.lang.Exception: Hello from setFoo()
[junit] exception = Hello from setFoo()
[junit] Caught MIE (good!) :
[junit] reference = woogie
[junit] method = getFoo
[junit] throwable = java.lang.Exception: Hello from getFoo()
[junit] exception = Hello from getFoo()
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.559 sec
[junit] Running org.apache.velocity.test.MethodOverloadingTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.6 sec
[junit] Running org.apache.velocity.test.MiscTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.velocity.test.MultipleFileResourcePathTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.36 sec
[junit] Running org.apache.velocity.test.NumberMethodCallsTestCase
[junit] Testing: method calls with arguments as context objects
[junit] Testing: method calls with arguments as literals
[junit] Testing: method calls with arguments as calculated values
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.501 sec
[junit] Running org.apache.velocity.test.ParseExceptionTestCase
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.152 sec
[junit] Running org.apache.velocity.test.ParseWithMacroLibsTestCase
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.057 sec
[junit] Running org.apache.velocity.test.ParserTestCase
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.673 sec
[junit] Running org.apache.velocity.test.ResourceCachingTestCase
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.839 sec
[junit] Running org.apache.velocity.test.ResourceLoaderInstanceTestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.318 sec

BUILD FAILED
/srv/gump/public/workspace/velocity-engine/build/build.xml:974: Test org.apache.velocity.test.ResourceLoaderInstanceTestCase failed

Total time: 47 seconds
---------------------------------------------

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/rss.xml
- Atom: http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/atom.xml

============================== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 01010004072008, vmgump:vmgump-public:01010004072008
Gump E-mail Identifier (unique within run) #19.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [VOTE] Release VelocityTools 2.0-beta2

2008-07-03T18:13:50Z

i unilaterally declare the vote extended. no need to roll another
build just yet. i'll gladly await your votes/feedback. :)

On Thu, Jul 3, 2008 at 5:43 PM, Claude Brisson <claude@...> wrote:

> Looks like I missed it too... but I'll have plenty of time next week to
> check (and actually try!) the beta, should it be this vote (extended) or
> a new one.
>
>
> Claude
>
> Le jeudi 03 juillet 2008 à 17:34 -0700, Will Glass-Husain a écrit :
>> Looks like I missed the vote--sorry! I'm traveling for the holidays;
>> will look at this Saturday if the vote is still open.
>>
>> WILL
>>
>> On Mon, Jun 30, 2008 at 9:54 AM, Nathan Bubna <nbubna@...> wrote:
>> > There was no negative feedback on the test build (no feedback at all
>> > actually), so we're moving on to a vote...
>> >
>> > The test build is still available here:
>> > http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
>> >
>> > Improved documentation is online here:
>> > http://velocity.apache.org/tools/devel/
>> >
>> > Please vote regarding your support for releasing this test build as
>> > VelocityTools 2.0-beta2:
>> >
>> > [ ] +1 Let's do it
>> > [ ] +0 Have fun; i don't care.
>> > [ ] -0 Not sure about this, but i won't stop you.
>> > [ ] -1 No, because __________________
>> >
>> > The voting period is typically 72 hours, putting its close time as
>> > roughly 10am PST on Thursday, Jul 3rd. I'll try to push out the
>> > release that afternoon if all goes well.
>> >
>> > On Thu, Jun 26, 2008 at 8:36 PM, Nathan Bubna <nbubna@...> wrote:
>> >> ok folks, here's a build for 2-beta2.
>> >>
>> >> http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
>> >>
>> >> please kick the tires and report any nitpicks soon. assuming no one
>> >> sees any problems, i'll call for a release vote this weekend. with
>> >> luck, that vote will close early next week, and i can push this
>> >> release out.
>> >>
>> >> thanks,
>> >> nathan
>> >>
>> >> p.s. 2.0 final is getting so close. i can tell some of you are just
>> >> itching to write some docs or tests or even just give it a thorough
>> >> look-over and report your thoughts! ;)
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@...
>> > For additional commands, e-mail: dev-help@...
>> >
>> >
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [VOTE] Release VelocityTools 2.0-beta2

2008-07-03T17:43:58Z

Looks like I missed it too... but I'll have plenty of time next week to
check (and actually try!) the beta, should it be this vote (extended) or
a new one.

Claude

Le jeudi 03 juillet 2008 à 17:34 -0700, Will Glass-Husain a écrit :

> Looks like I missed the vote--sorry! I'm traveling for the holidays;
> will look at this Saturday if the vote is still open.
>
> WILL
>
> On Mon, Jun 30, 2008 at 9:54 AM, Nathan Bubna <nbubna@...> wrote:
> > There was no negative feedback on the test build (no feedback at all
> > actually), so we're moving on to a vote...
> >
> > The test build is still available here:
> > http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
> >
> > Improved documentation is online here:
> > http://velocity.apache.org/tools/devel/
> >
> > Please vote regarding your support for releasing this test build as
> > VelocityTools 2.0-beta2:
> >
> > [ ] +1 Let's do it
> > [ ] +0 Have fun; i don't care.
> > [ ] -0 Not sure about this, but i won't stop you.
> > [ ] -1 No, because __________________
> >
> > The voting period is typically 72 hours, putting its close time as
> > roughly 10am PST on Thursday, Jul 3rd. I'll try to push out the
> > release that afternoon if all goes well.
> >
> > On Thu, Jun 26, 2008 at 8:36 PM, Nathan Bubna <nbubna@...> wrote:
> >> ok folks, here's a build for 2-beta2.
> >>
> >> http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
> >>
> >> please kick the tires and report any nitpicks soon. assuming no one
> >> sees any problems, i'll call for a release vote this weekend. with
> >> luck, that vote will close early next week, and i can push this
> >> release out.
> >>
> >> thanks,
> >> nathan
> >>
> >> p.s. 2.0 final is getting so close. i can tell some of you are just
> >> itching to write some docs or tests or even just give it a thorough
> >> look-over and report your thoughts! ;)
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: [VOTE] Release VelocityTools 2.0-beta2

2008-07-03T17:34:16Z

Looks like I missed the vote--sorry! I'm traveling for the holidays;
will look at this Saturday if the vote is still open.

WILL

On Mon, Jun 30, 2008 at 9:54 AM, Nathan Bubna <nbubna@...> wrote:

> There was no negative feedback on the test build (no feedback at all
> actually), so we're moving on to a vote...
>
> The test build is still available here:
> http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
>
> Improved documentation is online here:
> http://velocity.apache.org/tools/devel/
>
> Please vote regarding your support for releasing this test build as
> VelocityTools 2.0-beta2:
>
> [ ] +1 Let's do it
> [ ] +0 Have fun; i don't care.
> [ ] -0 Not sure about this, but i won't stop you.
> [ ] -1 No, because __________________
>
> The voting period is typically 72 hours, putting its close time as
> roughly 10am PST on Thursday, Jul 3rd. I'll try to push out the
> release that afternoon if all goes well.
>
> On Thu, Jun 26, 2008 at 8:36 PM, Nathan Bubna <nbubna@...> wrote:
>> ok folks, here's a build for 2-beta2.
>>
>> http://people.apache.org/~nbubna/velocity/tools/2.0-beta2/
>>
>> please kick the tires and report any nitpicks soon. assuming no one
>> sees any problems, i'll call for a release vote this weekend. with
>> luck, that vote will close early next week, and i can push this
>> release out.
>>
>> thanks,
>> nathan
>>
>> p.s. 2.0 final is getting so close. i can tell some of you are just
>> itching to write some docs or tests or even just give it a thorough
>> look-over and report your thoughts! ;)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Forio Business Simulations

Will Glass-Husain
wglass@...
www.forio.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jira] Commented: (VELTOOLS-94) Document standard use cases with J2EE filters

2008-07-03T17:10:45Z

[ https://issues.apache.org/jira/browse/VELTOOLS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610383#action_12610383 ]

Nathan Bubna commented on VELTOOLS-94:
--------------------------------------

As of revision 673880, you can now tell ServletUtils to use a VelocityView subclass by adding an init-param with the key of

org.apache.velocity.tools.view.class

and a value of the subclass' canonical class name. This makes it much easier to override things in VelocityView that used to be in VelocityViewServlet.

> Document standard use cases with J2EE filters
> ---------------------------------------------
>
> Key: VELTOOLS-94
> URL: https://issues.apache.org/jira/browse/VELTOOLS-94
> Project: Velocity Tools
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 2.0
> Environment: all
> Reporter: Claude Brisson
> Priority: Minor
>
> (yet another docs reminder...)
> There are some use cases concerning J2EE filters that I'd like to address/document before releasing 2.0 final:
> 1. sharing the VelocityView with filters - made very easy in 2.x, using:
> view = (VelocityView)servletContext.getAttribute(VelocityView.class.getName())
> but the loat-a-startup flag must be set on the servlets for the view to be initialized at the time the filter is called.
> [BTW, the VelocityView(ServletContext) exists but is not yet fully coded - init is not yet called. We should either comment it for now or refactor VV.init/configure to work either with a ServletConfig or ServletContext. Personally I don't need it at all.]
> 2. having a filter add objects in the context: very easy, objects should be put in targeted scopes using request/session/application attributes.
> 3. having a filter add a tools property (that will be added to newly created request/session tools using bean setters or configure): I'm not really sure about this one. With the current codebase, it is necessary to subclass both the VV and the ToolboxFactory to circumvent protected accesses to be able to do sthing like this:
> VV.getToolboxFactory().putProperties(scope,props)
> I'd vote for having those two methods made public.
> [BTW, subclassing of the VV also requires for now the subclassing of the VVS... maybe ServletUtils.getVelocityView could check a configuration property like "velocity.tools.view.class=" containing the classname of the VelocityView subclass to be used]

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Velocity arg init issue

2008-07-03T13:22:04Z

Thanks, Serge. I'd pulled up the code and was really quite puzzled.
Sounds like kind of a neat approach you are taking.

WILL

On Thu, Jul 3, 2008 at 1:18 PM, Serge Knystautas <sknystautas@...> wrote:

> Wow, figured this one out. :( I doubt anyone else will hit this, but
> wanted to post it so nobody else wastes their time on this.
>
> The issue is that when the Macro directive initializes itself, when it
> comes across a macro with args, it creates a VMProxyArg. For reasons
> I don't (need to) grasp, it creates some temporary velocity code that
> uses the Include directive and does a quick parse/evaluate on it.
> Once I re-enabled the include directive, things worked again.
>
> --
> Serge Knystautas
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@...
>
> On Thu, Jul 3, 2008 at 1:28 PM, Serge Knystautas <sknystautas@...> wrote:
>> This is a pretty far out question, but maybe someone could point me in
>> the right direction.
>>
>> As I mentioned a few weeks back, I realized the ResourceLoader concept
>> doesn't fit my CMS, so I began to access the core API. I basically
>> completely rewrote my own RuntimeInstance (my class implements
>> RuntimeServices) and just about everything I need works... VTL is
>> found, parsed, rendered, context variables work, foreach directive,
>> etc...
>>
>> One issue I have is with Macro arguments. The macro directive is
>> enabled, initialized, my vmfactory works, and I can create and use 0
>> argument macros just fine. It also works that if I define a 1
>> argument macro and use the macro with 2 arguments, it gives the
>> appropriate error that I passed the wrong number of arguments (I have
>> velocimacro.arguments.strict true).
>>
>> However, when I create a macro with more than 0 arguments and use it
>> correctly, I get this stack trace I can't understand. I must be not
>> initializing something somehow, but it's so many levels removed, I'm
>> not quite sure what's going on.
>>
>> java.lang.NullPointerException
>> at org.apache.velocity.runtime.parser.node.SimpleNode.jjtGetChild(SimpleNode.java:172)
>> at org.apache.velocity.runtime.directive.VMProxyArg.setup(VMProxyArg.java:409)
>> at org.apache.velocity.runtime.directive.VMProxyArg.<init>(VMProxyArg.java:136)
>> at org.apache.velocity.runtime.directive.VelocimacroProxy.setupProxyArgs(VelocimacroProxy.java:401)
>> at org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:321)
>> at org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309)
>> at org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134)
>> at org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285)
>>
>> The VTL in question is:
>>
>> =======================================================
>> #macro (stuff $arg1)
>> Hello stuff $arg1
>> #end
>>
>> #macro (foo)
>> Foooooo
>> #end
>>
>> #foo() ## This works!
>>
>> #stuff("foo") ## This gives the above stack trace
>> =======================================================
>>
>> If anyone has any pointers on what this might be looking for, I would
>> greatly appreciate it.
>>
>> --
>> Serge Knystautas
>> Lokitech >> software . strategy . design >> http://www.lokitech.com
>> p. 301.656.5501
>> e. sergek@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

Re: Velocity arg init issue

2008-07-03T13:18:57Z

Wow, figured this one out. :( I doubt anyone else will hit this, but
wanted to post it so nobody else wastes their time on this.

The issue is that when the Macro directive initializes itself, when it
comes across a macro with args, it creates a VMProxyArg. For reasons
I don't (need to) grasp, it creates some temporary velocity code that
uses the Include directive and does a quick parse/evaluate on it.
Once I re-enabled the include directive, things worked again.

--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@...

On Thu, Jul 3, 2008 at 1:28 PM, Serge Knystautas <sknystautas@...> wrote:

> This is a pretty far out question, but maybe someone could point me in
> the right direction.
>
> As I mentioned a few weeks back, I realized the ResourceLoader concept
> doesn't fit my CMS, so I began to access the core API. I basically
> completely rewrote my own RuntimeInstance (my class implements
> RuntimeServices) and just about everything I need works... VTL is
> found, parsed, rendered, context variables work, foreach directive,
> etc...
>
> One issue I have is with Macro arguments. The macro directive is
> enabled, initialized, my vmfactory works, and I can create and use 0
> argument macros just fine. It also works that if I define a 1
> argument macro and use the macro with 2 arguments, it gives the
> appropriate error that I passed the wrong number of arguments (I have
> velocimacro.arguments.strict true).
>
> However, when I create a macro with more than 0 arguments and use it
> correctly, I get this stack trace I can't understand. I must be not
> initializing something somehow, but it's so many levels removed, I'm
> not quite sure what's going on.
>
> java.lang.NullPointerException
> at org.apache.velocity.runtime.parser.node.SimpleNode.jjtGetChild(SimpleNode.java:172)
> at org.apache.velocity.runtime.directive.VMProxyArg.setup(VMProxyArg.java:409)
> at org.apache.velocity.runtime.directive.VMProxyArg.<init>(VMProxyArg.java:136)
> at org.apache.velocity.runtime.directive.VelocimacroProxy.setupProxyArgs(VelocimacroProxy.java:401)
> at org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:321)
> at org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309)
> at org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134)
> at org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285)
>
> The VTL in question is:
>
> =======================================================
> #macro (stuff $arg1)
> Hello stuff $arg1
> #end
>
> #macro (foo)
> Foooooo
> #end
>
> #foo() ## This works!
>
> #stuff("foo") ## This gives the above stack trace
> =======================================================
>
> If anyone has any pointers on what this might be looking for, I would
> greatly appreciate it.
>
> --
> Serge Knystautas
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Velocity arg init issue

2008-07-03T10:28:25Z

This is a pretty far out question, but maybe someone could point me in
the right direction.

As I mentioned a few weeks back, I realized the ResourceLoader concept
doesn't fit my CMS, so I began to access the core API. I basically
completely rewrote my own RuntimeInstance (my class implements
RuntimeServices) and just about everything I need works... VTL is
found, parsed, rendered, context variables work, foreach directive,
etc...

One issue I have is with Macro arguments. The macro directive is
enabled, initialized, my vmfactory works, and I can create and use 0
argument macros just fine. It also works that if I define a 1
argument macro and use the macro with 2 arguments, it gives the
appropriate error that I passed the wrong number of arguments (I have
velocimacro.arguments.strict true).

However, when I create a macro with more than 0 arguments and use it
correctly, I get this stack trace I can't understand. I must be not
initializing something somehow, but it's so many levels removed, I'm
not quite sure what's going on.

java.lang.NullPointerException
at org.apache.velocity.runtime.parser.node.SimpleNode.jjtGetChild(SimpleNode.java:172)
at org.apache.velocity.runtime.directive.VMProxyArg.setup(VMProxyArg.java:409)
at org.apache.velocity.runtime.directive.VMProxyArg.<init>(VMProxyArg.java:136)
at org.apache.velocity.runtime.directive.VelocimacroProxy.setupProxyArgs(VelocimacroProxy.java:401)
at org.apache.velocity.runtime.directive.VelocimacroProxy.setupMacro(VelocimacroProxy.java:321)
at org.apache.velocity.runtime.directive.VelocimacroProxy.init(VelocimacroProxy.java:309)
at org.apache.velocity.runtime.parser.node.ASTDirective.init(ASTDirective.java:134)
at org.apache.velocity.runtime.parser.node.SimpleNode.init(SimpleNode.java:285)

The VTL in question is:

=======================================================
#macro (stuff $arg1)
Hello stuff $arg1
#end

#macro (foo)
Foooooo
#end

#foo() ## This works!

#stuff("foo") ## This gives the above stack trace
=======================================================

If anyone has any pointers on what this might be looking for, I would
greatly appreciate it.

--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Results from a security audit

2008-07-02T13:47:10Z

On Wed, Jul 2, 2008 at 4:21 PM, Nathan Bubna <nbubna@...> wrote:

> On Wed, Jul 2, 2008 at 12:59 PM, Will Glass-Husain
> <wglasshusain@...> wrote:
> > Should Velocity be sanity checking these type of arguments in internal
> > functions? I open that question to our other experienced developers.
> > Henning has advocated null checking in the past, perhaps this is a
> similar
> > issue.
>
> no thanks. what would we do if we spotted such an overflow? throw an
> error, but that's already what will happen. we could perhaps put a
> more explanatory error message in place, but in most cases described,
> the user is doing something very extreme to cause it. i expect it
> should be pretty obvious to them that their 2+ million argument method
> call or macro or 2+ million node template might be the source of their
> problem. i also have never heard of anyone running across these in
> all of my many years reading these lists. i don't think it's worth
> the effort. the Parser and VelocityCharStream ones are perhaps a bit
> more likely to occur, but again, i have not heard of that happening.
> i say leave them be.
>

I concur with Nathan. Given that these exceptions would be triggered on
theoretically possible circumstances but realistically insane practice I see
no reason to waste anyone's time on it. I have enough information from this
discussion to state that case then turn it around on them and make them
explain their risk assessment.

>
> > Regarding WebMacro in the velocity.jar. This is a utility class, intended
> to
> > help WebMacro users migrate to Velocity. Does your app permit users to
> call
> > main methods? If not, doesn't seem significant. If your security
> concerns
> > are strong enough to warrant removal of this method, I recommend creating
> a
> > simple ant script to do a custom build of the Velocity jar that removes
> this
> > class. (There are no dependencies on it).
>

No we don't allow calls to main methods. Removing WebMacro from the jar is
easy enough to do. (though not at a security concern, more a client
management concern)

>
> >
> > Regarding the use of Random in Math.tools. It's simply a pass through to
> > the Java function. No worse or better than Java. Don't like it? Don't
> > configure your app to use MathTools. Write your own tool-- it's easy.
>

Nope, we don't use it. Looks like its not used for anything worrisome from
your end so I'm not worried.

>
> >
> > I think it's unlikely we'll remove error messages from the log files. We
> > find most users of Velocity find these helpful. If this is an issue,
> > comment them out and recompile the code. Or (if you don't want to fork
> > the source) create a custom logger that ignores those comments.
> >
>

Not a major deal to me. Hope that these lows didn't come across as being
considered a real issue to me

>
> > One more suggestion to Tom. It seems that the integer overflow issues
> are
> > probably the most troubling to your auditors. It's unlikely we'll
> rapidly
> > change these (low priority to the rest of us). However, if you or a
> > colleague were to go through these 9 methods and add argument-checking
> code,
> > then submit in a patch, we'd probably add it in to the base. (Would be
> > interesting to get other perspectives on this first).
>
> i wouldn't veto, but don't expect me to waste any more time on it. :)
>

I'll save that as a backup plan. Given the discussion above, I don't see it
having to come to that.

Again, thanks all for taking the time. I appreciate it.

Tom

Re: Results from a security audit

2008-07-02T13:38:30Z

I agree with Will & Nathan. I don't know what tool they used, but it
doesn't know Java's internals for sure.
Validating user input(when they call the API) is a must but rather than
that is just insane to check what they suggested. Of course, when some
(user) parameters are used to allocate memory you should check if the
value is bellow a reasonable value, just to be sure nobody can bring the
JVM down(once you got OutOfMemory exception you must presume the
application is not stable and must be restarted).

Except for an OutOfMemory prevention, any exception(like
ArrayIndexOutOfBoundsException, NegativeArraySizeException) is welcomed
and it is a standard way to stop the execution flow.

Tom Jenkins wrote:

> I posted on the user list asking where I should bring up the results
> of a 3rd party security audit one of our applications had to go
> through.
>
> All of these were found through static analysis; no attack vectors are
> known. I'm also unsure of the validity of these results, but I have
> to do my due diligence.
>
> We're using Velocity 1.5 and Velocity Tools 1.3
>
> Excuse the formatting...
>
> Very High Risk
> ============
> Integer Overflow (Wrap or Wraparound) (CWE ID 190)
>
> Description
> An integer overflow condition exists when an integer that has not been
> properly sanity checked is used in the determination of an offset or
> size for memory allocation, copying, concatenation, or similarly. If
> the integer in question is incremented past the maximum possible
> value, it may wrap to become a very small, or negative number,
> therefore providing an unintended value. This occurs most commonly in
> arithmetic operations or loop iterations. Integer overflows can often
> result in buffer overflows or data corruption, both of which may be
> potentially exploited to execute arbitrary code.
>
> Recommendations
> Perform bounds checking to ensure that integers do not exceed the
> maximum possible value.
>
> File Line
> Macro.java 241
> SimpleNode.java 156
> VelocityCharStream.java 65
> VelocityCharStream.java 67
> VelocityCharStream.java 416
> VelocityCharStream.java 66
> ASTMethod.java 143
> ASTMethod.java 134
> Parser.java 3298
>
> My analysis:
> Macro:
> ----------
> int numArgs = node.jjtGetNumChildren();
> numArgs--; // avoid the block tree...
>
> --> String argArray[] = new String[numArgs];
>
> Looks like the flag is because if jjtGetNumChildren ever returns 0,
> numArgs will be -1. But that will just throw a
> NegativeArraySizeException so there isn't any overflowing. May be
> unintended that it go to -1, however.
>
>
> SimpleNode:
> -------------------
> public void jjtAddChild(Node n, int i)
> {
> if (children == null)
> {
> --> children = new Node[i + 1];
> }
> else if (i >= children.length)
>
> Theoretically the parameter 'i' could be max int. Not sure if in
> practice this will be an issue. This will wrap, but then we get a
> NegativeArraySizeException.
>
>
> VelocityCharStream:
> ------------------------------
> private final void ExpandBuff(boolean wrapAround)
> {
> --> char[] newbuffer = new char[bufsize + 2048];
> --> int newbufline[] = new int[bufsize + 2048];
> --> int newbufcolumn[] = new int[bufsize + 2048];
>
> All 3 of these array initializations are flagged. Later on in
> ExpandBuff bufsize is incremented by 2048. So again theoretically it
> could wrap.
>
>
> VelocityCharStream:
> ------------------------------
> public final char[] GetSuffix(int len)
> {
> --> char[] ret = new char[len];
>
> No idea why this is flagged.
>
>
>
> ASTMethod:
> -----------------
> VelMethod method = null;
>
> --> Object [] params = new Object[paramCount];
>
> try
> {
> /*
> * sadly, we do need recalc the values of the args, as this can
> * change from visit to visit
> */
>
> --> final Class[] paramClasses = paramCount > 0 ? new
> Class[paramCount] : ArrayUtils.EMPTY_CLASS_ARRAY;
>
> paramCount is set by:
> paramCount = jjtGetNumChildren() - 1;
> so again if that method can return a 0, paramCount will wrap. And
> again a NegativeArraySizeException.
>
>
> Parser:
> ----------
> private void jj_add_error_token(int kind, int pos) {
> if (pos >= 100) return;
> if (pos == jj_endpos + 1) {
> jj_lasttokens[jj_endpos++] = kind;
> } else if (jj_endpos != 0) {
> --> jj_expentry = new int[jj_endpos];
>
> Again, theoretically jj_endpos could get so large as to wrap. And
> again a NegativeArraySizeException.
>
>
> Any suggestions on how to position these 9 in my meeting with the
> client and auditors? The fact that an exception is thrown (though I
> haven't specifically tested these methods) has got to alleviate some
> of the client panic. Though what does concern me is that knowing an
> exception should be thrown here, why is the auditor marking these as
> Very High?
>
>
> Medium Risk
> ==========
>
> Leftover Debug Code (CWE ID 489)
>
> Description
> A method may be leftover debug code that creates an unintended entry
> point in a web application. Although this is an acceptable practice
> during product development, classes that are part of a production J2EE
> application should not define a main() method. Whether this method can
> be remotely invoked depends on the configuration of the J2EE container
> and the application itself.
>
> Recommendations
> A method may be leftover debug code that creates an unintended entry
> point in a web application. Although this is an acceptable practice
> during product development, classes that are part of a production J2EE
> application should not define a main() method. Whether this method can
> be remotely invoked depends on the configuration of the J2EE container
> and the application itself.
>
> File Line
> WebMacro.java 297
>
> Won't post the code; simply put there is a main() method there. We
> don't reference WebMacro anywhere (that I can see) but its in the
> velocity jar so it popped out on the scan.
>
> Also want to note that WebMacro "failed" another test - External
> Control of File Name or Path (CWE ID 73). But as this class isn't
> used that I can see I won't include that "failure".
>
> Does WebMacro have to be in the velocity jar?
>
> ++++++++++++++++++++++++++++++
>
> Failure to Sanitize Script-Related HTML Tags in a Web Page (Basic XSS)
> (CWE ID 80)
>
> Description
> This call contains a cross-site scripting (XSS) flaw. The application
> populates the HTTP response with user-supplied input, allowing an
> attacker to embed malicious content, such as Javascript code, which
> will be executed in the context of the victim's browser. XSS
> vulnerabilities are commonly exploited to steal or manipulate cookies,
> modify presentation of content, and compromise confidential
> information, with new attack vectors being discovered on a regular
> basis.
>
> Recommendations
> Use HTML entities to encode all non-alphanumeric user-supplied data
> when using it to construct an HTTP response. Always validate
> user-supplied input to ensure that it conforms to the expected format,
> using centralized data validation routines when possible.
>
> File Line
> VelocityViewServlet.java 814
>
> It looks like a change was made to the servlet to add escapeHtml
> (r480851) in 1.3. Not sure why it was flagged. Either way, it looks
> like an upgrade of velocity tools will solve that one for us.
>
> ++++++++++++++++++++++++++++++
>
> Insufficient Entropy (CWE ID 331)
>
> Description
> Standard random number generators do not provide a sufficient amount
> of entropy when used for security purposes. Attackers can brute force
> the output of pseudorandom number generators such as rand().
>
> Recommendations
> If this random number is used where security is a concern, such as
> generating a session key or session identifier, use a trusted
> cryptographic random number generator instead. These can be found on
> the Windows platform in the CryptoAPI or in an open source library
> such as OpenSSL.
>
> File Line
> MathTool.java 361
> MathTool.java 364
>
> Both of these lines have Math.random(). The audit tool just doesn't
> like Math.random() at all. Not sure what MathTool.getRandom() or
> MathTool.random() are used for internally. As an aside, I have
> changed (because we got dinged on it also) to using SecureRandom which
> I believe will pass this test.
>
>
> Low Risk
> ==========
>
> Error Message Information Leaks (CWE ID 209)
>
> Description
> Due to the fact that SOAP relies on XML data from the user, it is
> possible for the user to submit an invalid XML document to attack the
> parsing routines which can cause buffer overrun and/or denial of
> service attacks. The SOAP service library is responsible for
> converting the data into language specific data types. Users could
> attack this layer by utilizing an understanding of the back end
> languages limitations and the weaknesses in the SOAP libraries string
> to data type conversion process. After getting past all the SOAP
> specific processes your application logic can be attacked with normal
> input attacks, such as providing a negative number value when your
> software is expecting a standard number value and is ill equipped to
> handle it, or even general SQL Injection attacks.
>
> Recommendations
> Make sure you are using the latest security patched parsing engine
> available and that you are trapping and handling all errors due to
> parsing problems and responding to the user gracefully. Make sure you
> are using the latest security patched SOAP library available and that
> you are trapping and handling all errors due to data type conversion
> problems and responding to the user gracefully. It is important to use
> strong definitions of expected data types to avoid having attacks get
> to the next layer. Your application logic must validate all data
> coming in. Do not rely on the SOAP library to handle this for you,
> unless it has specific features to do so. Like any web application
> development, it is important to consider all input from a user to be
> dirty until it passes validation and filtering to be specifically the
> type of input expected.
>
> File Line
> SystemLogChute.java 142
> StringUtils.java 376
> SystemLogChute.java 141
> Generator.java 215
> PrintExceptions.java 102
> FieldMethodizer.java 162
> VelocityViewServlet.java 807
> FieldMethodizer.java 92
> Generator.java 168
> StringUtils.java 489
> SystemLogChute.java 151
> LogSystemCommonsLog.java 156
> StringUtils.java 389
> Generator.java 520
> VelocityServlet.java 705
> FieldMethodizer.java 114
>
> I'm not quite sure what to say about these. I haven't gone through
> them all, but in our files that failed it was because of a call to
> printStackTrace(). Every call to printStackTrace() seems to raise a
> flag with the auditors. We're going to change ours to call a logger.
> Given that these are very low, I'm not too worried about these. But
> for completeness I included them.
>
>
>
> Hope you could follow this VERY long post.
>
> If anyone has any thoughts or suggestions on how I should proceed I
> would welcome the input.
>
> Thanks for your time.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

Re: Results from a security audit

2008-07-02T13:21:42Z

On Wed, Jul 2, 2008 at 12:59 PM, Will Glass-Husain
<wglasshusain@...> wrote:

> Thanks, Tom.
>
> That's interesting. Appreciate the time to compile this list and post it.
> I've posted some thoughts (fairly adhoc) directed to the community, you, and
> your auditors below.
>
> Personally, I wasn't familiar with Integer Overflow errors in Java. I'd
> always assumed the bounds checking took care of this C-like error. I see
> however there are still potential issues. Googling turned up a nice
> summary of the issue here. (very end of page).
>
> http://www.javacoffeebreak.com/books/extracts/javanotesv3/c9/s1.html
>
> Personally, this seems fairly miniscule risk here ("Very High Risk"? hard to
> take that seriously). None of these functions are under the direct control
> of the user. The calls to functions that access nodes are generally
> performed while iterating through a fixed number of nodes. One response to
> this audit would be to check the calls made to each function and confirm the
> arguments are bounded.
>
> Should Velocity be sanity checking these type of arguments in internal
> functions? I open that question to our other experienced developers.
> Henning has advocated null checking in the past, perhaps this is a similar
> issue.

no thanks. what would we do if we spotted such an overflow? throw an
error, but that's already what will happen. we could perhaps put a
more explanatory error message in place, but in most cases described,
the user is doing something very extreme to cause it. i expect it
should be pretty obvious to them that their 2+ million argument method
call or macro or 2+ million node template might be the source of their
problem. i also have never heard of anyone running across these in
all of my many years reading these lists. i don't think it's worth
the effort. the Parser and VelocityCharStream ones are perhaps a bit
more likely to occur, but again, i have not heard of that happening.
i say leave them be.

> There are other much more significant gotchas. Please be sure to read the
> article Nathan referenced. In particular, if you have third parties
> uploading templates they have the potential to call any Java method on
> objects in the context. Without proper configuration, they can even access
> the ClassLoader and create instantiate new objects (for example, getting a
> File object to access arbitrary files). You need to configure Velocity to
> use the SecureUberspector to prevent this. Also, Velocity contains event
> handlers to automatically escape all references-- this is recommended if
> users enter text.

agreed. their static code analysis missed the greatest risks, despite
their extreme paranoia. if you allow any third party/user content to
be processed by Velocity as VTL (either by user templates or
processing their inputs with the RenderTool), then you really must use
the SecureUberspector or be an expert in controlling java security
permissions at the JVM level. And of course, escaping all user inputs
(either via the event handler or something like EscapeTool) is always
crucial to app security.

> Regarding WebMacro in the velocity.jar. This is a utility class, intended to
> help WebMacro users migrate to Velocity. Does your app permit users to call
> main methods? If not, doesn't seem significant. If your security concerns
> are strong enough to warrant removal of this method, I recommend creating a
> simple ant script to do a custom build of the Velocity jar that removes this
> class. (There are no dependencies on it).
>
> Regarding VelocityViewServlet-- I'll let Nathan or one of the other Tools
> developers comment.
>
> Regarding the use of Random in Math.tools. It's simply a pass through to
> the Java function. No worse or better than Java. Don't like it? Don't
> configure your app to use MathTools. Write your own tool-- it's easy.
>
> I think it's unlikely we'll remove error messages from the log files. We
> find most users of Velocity find these helpful. If this is an issue,
> comment them out and recompile the code. Or (if you don't want to fork
> the source) create a custom logger that ignores those comments.
>
> One more suggestion to Tom. It seems that the integer overflow issues are
> probably the most troubling to your auditors. It's unlikely we'll rapidly
> change these (low priority to the rest of us). However, if you or a
> colleague were to go through these 9 methods and add argument-checking code,
> then submit in a patch, we'd probably add it in to the base. (Would be
> interesting to get other perspectives on this first).

i wouldn't veto, but don't expect me to waste any more time on it. :)

> Then you wouldn't
> have to fork the code. More on how to do this here:
> http://wiki.apache.org/velocity/GettingYourPatchCommitted
>
> Best, WILL
>
> On Wed, Jul 2, 2008 at 10:49 AM, Tom Jenkins <tomj.devis@...> wrote:
>
>> I posted on the user list asking where I should bring up the results
>> of a 3rd party security audit one of our applications had to go
>> through.
>>
>> All of these were found through static analysis; no attack vectors are
>> known. I'm also unsure of the validity of these results, but I have
>> to do my due diligence.
>>
>> We're using Velocity 1.5 and Velocity Tools 1.3
>>
>> Excuse the formatting...
>>
>> Very High Risk
>> ============
>> Integer Overflow (Wrap or Wraparound) (CWE ID 190)
>>
>> Description
>> An integer overflow condition exists when an integer that has not been
>> properly sanity checked is used in the determination of an offset or
>> size for memory allocation, copying, concatenation, or similarly. If
>> the integer in question is incremented past the maximum possible
>> value, it may wrap to become a very small, or negative number,
>> therefore providing an unintended value. This occurs most commonly in
>> arithmetic operations or loop iterations. Integer overflows can often
>> result in buffer overflows or data corruption, both of which may be
>> potentially exploited to execute arbitrary code.
>>
>> Recommendations
>> Perform bounds checking to ensure that integers do not exceed the
>> maximum possible value.
>>
>> File Line
>> Macro.java 241
>> SimpleNode.java 156
>> VelocityCharStream.java 65
>> VelocityCharStream.java 67
>> VelocityCharStream.java 416
>> VelocityCharStream.java 66
>> ASTMethod.java 143
>> ASTMethod.java 134
>> Parser.java 3298
>>
>> My analysis:
>> Macro:
>> ----------
>> int numArgs = node.jjtGetNumChildren();
>> numArgs--; // avoid the block tree...
>>
>> --> String argArray[] = new String[numArgs];
>>
>> Looks like the flag is because if jjtGetNumChildren ever returns 0,
>> numArgs will be -1. But that will just throw a
>> NegativeArraySizeException so there isn't any overflowing. May be
>> unintended that it go to -1, however.
>>
>>
>> SimpleNode:
>> -------------------
>> public void jjtAddChild(Node n, int i)
>> {
>> if (children == null)
>> {
>> --> children = new Node[i + 1];
>> }
>> else if (i >= children.length)
>>
>> Theoretically the parameter 'i' could be max int. Not sure if in
>> practice this will be an issue. This will wrap, but then we get a
>> NegativeArraySizeException.
>>
>>
>> VelocityCharStream:
>> ------------------------------
>> private final void ExpandBuff(boolean wrapAround)
>> {
>> --> char[] newbuffer = new char[bufsize + 2048];
>> --> int newbufline[] = new int[bufsize + 2048];
>> --> int newbufcolumn[] = new int[bufsize + 2048];
>>
>> All 3 of these array initializations are flagged. Later on in
>> ExpandBuff bufsize is incremented by 2048. So again theoretically it
>> could wrap.
>>
>>
>> VelocityCharStream:
>> ------------------------------
>> public final char[] GetSuffix(int len)
>> {
>> --> char[] ret = new char[len];
>>
>> No idea why this is flagged.
>>
>>
>>
>> ASTMethod:
>> -----------------
>> VelMethod method = null;
>>
>> --> Object [] params = new Object[paramCount];
>>
>> try
>> {
>> /*
>> * sadly, we do need recalc the values of the args, as this can
>> * change from visit to visit
>> */
>>
>> --> final Class[] paramClasses = paramCount > 0 ? new
>> Class[paramCount] : ArrayUtils.EMPTY_CLASS_ARRAY;
>>
>> paramCount is set by:
>> paramCount = jjtGetNumChildren() - 1;
>> so again if that method can return a 0, paramCount will wrap. And
>> again a NegativeArraySizeException.
>>
>>
>> Parser:
>> ----------
>> private void jj_add_error_token(int kind, int pos) {
>> if (pos >= 100) return;
>> if (pos == jj_endpos + 1) {
>> jj_lasttokens[jj_endpos++] = kind;
>> } else if (jj_endpos != 0) {
>> --> jj_expentry = new int[jj_endpos];
>>
>> Again, theoretically jj_endpos could get so large as to wrap. And
>> again a NegativeArraySizeException.
>>
>>
>> Any suggestions on how to position these 9 in my meeting with the
>> client and auditors? The fact that an exception is thrown (though I
>> haven't specifically tested these methods) has got to alleviate some
>> of the client panic. Though what does concern me is that knowing an
>> exception should be thrown here, why is the auditor marking these as
>> Very High?
>>
>>
>> Medium Risk
>> ==========
>>
>> Leftover Debug Code (CWE ID 489)
>>
>> Description
>> A method may be leftover debug code that creates an unintended entry
>> point in a web application. Although this is an acceptable practice
>> during product development, classes that are part of a production J2EE
>> application should not define a main() method. Whether this method can
>> be remotely invoked depends on the configuration of the J2EE container
>> and the application itself.
>>
>> Recommendations
>> A method may be leftover debug code that creates an unintended entry
>> point in a web application. Although this is an acceptable practice
>> during product development, classes that are part of a production J2EE
>> application should not define a main() method. Whether this method can
>> be remotely invoked depends on the configuration of the J2EE container
>> and the application itself.
>>
>> File Line
>> WebMacro.java 297
>>
>> Won't post the code; simply put there is a main() method there. We
>> don't reference WebMacro anywhere (that I can see) but its in the
>> velocity jar so it popped out on the scan.
>>
>> Also want to note that WebMacro "failed" another test - External
>> Control of File Name or Path (CWE ID 73). But as this class isn't
>> used that I can see I won't include that "failure".
>>
>> Does WebMacro have to be in the velocity jar?
>>
>> ++++++++++++++++++++++++++++++
>>
>> Failure to Sanitize Script-Related HTML Tags in a Web Page (Basic XSS)
>> (CWE ID 80)
>>
>> Description
>> This call contains a cross-site scripting (XSS) flaw. The application
>> populates the HTTP response with user-supplied input, allowing an
>> attacker to embed malicious content, such as Javascript code, which
>> will be executed in the context of the victim's browser. XSS
>> vulnerabilities are commonly exploited to steal or manipulate cookies,
>> modify presentation of content, and compromise confidential
>> information, with new attack vectors being discovered on a regular
>> basis.
>>
>> Recommendations
>> Use HTML entities to encode all non-alphanumeric user-supplied data
>> when using it to construct an HTTP response. Always validate
>> user-supplied input to ensure that it conforms to the expected format,
>> using centralized data validation routines when possible.
>>
>> File Line
>> VelocityViewServlet.java 814
>>
>> It looks like a change was made to the servlet to add escapeHtml
>> (r480851) in 1.3. Not sure why it was flagged. Either way, it looks
>> like an upgrade of velocity tools will solve that one for us.
>>
>> ++++++++++++++++++++++++++++++
>>
>> Insufficient Entropy (CWE ID 331)
>>
>> Description
>> Standard random number generators do not provide a sufficient amount
>> of entropy when used for security purposes. Attackers can brute force
>> the output of pseudorandom number generators such as rand().
>>
>> Recommendations
>> If this random number is used where security is a concern, such as
>> generating a session key or session identifier, use a trusted
>> cryptographic random number generator instead. These can be found on
>> the Windows platform in the CryptoAPI or in an open source library
>> such as OpenSSL.
>>
>> File Line
>> MathTool.java 361
>> MathTool.java 364
>>
>> Both of these lines have Math.random(). The audit tool just doesn't
>> like Math.random() at all. Not sure what MathTool.getRandom() or
>> MathTool.random() are used for internally. As an aside, I have
>> changed (because we got dinged on it also) to using SecureRandom which
>> I believe will pass this test.
>>
>>
>> Low Risk
>> ==========
>>
>> Error Message Information Leaks (CWE ID 209)
>>
>> Description
>> Due to the fact that SOAP relies on XML data from the user, it is
>> possible for the user to submit an invalid XML document to attack the
>> parsing routines which can cause buffer overrun and/or denial of
>> service attacks. The SOAP service library is responsible for
>> converting the data into language specific data types. Users could
>> attack this layer by utilizing an understanding of the back end
>> languages limitations and the weaknesses in the SOAP libraries string
>> to data type conversion process. After getting past all the SOAP
>> specific processes your application logic can be attacked with normal
>> input attacks, such as providing a negative number value when your
>> software is expecting a standard number value and is ill equipped to
>> handle it, or even general SQL Injection attacks.
>>
>> Recommendations
>> Make sure you are using the latest security patched parsing engine
>> available and that you are trapping and handling all errors due to
>> parsing problems and responding to the user gracefully. Make sure you
>> are using the latest security patched SOAP library available and that
>> you are trapping and handling all errors due to data type conversion
>> problems and responding to the user gracefully. It is important to use
>> strong definitions of expected data types to avoid having attacks get
>> to the next layer. Your application logic must validate all data
>> coming in. Do not rely on the SOAP library to handle this for you,
>> unless it has specific features to do so. Like any web application
>> development, it is important to consider all input from a user to be
>> dirty until it passes validation and filtering to be specifically the
>> type of input expected.
>>
>> File Line
>> SystemLogChute.java 142
>> StringUtils.java 376
>> SystemLogChute.java 141
>> Generator.java 215
>> PrintExceptions.java 102
>> FieldMethodizer.java 162
>> VelocityViewServlet.java 807
>> FieldMethodizer.java 92
>> Generator.java 168
>> StringUtils.java 489
>> SystemLogChute.java 151
>> LogSystemCommonsLog.java 156
>> StringUtils.java 389
>> Generator.java 520
>> VelocityServlet.java 705
>> FieldMethodizer.java 114
>>
>> I'm not quite sure what to say about these. I haven't gone through
>> them all, but in our files that failed it was because of a call to
>> printStackTrace(). Every call to printStackTrace() seems to raise a
>> flag with the auditors. We're going to change ours to call a logger.
>> Given that these are very low, I'm not too worried about these. But
>> for completeness I included them.
>>
>>
>>
>> Hope you could follow this VERY long post.
>>
>> If anyone has any thoughts or suggestions on how I should proceed I
>> would welcome the input.
>>
>> Thanks for your time.
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@...
> www.forio.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...