owasp-input-api-developers Mailing List for OWASP Filter Project (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Mon, 9 Sep 2002, Alex Russell wrote:

Sorry for the stupid miss-post. This is what I get for doing too much
OWASP stuff = )

-- 
Alex Russell
al...@Se...
al...@ne...

hey Gene,

On Wednesday 04 September 2002 17:00, Gene McKenna wrote:
> By the looks of things, i will need this weekend to get
> a review done. can we wait until monday to tag it?

I noticed your checkins from this weekend. Thanks so much for covering ou=
r=20
collective butts =3D )

I'm finishing up with adding images right now. If everyone is comfortable=
 with=20
where we are, I'll get 1.1 tagged yet tonight.

Let me know.

--=20
Alex Russell
al...@Se...
al...@ne...

Hello everyone,

I am sorry I didn't get this posted sooner, but life has a funny way of
interfering with the best laid plans and all...

As mentioned in my previous posts, I've put together a testing framework
that I think might be useful for us on the Filters project.  You can
download it at http://www.christophertodd.com/owasp/.  I hope everythinhg
will be fairly self-explanatory, but if you have any problems using it,
please respond to this email (including the list).

I haven't posted this to CVS yet, because I wanted everyone's feedback
regarding ease of use, etc.

I am working on a version that does not require the use of a webserver, and
I will post that as soon as I have it available.  It should not be difficult
to put together.

I look forward to your comments,
Chris

On Thu, 5 Sep 2002, Steven J. Sobol wrote:

> 
> Again...
> 
> Anyone out there?

yeah, sorry, just massively busy. I'll have status for you later this
afternoon

-- 
Alex Russell
al...@Se...
al...@ne...

Again...

Anyone out there?

-- 
Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH
http://JustTheNetLLC.com/ http://JustThe.net/ 888.480.4NET (4638)
Happily owned by a wife, two children, two cockatiels, four Chinese Shar-Pei,
a Pug, a Whippet, a rescued Greyhound, and a rescued Chow. :)

On Tue, 27 Aug 2002, Alex Russell wrote:

> That said, I'm hoping the list will have some input as to what our 2nd
> language should be.

I know PHP, VBSCRIPT (ASP) and C inside out; Perl somewhat, Python not at
all. I'd love to do PHP.

-- 
Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH

Matt,

> Perl or PHP, if we want to take a "popular" route.  IMO PHP developers
> are in much more need of this -- at least the perl developers have -t.
>
> That being said, I think the PHP version will be good for gauging how
> well the generally [security] clueless majority will accept this.
>
> As far as C, I agree with Nik that its not used very much and it will be
> a lot more difficult to implement.  Personally, I feel anyone still
> using C, at least for frontends, is a masochist.  No reason for that
> kind of power (and danger!) to be used for a web app.
>
> Python itself should be an easy jump from the Java, perl or python
> routes -- I don't think it will be very difficult to implement it in
> python.

All good points.  I agree about Python and C.  I originally voted for Perl,
but PHP should work just as well for testing the cross-language development
waters.

Chris

On Tue, 2002-08-27 at 17:32, Christopher Todd wrote:
[...]
> > Our thinking is that it'll be much easier for us to
> > be conscious of cross-language development problems if we force
> > ourselves to develop for at least 2 very different languages right off
> > the bat.
> 
> Makes sense to me, so long as everyone goes into this understanding that one
> of our goals is to be flexible and try to work out these issues.  I think
> our discussion about the testing tool/framework is a good example of how we
> all have different biases, *which is a Good Thing*, but to succeed, we all
> need to understand that the Perl folks have it right in that "There is more
> than one way to do it."  :-)
> 
> > Current thinking is that we might use one of the following:
> >
> > 	* PHP
> > 	* Python
> > 	* Perl
> > 	* C
> 
> I would argue for Perl.  It's popular, very different from Java, and we have
> Perl developers on this list.

Perl or PHP, if we want to take a "popular" route.  IMO PHP developers
are in much more need of this -- at least the perl developers have -t.

That being said, I think the PHP version will be good for gauging how
well the generally [security] clueless majority will accept this.

As far as C, I agree with Nik that its not used very much and it will be
a lot more difficult to implement.  Personally, I feel anyone still
using C, at least for frontends, is a masochist.  No reason for that
kind of power (and danger!) to be used for a web app.

Python itself should be an easy jump from the Java, perl or python
routes -- I don't think it will be very difficult to implement it in
python.

-matt

