Menu
▾
▴
owasp-input-api-developers — Developers for OWASP Input API's
You can subscribe to this list here.
| 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
|
|
From: Alex R. <al...@se...> - 2002-08-18 21:54:27
|
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. > 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 = ) > 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. > 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). -- Alex Russell al...@Se... al...@ne... |
|
From: Christopher T. <ch...@ch...> - 2002-08-18 21:40:50
|
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? 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? 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? 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. Chris |
|
From: Mark C. <ma...@cu...> - 2002-08-18 14:13:18
|
Gents The amount of votes last week was dissapointing to say the least. I know = we have had several false starts to this project (and I apolgize for not = being more on top of things) but the vote was an attempt to make sure = everyone was in sync and ready to start. If you didn't vote I will = remove you from the list as I can only assume you have lost interest, = unless I hear from you. As I didn't hear from the tech lead, I have nominated a replacement and = he has kindly accepted. Alex Russell and I have met in person and I am = confident Alex will ensure this project now gets off the ground.=20 I am off on vacation for a few weeks so over to Alex and Gabe to get = this puppy on the road. Thanks guys ! Mark |
|
From: Alex R. <al...@se...> - 2002-08-15 15:05:00
|
Ok, quick tally: Gabe: "yes" Matt: "yes" Nik: "yes" Chris: "yes" Alex: "yes" Steve: "yes" John: "yes" Todd: n/a Nathan: n/a Am I missing anyone? -- Alex Russell al...@Se... al...@ne... |
|
From: Nik C. <ni...@ni...> - 2002-08-15 12:09:16
|
Gets my vote. - good to see that 'block by default' made it - I can help out on the canonicalization routines, as well as PHP and C implelentations - for the PHP implementation, could this be part of PEAR? (http://pear.php.net), using the PEAR coding standards. - for the c implementation, i assume that it would just be a library that can be linked, how popular is C/C++ with webapps now anyway? on another note, will there be another online meeting soon? -Nik On Tue, 13 Aug 2002, Alex Russell wrote: > See attached DocBook file (I'll leave it to you to run it through your > favorite style sheets). I'm sure it's still chock-full of > spelling/grammar errors, but the important thing here is the content. > > Is this version sufficiently cleaned up that we can bring it to a vote by > tomorrow afternoon? > > -- > Alex Russell > al...@Se... > al...@ne... > |
|
From: Steven J. S. <sj...@Ju...> - 2002-08-15 02:44:53
|
On Mon, 12 Aug 2002, John Percival wrote: > I just had a read through, and that doc looks clear and informative. The > only thing that I would question, without wanting to open a can of worms, is > the choice not to develop for DCOM/.NET technology. I am not in a position > to create such filters, but is it our position to judge what language our > 'customers' will be using? I think .NET wide-spread adoption is not here yet, but DCOM would be a good idea. It's braindead simple to create a DCOM component. It can be done quickly and easily in VB... Other than that, the doc looks good to me. -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH |
|
From: Alex R. <al...@se...> - 2002-08-14 19:03:18
|
On Wed, 14 Aug 2002 Chr...@ey... wrote: > +1 on version 1.0.2. Sorry if I ruffled any feathers with my anal > retentiveness. I'll try to be less annoying in the future. :-) No, you weren't annoying. You got me motivated enough to do something about your comments, which is a Good Thing (TM). = ) I'm glad the new version meets with your approval, and I look forward to your spelling/grammar patches. > I am going to try not to use my work email account for OWASP > communications because Lotus Notes seems to automatically send out HTML > emails (which I know everyone dislikes), and unfortunately, I do not have > access to my home email from work. We can probably live with it, it's just good to know that it's not your fault = ) -- Alex Russell al...@Se... al...@ne... |
|
From: <Chr...@ey...> - 2002-08-14 18:51:23
|
+1 on version 1.0.2. Sorry if I ruffled any feathers with my anal retentiveness. I'll try to be less annoying in the future. :-) I am going to try not to use my work email account for OWASP communications because Lotus Notes seems to automatically send out HTML emails (which I know everyone dislikes), and unfortunately, I do not have access to my home email from work. So in the future, I will do most of my OWASP communications in the evenings and on weekends. Chris ________________________________________________________________________ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP |
|
From: Alex R. <al...@se...> - 2002-08-14 18:25:29
|
On Wed, 14 Aug 2002, Mark Curphey wrote: > Gents, > > Its Weds morning and Friday 5pm Pacific is the deadline. Remeber no votes > then its as the document states. So far I have only seen John who has > appoved things but raised a question about support for MS technology. That language has been removed from 1.0.2. Matt already signaled his "yes" vote to the list, and I am an implicit "yes". Still waiting to hear back from Chris as to whether the new DocBook version is acceptable to him. Anybody I missed? -- Alex Russell al...@Se... al...@ne... |
|
From: Mark C. <ma...@cu...> - 2002-08-14 16:53:20
|
Gents, Its Weds morning and Friday 5pm Pacific is the deadline. Remeber no votes then its as the document states. So far I have only seen John who has appoved things but raised a question about support for MS technology. ----- Original Message ----- From: "Alex Russell" <al...@se...> To: <owa...@so...> Cc: "Mark Curphey" <ma...@cu...> Sent: Tuesday, August 13, 2002 9:48 AM Subject: VisionDoc 1.0.2 > See attached DocBook file (I'll leave it to you to run it through your > favorite style sheets). I'm sure it's still chock-full of > spelling/grammar errors, but the important thing here is the content. > > Is this version sufficiently cleaned up that we can bring it to a vote by > tomorrow afternoon? > > -- > Alex Russell > al...@Se... > al...@ne... > |
|
From: Alex R. <al...@se...> - 2002-08-13 16:48:31
|
See attached DocBook file (I'll leave it to you to run it through your favorite style sheets). I'm sure it's still chock-full of spelling/grammar errors, but the important thing here is the content. Is this version sufficiently cleaned up that we can bring it to a vote by tomorrow afternoon? -- Alex Russell al...@Se... al...@ne... |
|
From: Alex R. <al...@ne...> - 2002-08-13 06:41:03
|
> From: Christopher Todd <ch...@ch...> > To: owa...@so... > Subject: RE: [Owasp-input-api-developers] Vision Document > Date: 12 Aug 2002 23:26:39 -0400 > > If we are going to be voting Apache style (which I support), then I wou= ld > have vote -1 for this version of the doc for the following reasons (oth= er > than the specifics below, however, I think it is a good start): > > 1) In Word format. The document states that changes can be made by > submitting diffs to the document. How do you do that with a Word doc? = For > consistency with the stated goal of the rest of the OWASP project, it > should be in DocBook format (I volunteer to convert it - I'll try to do > that this weekend). the original document was a plain-text doc. Mark was kind enough to give = it=20 some more formalized structure, which it was converted to a Word doc. As = most=20 everyone knows, I'm as little of a MS word fan as the next guy, although = I=20 find this not to be a legitimate objection. We're voting on the contents,= not=20 the formatting. I'll convert it to docbook, keep everyone happy. blah. > 2) I strongly disagree with the statement: "We will NOT develop for a= ny > proprietary technologies such as Microsoft .NET or Microsoft DCOM in an= y > shape or form." Since when is Java *not* a proprietary technology? > Furthermore, what you are saying with this statement is that MS coders > don't deserve tools to help them make their web apps more secure, which= is > preposterous. They need tools like the Filters API even worse than fol= ks > who use Java. To preclude any programming language would be irresponsi= ble. See my comments earlier in the day. Don't feel like re-typing it all. Bas= ic=20 upshot of it is that I don't have a problem removing that language, but I= 'm=20 not going to vote in favor of specifying ASP/.NOT as a target platform fo= r an=20 initial release. > On the other hand, this is an open source software project, so if none = of > us feels like porting the API to .NET or whatever, then so be it. :-) > > 3) What is meant by "correctly 'Huffman Encoded' interfaces"? This is= n't > an objection so much as a point of clarification - maybe I'm a total > ignoramus, but I usually assume that if I don't know what something mea= ns, > I'm probably not the only one. I'll change it to read something along the lines of "easy to use and deve= lop=20 with API naming conventions". The idea behind Huffman encoding is that if= you=20 sort based on the frequency of a substring, you can represent things in t= heir=20 most efficient way. Basically, what I was trying to say is that things th= at=20 get used all the time should have shorter names or shortcuts, and things = that=20 are rarer should use more obvious (but longer) naming conventions. > 4) I am not sure I understand the whole boundary filter idea. I don't > necessarily want to re-hash something that's already been discussed, bu= t if > someone could provide a simple description or example, I'd appreciate i= t.=20 > I know what boundary checking is, I'm just not sure you're talking abou= t > the same thing. No, it's not the same thing. The primary contention behind this Vision Doc is that very often we get=20 filtering wrong because we try to predict uses of data far in advance of = it's=20 actual end-use. Instead of trying to filter at a single point in a system= and=20 then try to worry about every class of attack that might exist at various= =20 stages in the processing of that data, we instead will define filters bas= ed=20 on the inflow/outflow locations of data in the program, and will deal wit= h=20 threats as they are present _at that boundary_. We won't try to block SQL= =20 injection attacks in places other than just before we insert the data int= o a=20 SQL statement, etc... This model of filtering will give us a greater chance of getting it right= more=20 of the time, and will help to decrease the effect that environment drift = will=20 place on the system, as assumptions made at a boundary won't be invalidat= ed=20 simply because the data is now used in another context. Rather, we simply= =20 filter for that new context before we output it there. > 5) I think we will need to consider a wider character set than UTF-8, = for > I18N reasons. This may present a porting challenge, as different langu= ages > have differing levels of support for Unicode (just to cite one possible > encoding). I didn't suggest that we should use ONLY UTF-8, but rather that it was a = sane=20 default. Rather, what I said is that all data MUST be reduced to a target= =20 character set (of the developer's choice) before any filtering can begin,= =20 otherwise we're just spitting in the wind. > 6) There are numerous typos and grammatical errors that I'll try to fi= x > when I convert this to DocBook this weekend. I'll get it in docbook tomorrow, and then you can submit diff's to your h= earts=20 content. --=20 Alex Russell al...@Se... al...@ne... |
|
From: Matt W. <wi...@ce...> - 2002-08-13 04:03:18
|
On Mon, 2002-08-12 at 22:26, Christopher Todd wrote: [...] > 3) What is meant by "correctly 'Huffman Encoded' interfaces"? This isn't > an objection so much as a point of clarification - maybe I'm a total > ignoramus, but I ususally assume that if I don't know what something means, > I'm probably not the only one. While I know what Huffman Encoding is, wrt text compression, I too fail to understand what "correctly 'Huffman Encoded' interfaces" really means. > > 4) I am not sure I understand the whole boundary filter idea. I don't > necessarily want to re-hash something that's already been discussed, but if > someone could provide a simple description or example, I'd appreciate it. I > know what boundary checking is, I'm just not sure you're talking about the > same thing. The boundary idea is pretty simple. Its basically deciding when you need to filter the data. For example, filtering SQL injection is something you would want to do on input, when the user sends there data. However, filtering XSS might be something you wish to do when displaying said data. > > 5) I think we will need to consider a wider character set than UTF-8, for > I18N reasons. This may present a porting challenge, as different languages > have differing levels of support for Unicode (just to cite one possible > encoding). Bah. > > 6) There are numerous typos and grammatical errors that I'll try to fix > when I convert this to DocBook this weekend. Here we go again :> -matt -- Matthew Wirges Developer, CERIAS Incident Response Database wi...@ce... |
|
From: Christopher T. <ch...@ch...> - 2002-08-13 03:36:02
|
If we are going to be voting Apache style (which I support), then I would have vote -1 for this version of the doc for the following reasons (other than the specifics below, however, I think it is a good start): 1) In Word format. The document states that changes can be made by submitting diffs to the document. How do you do that with a Word doc? For consistency with the stated goal of the rest of the OWASP project, it should be in DocBook format (I volunteer to convert it - I'll try to do that this weekend). 2) I strongly disagree with the statement: "We will NOT develop for any proprietary technologies such as Microsoft .NET or Microsoft DCOM in any shape or form." Since when is Java *not* a proprietary technology? Furthermore, what you are saying with this statement is that MS coders don't deserve tools to help them make their web apps more secure, which is preposterous. They need tools like the Filters API even worse than folks who use Java. To preclude any programming language would be irresponsible. On the other hand, this is an open source software project, so if none of us feels like porting the API to .NET or whatever, then so be it. :-) 3) What is meant by "correctly 'Huffman Encoded' interfaces"? This isn't an objection so much as a point of clarification - maybe I'm a total ignoramus, but I ususally assume that if I don't know what something means, I'm probably not the only one. 4) I am not sure I understand the whole boundary filter idea. I don't necessarily want to re-hash something that's already been discussed, but if someone could provide a simple description or example, I'd appreciate it. I know what boundary checking is, I'm just not sure you're talking about the same thing. 5) I think we will need to consider a wider character set than UTF-8, for I18N reasons. This may present a porting challenge, as different languages have differing levels of support for Unicode (just to cite one possible encoding). 6) There are numerous typos and grammatical errors that I'll try to fix when I convert this to DocBook this weekend. Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Alex Russell Sent: Monday, August 12, 2002 1:06 PM To: owa...@so... Cc: Mark Curphey Subject: [Owasp-input-api-developers] Vision Document Hey Everyone, After much discussion, the project is now (apparently) stalled. To combat this, Mark Curphey and I have drafted a "vision document" to outline the purpose of the project and our preferred approach to development. You'll find the document attached for your review. Gabe or Mark should be announcing a vote on the document soon, so it'd be good if everyone were familiar with it's contents before we vote to adopt it. Thanks, Alex -- Alex Russell al...@Se... al...@ne... |
|
From: Christopher T. <ch...@ch...> - 2002-08-13 03:08:19
|
If we're going to use the Apache system of voting, then a reasonable question to ask would be "Who gets to vote?", or more accurately, who gets veto rights. And for those of you not familiar with the Apache system, -1's need to be justified with arguments as to why the proposal/code/patch/whatever is insufficient. Regards, Chris -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Mark Curphey Sent: Monday, August 12, 2002 6:21 PM To: John Percival; Alex Russell; owa...@so... Cc: Mark Curphey Subject: RE: [Owasp-input-api-developers] Vision Document Good deal. Looks like the first vote for yes. What I was talking to Gabe and Alex about is using the doc as THE vision for the project and everyone having a vote before the end of this biz week (5pm Friday Pacific Time) so we can move on and get a release done. The OWASP portal is being built using UPortal so we need this ;-) It seems to (me anyway) make sense that if there are things you think are missing or its not what you think we should be doing, then please append the issue as a voting item and send them out to Gabe before Wednesday. Gabe can send out a list of all the items people feel need to be voted on on Thursday and we can tally votes by Friday night. I suggest we use the Apache system or a +1, 0 or -1 for each item and add the total. If you don't vote it don't count so be warned. Mine is for +1 on the vision document as it stands with no alterations. I think it sums up what the project is trying to do and needs to do, even if it is somewhat off from what has been done to date. Cheers ---- John Percival <joh...@je...> wrote: > Hi guys, > > I just had a read through, and that doc looks clear and informative. The > only thing that I would question, without wanting to open a can of worms, is > the choice not to develop for DCOM/.NET technology. I am not in a position > to create such filters, but is it our position to judge what language our > 'customers' will be using? > > On the whole though, good work! > > John > > > -----Original Message----- > > From: owasp-input-api-developers- ad...@li... > > [mailto:owasp-input-api-developers- ad...@li...]On Behalf > > Of Alex Russell > > Sent: 12 August 2002 18:06 > > To: owa...@so... > > Cc: Mark Curphey > > Subject: [Owasp-input-api-developers] Vision Document > > > > > > Hey Everyone, > > > > After much discussion, the project is now (apparently) stalled. To > > combat this, Mark Curphey and I have drafted a "vision document" to > > outline the purpose of the project and our preferred approach to > > development. > > > > You'll find the document attached for your review. Gabe or Mark should > > be announcing a vote on the document soon, so it'd be good if everyone > > were familiar with it's contents before we vote to adopt it. > > > > Thanks, > > > > Alex > > > > -- > > Alex Russell > > al...@Se... > > al...@ne... > > > > > ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: Christopher T. <ch...@ch...> - 2002-08-13 03:05:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, My name is Chris Todd, and I have been lurking on this list for some time, even putting in my two cents from time to time. I have not yet made any real contributions because I was working out some IP rights and confidentiality agreement issues with my employer. Now that I have that mess all squared away, I am eager to contribute to the Filters API. I am currently a security consultant for Ernst & Young, where I have performed quite a few web application audits, both from a black box and white box perspective, including source code level reviews. I've done other work at EY, but most of it has no relevance to this group (PKI, security policy development, and LDAP stuff). Prior to joining EY, I was a web applications developer for Alabanza Corporation, a website hosting company, where I wrote Perl and PHP scripts that helped automate the tasks associated with administering a Linux/Apache/MySQL/Perl/PHP-based web server. I was working on a team to help port all of that code to JSPs and servlets when I was laid off in a typical dot com story. Despite the work I did in Perl and PHP, I consider Java my strongest programming language. I have no experience with C, C++, Python, .NET, or Cold Fusion. I have a teeny tiny little bit of experience with VBScript for doing Active Server Pages. My motivation for working on the Filters API is that I am getting sick and tired of seeing web app developers make the same mistakes over and over again, either through ignorance or apathy. I want to be able to perform a web app audit, and when I see that they don't filter user input (I have yet to review a web app that does), I can point to the Filters API and say "There, go use that!" :-) While I would love to help write the Java port of the Filters API, I suspect we will have more than enough Java programmers to get the job done. I am not terribly confident that my Perl and PHP skills are up to the task of working on those ports, but I'm more than willing to give it a shot. Where I think I can make a strong contribution, however, is in the department of documentation and testing. I would be more than happy to help document the Filters API, and I am already well on my way to creating a simple to use testing suite that will help us validate that the Filters API actually works the way we expect it to. I hope to submit some beta code for that sometime soon (maybe by the end of this weekend, depending on family commitments). I look forward to working with you all, Chris -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPVh1Kw1yj8e2/NpyEQIQzQCgteYiXFuWFPoiIfljPuTTo4Xaz8wAniP5 LUgvO8wRIteXlFTvqYB9yVJQ =mE7j -----END PGP SIGNATURE----- |
|
From: Matthew W. <wi...@ce...> - 2002-08-12 23:48:40
|
On Mon, 12 Aug 2002 17:02:56 -0500 (CDT) Alex Russell <al...@se...> wrote: > On Mon, 12 Aug 2002, John Percival wrote: > > > Hi guys, > > > > I just had a read through, and that doc looks clear and informative. The > > only thing that I would question, without wanting to open a can of worms, is > > the choice not to develop for DCOM/.NET technology. I am not in a position > > to create such filters, but is it our position to judge what language our > > 'customers' will be using? > > No, and perhaps doing a VBScript/D-flat verion is worth considering. > That said, developers using MS tech are starting from an inherently > disadvantaged position WRT to security (IIS, MSSQL, etc..), and probably > have bigger problems. > > I think we can safely say that we won't refuse a contributed MS-tech > version of the filters once we have them working in a reference > language, but I for one won't be spending much (any?) time on that port > as I simply don't have any MS software to develop against. Perhaps when > Mono goes gold... Completely agreed. If there is a developer who wants to contribute a VBD/Db I say more power to them, but I can't see myself spending any appreciable amount of time developing on/for this platform. (Hey, I had to play with ISS's Internet Scanner and almost went out of my mind -- go Nessus!) In the end, I suppose its not fair to rule out these languages based on their vendor or said vendor's intentions, but as Alex said, anyone developing for this platform using these tools probably has more to worry about. (Though the latest OpenSSL escapade doesn't say much for us, other than turn-around time on patches.. :->) > > Additionally, providing filters for MS languages, while undeniably > necessaray, almost condones their use for security-critical applications, > and I think that if we ever do ship such a port, we should point out to > developers the insecure posture that relying upon a vendor like MS > inherently creates. I wish I would have read this paragraph before writing all of that up there :-) > > Should we grease the squeaky wheel? I don't have a strong opinion one way > or the other, save that for the time being I'm "out" when it comes to > developing such a port. > This document, though, is most definitely on the write track (save the fact that its not in PDF or PS, but rather MSWord -- Thanks OpenOffice!). In short, I've a "Yes" vote. -matt |
|
From: Mark C. <ma...@cu...> - 2002-08-12 22:21:47
|
Good deal. Looks like the first vote for yes. What I was talking to Gabe and Alex about is using the doc as THE vision for the project and everyone having a vote before the end of this biz week (5pm Friday Pacific Time) so we can move on and get a release done. The OWASP portal is being built using UPortal so we need this ;-) It seems to (me anyway) make sense that if there are things you think are missing or its not what you think we should be doing, then please append the issue as a voting item and send them out to Gabe before Wednesday. Gabe can send out a list of all the items people feel need to be voted on on Thursday and we can tally votes by Friday night. I suggest we use the Apache system or a +1, 0 or -1 for each item and add the total. If you don't vote it don't count so be warned. Mine is for +1 on the vision document as it stands with no alterations. I think it sums up what the project is trying to do and needs to do, even if it is somewhat off from what has been done to date. Cheers ---- John Percival <joh...@je...> wrote: > Hi guys, > > I just had a read through, and that doc looks clear and informative. The > only thing that I would question, without wanting to open a can of worms, is > the choice not to develop for DCOM/.NET technology. I am not in a position > to create such filters, but is it our position to judge what language our > 'customers' will be using? > > On the whole though, good work! > > John > > > -----Original Message----- > > From: owasp-input-api-developers- ad...@li... > > [mailto:owasp-input-api-developers- ad...@li...]On Behalf > > Of Alex Russell > > Sent: 12 August 2002 18:06 > > To: owa...@so... > > Cc: Mark Curphey > > Subject: [Owasp-input-api-developers] Vision Document > > > > > > Hey Everyone, > > > > After much discussion, the project is now (apparently) stalled. To > > combat this, Mark Curphey and I have drafted a "vision document" to > > outline the purpose of the project and our preferred approach to > > development. > > > > You'll find the document attached for your review. Gabe or Mark should > > be announcing a vote on the document soon, so it'd be good if everyone > > were familiar with it's contents before we vote to adopt it. > > > > Thanks, > > > > Alex > > > > -- > > Alex Russell > > al...@Se... > > al...@ne... > > > > > |
|
From: Alex R. <al...@se...> - 2002-08-12 22:02:36
|
On Mon, 12 Aug 2002, John Percival wrote: > Hi guys, > > I just had a read through, and that doc looks clear and informative. The > only thing that I would question, without wanting to open a can of worms, is > the choice not to develop for DCOM/.NET technology. I am not in a position > to create such filters, but is it our position to judge what language our > 'customers' will be using? No, and perhaps doing a VBScript/D-flat verion is worth considering. That said, developers using MS tech are starting from an inherently disadvantaged position WRT to security (IIS, MSSQL, etc..), and probably have bigger problems. I think we can safely say that we won't refuse a contributed MS-tech version of the filters once we have them working in a reference language, but I for one won't be spending much (any?) time on that port as I simply don't have any MS software to develop against. Perhaps when Mono goes gold... Additionally, providing filters for MS languages, while undeniably necessaray, almost condones their use for security-critical applications, and I think that if we ever do ship such a port, we should point out to developers the insecure posture that relying upon a vendor like MS inherently creates. Should we grease the squeaky wheel? I don't have a strong opinion one way or the other, save that for the time being I'm "out" when it comes to developing such a port. -- Alex Russell al...@Se... al...@ne... |
|
From: John P. <joh...@je...> - 2002-08-12 21:45:52
|
Hi guys, I just had a read through, and that doc looks clear and informative. The only thing that I would question, without wanting to open a can of worms, is the choice not to develop for DCOM/.NET technology. I am not in a position to create such filters, but is it our position to judge what language our 'customers' will be using? On the whole though, good work! John > -----Original Message----- > From: owa...@li... > [mailto:owa...@li...]On Behalf > Of Alex Russell > Sent: 12 August 2002 18:06 > To: owa...@so... > Cc: Mark Curphey > Subject: [Owasp-input-api-developers] Vision Document > > > Hey Everyone, > > After much discussion, the project is now (apparently) stalled. To > combat this, Mark Curphey and I have drafted a "vision document" to > outline the purpose of the project and our preferred approach to > development. > > You'll find the document attached for your review. Gabe or Mark should > be announcing a vote on the document soon, so it'd be good if everyone > were familiar with it's contents before we vote to adopt it. > > Thanks, > > Alex > > -- > Alex Russell > al...@Se... > al...@ne... > |
|
From: Alex R. <al...@se...> - 2002-08-12 17:05:19
|
Hey Everyone, After much discussion, the project is now (apparently) stalled. To combat this, Mark Curphey and I have drafted a "vision document" to outline the purpose of the project and our preferred approach to development. You'll find the document attached for your review. Gabe or Mark should be announcing a vote on the document soon, so it'd be good if everyone were familiar with it's contents before we vote to adopt it. Thanks, Alex -- Alex Russell al...@Se... al...@ne... |
|
From: Steven J. S. <sj...@Ju...> - 2002-08-11 02:42:44
|
On Wed, 7 Aug 2002, Steven J. Sobol wrote: > > > Thanks. > > > > <?php > > $data = utf8_encode($_SERVER['data']); > > ?> > > Looks like it requires XML support... I do know enough about extending PHP to be able to yank those functions and place them into a dynamically loaded PHP extension, though. What I really want to find is a pointer to a COM object that'll do the same for ASP. If someone knows of one, lemme know. Otherwise I'll search for one, and post here when I find it. -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH |
|
From: Steven J. S. <sj...@Ju...> - 2002-08-07 17:00:15
|
On Wed, 7 Aug 2002, Matt Wirges wrote: > > > > Thanks. > > <?php > $data = utf8_encode($_SERVER['data']); > ?> Looks like it requires XML support... -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH |
|
From: Matt W. <wi...@ce...> - 2002-08-07 15:56:30
|
On Wednesday 07 August 2002 10:49, Steven J. Sobol wrote: > On Thu, 8 Aug 2002, Nik Cubrilovic wrote: > > convert allowed non A-Z,a-z,0-9 charcters to their UTF-8 equivs and s= tore > > them in that format. > > Hm. > > That will work. > > I don't feel comfortable writing PHP/ASP code, so I'm going to look > for UTF-8 conversion functions. The snippet of C you pointed to is a go= od > start. I think PHP has built-in UTF-8 functionality, but I'm not sure > about VBScript. > > Thanks. <?php =09$data =3D utf8_encode($_SERVER['data']); ?> www.php.net/utf8_encode -matt |
|
From: Steven J. S. <sj...@Ju...> - 2002-08-07 15:49:49
|
On Thu, 8 Aug 2002, Nik Cubrilovic wrote: > convert allowed non A-Z,a-z,0-9 charcters to their UTF-8 equivs and store > them in that format. Hm. That will work. I don't feel comfortable writing PHP/ASP code, so I'm going to look for UTF-8 conversion functions. The snippet of C you pointed to is a good start. I think PHP has built-in UTF-8 functionality, but I'm not sure about VBScript. Thanks. -- Steve Sobol, CTO JustThe.net LLC, Mentor On The Lake, OH |
1 message has been excluded from this view by a project administrator.
