Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Java Open Review Project 50

bvc writes "We Launched the Java Open Review Project today. We're reviewing open source Java code all the way from Tomcat down to PetStore looking for bugs and security vulnerabilities. We're using two static analysis tools to do the heavy lifting: the open source tool FindBugs, and the commercial tool Fortify SCA. We can use plenty of human eyes to help sort through the results. We're also soliciting ideas for which projects we should be reviewing next. Please help!"
This discussion has been archived. No new comments can be posted.

Java Open Review Project

Comments Filter:
  • Wow (Score:5, Funny)

    by xenocide2 ( 231786 ) on Tuesday December 12, 2006 @10:43PM (#17218492) Homepage
    You'd think someone asking for community participation would go to the effort of including a link to the community in question. Somehow, I think you'll get out of this request what you put into it.
  • FYI (Score:3, Informative)

    by guitaristx ( 791223 ) on Tuesday December 12, 2006 @10:49PM (#17218540) Journal
    Link to the project's homepage [fortifysoftware.com]
  • Why so broad? (Score:3, Interesting)

    by kevin_conaway ( 585204 ) on Tuesday December 12, 2006 @10:50PM (#17218544) Homepage

    Why so many projects?

    Why not pick one or two and really run them through the wringer? Most of the heavily used projects like Tomcat have already been viewed by thousands of eyes so a cursory overview probably won't be worth the time

    Anyways, good luck

  • by Anonymous Coward
    Static analysis becomes virtually unnecessary when you use a proper, statically-typed language like Haskell, Standard ML or OCaml. Furthermore, the use of garbage collection eliminates many of the buffer overruns that plague C and C++ software. Add in proper unit testing, and you're almost guaranteed to have a rock-solid system, developed very economically and often with extremely clean code.

    While Java is more difficult to exploit, it is still possible to crash an app (say, a servlet container running a maj
    • by Coryoth ( 254751 )

      Static analysis becomes virtually unnecessary when you use a proper, statically-typed language like Haskell, Standard ML or OCaml. Furthermore, the use of garbage collection eliminates many of the buffer overruns that plague C and C++ software. Add in proper unit testing, and you're almost guaranteed to have a rock-solid system, developed very economically and often with extremely clean code.

      As nice as that is it runs into the difficulty that there are already millions of lines of code in Java and rewriting

      • by Raenex ( 947668 )
        Seems like JML & friends still don't support Java 1.5 yet, and now 1.6 is out. I've seen you mention this quite some time ago, but I write all my code in 1.5. Do you know if they are they working on 1.5?
        • by Coryoth ( 254751 )
          Support for a.5 is in the works apparently, though it is the next major version of ESC/Java that will have it, so I don't know how soon that will come out. It is, at the least, in the works.
    • While Java is more difficult to exploit, it is still possible to crash an app (say, a servlet container running a major web site) by sending data in such a way that an array's capacity is exceeded.

      You can't crash a Java App Server with just an ArrayIndexOutOfBoundsException. It will produce an error for that user, sure, but it won't propogate any farther than that. Read the specs sometime. The servlet container is responsible for trapping all exceptions thrown by the servlet, then dealing with them in an appropriate manner. Usually that means giving the user an HTTP 500 error.
      • Usually that means giving the user an HTTP 500 error

        Which, in webapp speak, is a crash... Yes it won't kill the server since the exception has been handled before that but if your index page dies with an HTTP 500 error it's exactly the same thing for the user : "Website doesn't work".
        • Which, in webapp speak, is a crash..

          No, it's an error. A crash would be if the server went down.

          it's exactly the same thing for the user : "Website doesn't work".

          Considering that the GPs point was that the user was trying to break it, I don't see what your complaint is. The server shrugs off the error and keeps chugging along.
    • If a langauge will not let you commit security vilolations through design, then I can say with surity that language is not usable.

      Note I am NOT saying Haskell is unusable. What I am saying is that in all the languages you list, it is still possible to create code that by design will be insecure. Any time you take input from a user, and place that input into a database for example, you have an avenue for attack.

      As for the suggestion to use an ArrayList instead of basic arrays in Java, it makes me sudder to
      • by MythMoth ( 73648 )
        As for the suggestion to use an ArrayList instead of basic arrays in Java, it makes me sudder to think of you designing any web systems that may be touched by a high volume of traffic

        Then it makes me shudder to think of the design atrocities you're going to commit if by default you use arrays. Use arrays (maybe) if and only if you have established that they are required to solve a proven performance problem. Using them on the offchance that they'll be needed is the height of premature optimisation folly.
  • Whoever the heck is kdawson, he certainly does not sound like he is from the many-eyeballs dept.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...