-- 
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce...
Credo quia absurdum est.

On Wed, 28 Aug 2002, Christopher Todd wrote:

> I had not intended to write a reqs doc for the testing tool, since it is
> essentially finished. 

Great!

> I want to tweak one or two things, but it's
> essentially ready.  The tool is pretty simple - it reads a config file with
> test input, posts to a web page (php, jsp, asp, whatever), grabs what the
> server sends back, and compares it to the expected output.
> 
> Sometime in the next day or so I'll post it to the web someplace where
> people can download it, try it, and tell me whether it sucks or rocks.  If
> the general consensus is that it is useful and fairly unobtrusive (or at
> least that it doesn't suck), I'll put it into CVS.

Sounds wonderful. Thanks so much for getting that done.

-- 
Alex Russell
al...@Se...
al...@ne...

> Is there going to be a requirments document for the testing tool and
> framework written also? I assume the tool will be written in perl.

I had not intended to write a reqs doc for the testing tool, since it is
essentially finished.  I want to tweak one or two things, but it's
essentially ready.  The tool is pretty simple - it reads a config file with
test input, posts to a web page (php, jsp, asp, whatever), grabs what the
server sends back, and compares it to the expected output.

Sometime in the next day or so I'll post it to the web someplace where
people can download it, try it, and tell me whether it sucks or rocks.  If
the general consensus is that it is useful and fairly unobtrusive (or at
least that it doesn't suck), I'll put it into CVS.

Chris

On Tue, 27 Aug 2002, Christopher Todd wrote:

> > I spoke with Gabe this afternoon and it was agreed that we're going to
> > use Java as one of the 2 inital development languages.
>
> +1
>
> > Our thinking is that it'll be much easier for us to
> > be conscious of cross-language development problems if we force
> > ourselves to develop for at least 2 very different languages right off
> > the bat.
>
> Makes sense to me, so long as everyone goes into this understanding that one
> of our goals is to be flexible and try to work out these issues.  I think
> our discussion about the testing tool/framework is a good example of how we
> all have different biases, *which is a Good Thing*, but to succeed, we all
> need to understand that the Perl folks have it right in that "There is more
> than one way to do it."  :-)
>
> > Current thinking is that we might use one of the following:
> >
> > 	* PHP
> > 	* Python
> > 	* Perl
> > 	* C
>
> I would argue for Perl.  It's popular, very different from Java, and we have
> Perl developers on this list.

I would have to vote for PHP, since I am not confident enough with Perl or
Java to write anything very serious, and do not understand the full scope
of either language. I am currently doing a lot of PHP work and could
easily justify developing PHP filters during work time, and could start on
it ASAP.

Filters for C are going to be very different to the other languages, since
it is a lower level language with its own issues. For full filter
functionality in C you will probably find yourself re-writting (or
writting wrappers for) a lot of the existing libc functions. How popular
is C in web apps nowadays anyway?

Is there going to be a requirments document for the testing tool and
framework written also? I assume the tool will be written in perl.

-Nik

> I spoke with Gabe this afternoon and it was agreed that we're going to
> use Java as one of the 2 inital development languages.

+1

> Our thinking is that it'll be much easier for us to
> be conscious of cross-language development problems if we force
> ourselves to develop for at least 2 very different languages right off
> the bat.

Makes sense to me, so long as everyone goes into this understanding that one
of our goals is to be flexible and try to work out these issues.  I think
our discussion about the testing tool/framework is a good example of how we
all have different biases, *which is a Good Thing*, but to succeed, we all
need to understand that the Perl folks have it right in that "There is more
than one way to do it."  :-)

> Current thinking is that we might use one of the following:
>
> 	* PHP
> 	* Python
> 	* Perl
> 	* C

I would argue for Perl.  It's popular, very different from Java, and we have
Perl developers on this list.

> As a final note, expect something vaguely resembling a "design document"
> from me by sometime tomorrow afternoon. At the very minimum it will
> outline our design philosophy (probably stolen from the vision doc), as
> well as technical specifics of how things will be built. Perhaps some
> sample usage semantics will be presented. Once I post it, we'll kick it
> around a bit before we start coding, but that shouldn't take more than a
> couple of days (end of week?).

Sounds good to me.  Q:  Given that the vision doc is high-level, will the
"design doc" be, in essence, a requirements doc?  WE've already have several
conversations relating to requirements; perhaps we could start by pulling
all those comments together for discussion?

Chris

Hey,

I spoke with Gabe this afternoon and it was agreed that we're going to
use Java as one of the 2 inital development languages. But that leaves
one still undecided. Our thinking is that it'll be much easier for us to
be conscious of cross-language development problems if we force
ourselves to develop for at least 2 very different languages right off
the bat.

That said, I'm hoping the list will have some input as to what our 2nd
language should be. Whatever it is, the development that happens for
that language will be done in a more-or-less procedural way, and so the
language should lend itself to that style of development.

Current thinking is that we might use one of the following:

	* PHP
	* Python
	* Perl
	* C

Other suggestions are of course welcome.

As a final note, expect something vaguely resembling a "design document"
from me by sometime tomorrow afternoon. At the very minimum it will
outline our design philosophy (probably stolen from the vision doc), as
well as technical specifics of how things will be built. Perhaps some
sample usage semantics will be presented. Once I post it, we'll kick it
around a bit before we start coding, but that shouldn't take more than a
couple of days (end of week?).

-- 
Alex Russell
al...@Se...
al...@ne...

Would those people who indicated an interest in the webmail package I'm
developing please re-email me... your mail seems to have gotten lost in 
the dozens of messages I get each day. 

I'm proceeding with the project and think it would be a great testbed for
the filters. It is written in PHP, though. Kinda sounds like we're moving
towards Java as the initial platform.

-- 
Steve Sobol, CTO  JustThe.net LLC, Mentor On The Lake, OH

On Sun, 2002-08-18 at 15:42, Alex Russell wrote:
> On Sun, 18 Aug 2002, Christopher Todd wrote:
> 
> > Interesting idea; I was thinking more along the lines of iterative
> > code-test-code-test, 
> 
> I think that whatever we do, we'll need that capability.
> 
> > but your suggestion would work better in an automated
> > nightly build type of situation.  
> 
> Yeah, I thought of that...Perhaps if there was a set of scripts that (on
> demand) made a CVS checkout, tested it, and reported the results
> more-or-less instantly?

Yes. We are really going to need something of this type. As a security
product, we really do need to focus on unit testing and system testing
as a key portion of the development. With many authors and new
contributors as is common in open source projects, we need to build some
tools that help assure that checkins don't break the security of the
system. I would suspect nightly builds with test run and the ability for
developers to do a test run would be ideal.

-gabe

-- 
Gabriel Lawrence
CTO
Butterfly Security <www.butterflysecurity.com>
(408) 333-9948
ga...@bu...

as seen on Bugtraq today..

http://www.mricon.com/html/phpfilter.html

havn't been able to break it yet.

-Nik

On 18 Aug 2002, Matt Wirges wrote:

> We need to iterate over a set of test data, pass them through test
> applications in each lang's library, get and parse the results, then
> make a report so we can identify problems.

right. Frankly I don't care that much about what you implement it in

Chris, Go nuts. You have my consent to use whatever language or design
you want. You have license. Check some code in, and we'll talk
more about testing then. I fully expect we'll go through a couple of
iterations, so let's get someting going and start collecting test cases.

Thanks for taking the initiative.

-- 
Alex Russell
al...@Se...
al...@ne...

On Sun, 2002-08-18 at 23:05, Alex Russell wrote:
> On 18 Aug 2002, Matt Wirges wrote:
> 
> > On Sun, 2002-08-18 at 22:14, Alex Russell wrote:
> > I just think that perl will be the quickest 
> 
> Quickest in what sense? Let's avoid maintenience nightmares for the time
> being and do it in either Java or Python.
Nightmares in what way?

We need to iterate over a set of test data, pass them through test
applications in each lang's library, get and parse the results, then
make a report so we can identify problems.

IMO, using Java for such a simple task such as this is like writing a
formmail in C++...
> 
> > and best way to handle the
> > tests.  LWP::simple anyone? and parsing?  You'd actually consider
> > something else? ;p
> 
> Yes.
> 
> > I see no need for an elaborate java program to do all of this.  While
> > tests are important, they shouldn't require a huge investment.
> > Should they?
> 
> No, which I think is what I"m advocating. Let's get something working
> that's easily extensible, and chug with it.
> 

At any rate, we should probably be concentrating on the filters
themselves, rather than their tests.  Yes, the tests will need to be
developed while we develop the filters, but we don't even have much past
the "requirments" phase.

-- 
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce...
Credo quia absurdum est.

On 18 Aug 2002, Matt Wirges wrote:

> On Sun, 2002-08-18 at 22:14, Alex Russell wrote:
> I just think that perl will be the quickest 

Quickest in what sense? Let's avoid maintenience nightmares for the time
being and do it in either Java or Python.

> and best way to handle the
> tests.  LWP::simple anyone? and parsing?  You'd actually consider
> something else? ;p

Yes.

> I see no need for an elaborate java program to do all of this.  While
> tests are important, they shouldn't require a huge investment.
> Should they?

No, which I think is what I"m advocating. Let's get something working
that's easily extensible, and chug with it.

-- 
Alex Russell
al...@Se...
al...@ne...

On Sun, 2002-08-18 at 22:14, Alex Russell wrote:
[...]
> Ick. I say let's do the testing framework in one language (Java's great
> with me) and let's have it do file-based/stdin-based invocation of the
> various interepreters and define some form of output that test programs
> should feed back to the caller so that we can determine success or
> failure.
> 
> Extending this to parse HTTP server input shouldn't be much harder at
> all (simply request with a socket, feed our malicous input, parse HTTP
> reply in common format). Something like this might even be able to test
> against various servers running different configs once we have it
> working corretly. The first step though is to get it working at the
> command line with a set of reasonable bad input against a reasonable set
> of interpreters.
> 
> Anyone think I'm smoking crack here?

I just think that perl will be the quickest and best way to handle the
tests.  LWP::simple anyone? and parsing?  You'd actually consider
something else? ;p

I see no need for an elaborate java program to do all of this.  While
tests are important, they shouldn't require a huge investment.
Should they?

-matt
-- 
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce...
Credo quia absurdum est.

On Sun, 18 Aug 2002, Christopher Todd wrote:

> Matt,
> 
> > The problem will be coming up with enough different cases to
> > cover as many methods of "attack" as possible.
> 
> Actually, we can simply ask all the gurus on the webappsec list to submit
> test cases to us.  I'm sure they'll come up with a ton.
> 
> > I don't see why a web server is necessary to test these cases?
> 
> When it comes to testing, I always assume it is best to test code in an
> environment that mimcs the production environment.  Different web servers
> and web app servers will process the input before web apps see it, and they
> might play with things like character encodings, etc.

we're going to be forcing canonicalization in our API anyway. Bring on
the funky encodings. I see no need to have a server involved to muck
with stuff when we can do it ourselves = )

