clipka wrote:
> It may be interesting news to you that examining compiled piece of software is
> just as easy with open-source software as it is with closed-source software...

Oh, I know that. I was just saying that many might not even look for 
(essentially) compiler errors if they have the source.

> And knowing this particular compiler behavior, the bad guy's job has become a
> whole lot easier with open-source software: Just get a good static
> code-analysis tool and have it grind the code for places where pointers are
> de-referenced without checking for NULL first.

True.  If you think of it.

> So however you toss and turn it: Breaking into any piece of software is easier
> if it's open-source than if it's closed-source.

Yes. Perhaps the word "easier" should have been "more likely."

> Yet how many more could a static code-analysis tool notice? Quite a lot, I bet.

Hopefully, people are running such static analysis tools on their 
proprietary software too. :-)

> Unless the compiler is outright buggy of course, but that would surface sooner
> or later, too.

I understand the good folks at JPL actually *do* disassemble the machine 
code the compiler generated and checks that it does what they think it does. 
When you're sending something to Mars, it's probably worth it.

> Static code analysis
> tools do a great job at identifying the use of such constructs.

Well, not so good, no.  At least, not in C. Otherwise, buffer overruns 
wouldn't be the black hat's attack of choice for C programs.

You can make a language where it's a lot easier to find such things, tho, 
even without a lot of runtime overhead.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message