> > We could write a test suite application in an appropriate language (I'm
> > thinking perl) that could invoke a simple application written in each
> > language that filters test data by a supplied filter, this simple app
> > then returns the filtered data to the test suite application which
> > determines if the output is correct.  This can be easily run after each
> > build.
> 
> I think the tricky part here is finding standalone interpreters for all the
> languages we will (eventually) support.  I am thinking of things like Cold
> Fusion, Cocoon, Zope and Enhydra (which uses XMLC).  Granted, these are not
> hugely popular platforms (please no flames, I'm only talking about market
> share :-), and I'm not suggesting we support them out of the box.

This is going to be grossly unpopular, but I say we get something
working for langauages that are reasonable candidates for a reference
implementation: Perl, PHP, Python, Java, C, C++. Among those I don't see
any that can't be called from the command line, so I think that in the
interest of getting something working, let's sidestep the complexity of
mucking with a server until we absolutely need to do so.

That might be sooner rather than later, but how much harder will it be
to throw in a couple of wget calls once we've got the rest of the
testing infrastructure in place?

> Your suggestion would be simpler than mine, and would generally make things
> easier on API porters.  My thought on having just one tool for doing all the
> testing for all the languages we support is that maintaining that tool and
> the test cases would require less overhead, and would provide greater
> consistency across the languages.

I think eventually we'll get there, but I'm not so sure it makes sense
unless we have our own test machines to play with. Until then, let's get
some command line testing tools going.

> An excellent point.  It's just that I'm not a very good Perl hacker.  :-)
> Most developers hate writing tests (or comments or documentation), and I
> love writing all three, so I thought I could help there.
> 
> On the flip side, it means we won't have one testing framework, we'll have
> one for every language we support, which could become a maintenance burden.

Ick. I say let's do the testing framework in one language (Java's great
with me) and let's have it do file-based/stdin-based invocation of the
various interepreters and define some form of output that test programs
should feed back to the caller so that we can determine success or
failure.

Extending this to parse HTTP server input shouldn't be much harder at
all (simply request with a socket, feed our malicous input, parse HTTP
reply in common format). Something like this might even be able to test
against various servers running different configs once we have it
working corretly. The first step though is to get it working at the
command line with a set of reasonable bad input against a reasonable set
of interpreters.

Anyone think I'm smoking crack here?

-- 
Alex Russell
al...@Se...
al...@ne...

Matt,

> The problem will be coming up with enough different cases to
> cover as many methods of "attack" as possible.

Actually, we can simply ask all the gurus on the webappsec list to submit
test cases to us.  I'm sure they'll come up with a ton.

> I don't see why a web server is necessary to test these cases?

When it comes to testing, I always assume it is best to test code in an
environment that mimcs the production environment.  Different web servers
and web app servers will process the input before web apps see it, and they
might play with things like character encodings, etc.

> While OWASP is geared towards web
> applications, I don't see why someone couldn't use these filters in
> other applications.

An excellent point, and one I hope we pursue.  Then again, the filtering
needs of web applications are different from many standalone apps, and our
first goal is to help web app developers.

> We could write a test suite application in an appropriate language (I'm
> thinking perl) that could invoke a simple application written in each
> language that filters test data by a supplied filter, this simple app
> then returns the filtered data to the test suite application which
> determines if the output is correct.  This can be easily run after each
> build.

I think the tricky part here is finding standalone interpreters for all the
languages we will (eventually) support.  I am thinking of things like Cold
Fusion, Cocoon, Zope and Enhydra (which uses XMLC).  Granted, these are not
hugely popular platforms (please no flames, I'm only talking about market
share :-), and I'm not suggesting we support them out of the box.  But
eventually, it might be nice.  And if we were to do a JSP taglib version of
the Filter API (which would also be nice), that would have to be run in a
JSP page.

Perl, PHP (you can use the compiled CGI binary), Python, Java, C, and C++
all have standalone interpreters.  With respect to your Microsoft/ASP
comment below, most ASP pages are written in VBScript (someone correct me if
I'm wrong), for which there is Windows Scripting Host.  I don't know about
.NET, though.

Your suggestion would be simpler than mine, and would generally make things
easier on API porters.  My thought on having just one tool for doing all the
testing for all the languages we support is that maintaining that tool and
the test cases would require less overhead, and would provide greater
consistency across the languages.

> ./testSuite --lang=java -f tests/xssTests.xml ?
>
> The test suite application doesn't have to run everything, only what we
> tell it so people who aren't developing on other languages don't need to
> install anything extra, other than the languages they are using and of
> course the language that the test suite is written (which is why perl
> would probably be best, its available on most major unix distributions
> and I hear ActiveState Java is pretty decent).  Besides, I would think
> that we would want to package up the tools for each language for
> individual distribution.  ( I don't need the java filters for my php
> applications).

An excellent point.  It's just that I'm not a very good Perl hacker.  :-)
Most developers hate writing tests (or comments or documentation), and I
love writing all three, so I thought I could help there.

On the flip side, it means we won't have one testing framework, we'll have
one for every language we support, which could become a maintenance burden.

> AND DAMMIT.  I just realized that my test application idea breaks down
> when we throw ASP into the mix.
> (/me mumbles something dirty about Microsoft)

See my comment above about VBScript.

Chris

On Sun, 2002-08-18 at 16:54, Alex Russell wrote:
> On Sun, 18 Aug 2002, Christopher Todd wrote:
> 
> > Hello all,
> > 
> > I've been working on an automated tool for unit testing the Filters API.
> > The purpose of the tool is to validate that the API functions/methods
> > perform as expected.  Before I put much more effort into it, though, I
> > wanted to ask the group a few questions.
> > 
> > 1)  Will this be helpful and/or valuable?
> 
> Yes. Incredibly so.

Yes, yes, yes.  Tests are a good idea in any project, this one is no
exception.  The problem will be coming up with enough different cases to
cover as many methods of "attack" as possible.  

>  
> > 2)  I was planning on building the tool around Ant, a Java/XML based build
> > tool, and HTTPUnit, a web application unit testing tool.  You won't need to
> > know Java to construct test cases, just a little XML.  But for those of you
> > developing the ASP, Perl or PHP ports of the API, would you be annoyed about
> > having to install Java and Ant on your development boxes?
> 
> I think that any test environment is going to necessarialy be slightly 
> complex (involved a web server, correctly configured languages, etc...),
> so I don't (personally) feel that Java/Ant is a problem. If anyone is
> dead set against it, speak up now = )
I don't see why a web server is necessary to test these cases?  Our
filters are for filtering input.  While OWASP is geared towards web
applications, I don't see why someone couldn't use these filters in
other applications.  

We could write a test suite application in an appropriate language (I'm
thinking perl) that could invoke a simple application written in each
language that filters test data by a supplied filter, this simple app
then returns the filtered data to the test suite application which
determines if the output is correct.  This can be easily run after each
build.

As far as Java/Ant is concerned, I don't know.  I've never used it
myself, but I am willing to learn.  I really don't see this being a big
problem with the scripting languages since nothing special should need
to be done on a build.
> 
> > 3)  I was planning on having the tool create .jsp, .asp., .php, etc. files
> > that take the specified input and run it through the Filter API
> > functions/methods, but this requires deploying those pages in a working web
> > server environment.  May I safely assume that everyone working on the
> > various languages will have access to such a setup?

> 
> Probably not. I think it'll be a better bet to find one environment
> against which we can test most of these languages and then spit back
> reports about what succeeded and what failed. Not sure there's a need
> for each of us to configure servers to support all (or even most) of
> these languages. It can only get more complex when we introduce DBs into
> the mix, so for the time being I'm going to advocate a central testing
> setup of some sort. Not sure how we'll make it a reality (suggestions
> welcome), but it seems a good way to start.

./testSuite --lang=java -f tests/xssTests.xml ? 

The test suite application doesn't have to run everything, only what we
tell it so people who aren't developing on other languages don't need to
install anything extra, other than the languages they are using and of
course the language that the test suite is written (which is why perl
would probably be best, its available on most major unix distributions
and I hear ActiveState Java is pretty decent).  Besides, I would think
that we would want to package up the tools for each language for
individual distribution.  ( I don't need the java filters for my php
applications).
> 
> > And finally, just out of curiosity, what development platforms is everyone
> > using?  I use Emacs on Linux, Win98 and Win2k.  I have access to Apache
> > (w/Perl & PHP) on Linux, Tomcat on any platform, and IIS 5.
> 
> I've got access to Apache on Linux and OpenBSD supporting  Python, PHP, 
> Tomcat/JSP, and Perl.
> 
> For editing I use vim with 8-space tabs, and tabs-as-tabs (no auto-space
> insertion).

I develop on Linux, using vim.  I have Apache with perl/mod_perl, php,
python, mod_python, yadda, yadda, yadda..  I can install anything else I
need.

AND DAMMIT.  I just realized that my test application idea breaks down
when we throw ASP into the mix. 
(/me mumbles something dirty about Microsoft)

-matt

-- 
Matthew Wirges
Developer, CERIAS Incident Response Database
wi...@ce...
Credo quia absurdum est.

On Sun, 18 Aug 2002, Christopher Todd wrote:

> Interesting idea; I was thinking more along the lines of iterative
> code-test-code-test, 

I think that whatever we do, we'll need that capability.

> but your suggestion would work better in an automated
> nightly build type of situation.  

Yeah, I thought of that...Perhaps if there was a set of scripts that (on
demand) made a CVS checkout, tested it, and reported the results
more-or-less instantly?

maybe it'd even take an uploaded source directory tarball and tested
against that...I don't know. I'd like it to be easy for us to use as
part of our development cycle (fireable from a command line?), but I
think a bit of lag might be acceptable.

Thoughts?

-- 
Alex Russell
al...@Se...
al...@ne...

Alex,

>Probably not. I think it'll be a better bet to find one environment
>against which we can test most of these languages and then spit back
>reports about what succeeded and what failed. Not sure there's a need
>for each of us to configure servers to support all (or even most) of
>these languages. It can only get more complex when we introduce DBs into
>the mix, so for the time being I'm going to advocate a central testing
>setup of some sort. Not sure how we'll make it a reality (suggestions
>welcome), but it seems a good way to start.

Interesting idea; I was thinking more along the lines of iterative
code-test-code-test, but your suggestion would work better in an automated
nightly build type of situation.  Sourceforge has compile farms; I don't
know much about them, but maybe we could setup a nightly build from CVS.
The Jakarta projects (and many Apache projects) do that sort of thing, and
there are several tools to help.

Chris

2002	Jan	Feb	Mar (1)	Apr (26)	May	Jun (57)	Jul (22)	Aug (50)	Sep (14)	Oct (9)	Nov (4)	Dec
2003	Jan (3)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

owasp-input-api-developers Mailing List for OWASP Filter Project (Page 2)

owasp-input-api-developers — Developers for OWASP Input API's