Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:But Java is secure! (Score 1) 66

out of interest why does free not null out the pointer

Well, C's free() is a library function, so it only gets a pointed-to value, not the actual pointer itself. But if free() could magically null the pointer, would that solve your problem? Your program could have other copies of the pointer that free() wouldn't know about; those would still be dangerous.

Java's GC fixes this problem by freeing memory only when it knows no object references point to it.

Comment Re:But Java is secure! (Score 5, Insightful) 66

Doesn't anyone remember that when Java first came out that it was marketed as a secure alternative to C and C++? Proponents claimed that Java got the security model right, and that we could all just get down to solving the problems at hand, rather than having to worry about writing insecure code.

Agreed. Java did get some things right. When was the last time someone took advantage of a buffer overflow in a Java program? (I'm talking about the Java language here, not about vulnerabilities in particular implementations of Java.) The fact that it garbage-collects memory for you is not only convenient, but closes off a whole class of vulerabilities like double-free, that still plague C/C++ programmers.

On top of that, Java provides a standard API for concurrency...standard C and C++ didn't provide any threading model until this year.

And Java provides a framework allowing a program to run hostile code and still maintain control. C has no such capability; if your C program runs hostile code, game over, you're pwned. So I'd say Java did solve some of the biggest problems affecting C...buffer overflows and memory-allocation errors. I'd say that makes Java more secure than C. The problems outlined in the book can mostly be applied to C as well, though you'll have to go outside the standard to do them (eg for multithreaded code).

There are many reasons to use Java, but as this book clearly demonstrates, security is not one of them. The notion that a language automatically provides security is flawed, at best. The best a language can do is provide a mental model which encourages secure coding. The rest is on the programmer.

I'd say that no language provides security, as perfect security is an impossible dream...we can strive for it, and approach it, but never quite reach it. So I'd rather say that Java provides more security than C.

Comment Re:FUCKING ENGLISH, DO YOU SPEAK IT (Score 4, Insightful) 66

a fine balance between enhancing delivery excellence and releasing a software product in consonance with deadlines.

Can I get this translated into English, please? I try to avoid parsing marketroid and/or manager babble. ;)

No, but here is a translation you'll understand:

Project code = getProject();
int softwareQuality = QA.getQuality( code);
Date deadline = Boss.getDeadline();
Date completionDate = estimateRemainingWork( Project.codingQuality);
while (completionDate > deadline) {
    completionDate = estimateRemainingWork( Project.codingQuality);

Comment Re:750 pages? (Score 2) 66

Let me there is too much. Let me sum up.

I've read 1000-page technical books that had no filler (at least none that I could find). They just had a LOT of ground to cover. Sigh. How do you distinguish the books with mostly filler from the books that aren't? You gotta slog through the whole thing. Or you gotta trust that that review you're reading was done by someone who slogged through the whole thing.

Sounds like you want more of a tutorial in the style of K\&R, rather than a reference book like this.

Comment Re:Pretty decent general coding practices (Score 4, Informative) 66

Disclaimer: I'm one of the authors.

Really, what is wanted is a set of books, each for a different required confidence level. This would make an excellent book #1 in the set. Book #2 onwards would need to add to the book before, explaining where a certain methodology simply won't work at the more stringent level and what you replace it with. For example, their compliant solution on page 25 for doPrivilegedAction() is good for a basic level of confidence but has flaws. There's magic numbers (an 8 for the maximum length of a username), the program flow isn't great (check for a maximum length doesn't actually trip an exception), some parameters aren't sanity-checked (the password is passed straight to the hash function without knowing if it meets the size requirements for the function or if there's anything in the string that might break things). It's perfectly good for a basic level of good practice, but I wouldn't consider it adequate for more advanced levels.

I'm not sure what you are referring to on page 25, there is no doPrivileged() block there. But go ahead & contact me with specific criticisms or comments on the rules.

Some of the problems you cite arise from the main purpose of the code examples, which is to be illustrative, rather than to be functional. For example, I'll agree that magic numbers in code are generally a bad idea, and should be replaced with constants. In fact, we considered adding a rule about this to the book, and nixed it because that is purely a maintainability issue, with no direct ramifications to security. (That is, you'd have to work hard to contrive an example where failing to use magic numbers makes your program vulnerable rather than just buggy.)

Using 'magic numbers' also makes the code bigger, and a little harder to read. For code whose purpose is to work properly, this extra code size is no big deal, but when the code's purpose is to serve as an illustration in a book, this bloat is more problematic. If the code has to appear on a PowerPoint slide, this bloat can be critical.

(Having everything in one single book and coding to an insanely high standard is why the DoD's efforts for higher quality code ultimately failed. It had nothing to do the limits of what people can do, it had everything to do with what people have time to do. You need a good baseline and build from it.) The thing that concerns me is that Oracle will probably consider this sufficient for everyone, which it isn't. The standards are not even up to the quality needed by e-Commerce and should not be used directly from this book for that purpose. This is a foundation layer, it isn't the entire edifice.

I suspect the ediface you are imagining is a tower of will never be complete. True security is an impossible dream, that we can asymptotically approach yet never attain. In this book, we tried to focus on the insecure coding practices being made today; we ignored 'theoretical' insecure coding practices that aren't being widely done today. Mainly to keep the project a manageable size :)

Comment Re:What do you think happens today? (Score 2, Insightful) 613

So let me see if I get this straight...

The current system allows a taxpayer to be dishonest, but catches him if he is.

The proposed change prevents a taxpayer from being dishonest (by informing him of what the IRS already knows of his finances), and only gives him a chance to correct the records.

So how is catching taxpayer dishonesty an advantage, again?

Comment Re:Frustrating For Developers (Score 4, Informative) 149

Might I recommend that if you wish to provide a link to an iPhone app, don't link directly to iTunes. Not everyone has iTunes installed on every machine? (Last I checked there was no Linux version.) Instead provide a link to your app via AppBeacon.

For instance: Velocity

They mirror the info iTunes provides, also providing a iTunes link. But that way I can review your app on my linux box and buy it directly, or buy it later on my mac laptop. (No, I don't work for AppBeacon, just a satisfied netizen.)

Comment Re:fake vs genuine (Score 1) 385

For people who have to deal with members of the public on a daily basis, being able to produce a smile that seems genuine may make a difference in how their customers perceive their service.

I can't tell a fake smile from a real one, but I sure can spot the oxymoron in that sentence. So the goal is to present a fake smile that others think is genuine?


Senators To Examine Exclusive Handset Deals 234

narramissic writes "Based on a request that a group of rural operators sent asking the FCC to examine the practice of handset exclusivity, four members of the Commerce Subcommittee on Communications, Technology and the Internet sent a letter to the FCC expressing their concern. Small operators, like U.S. Cellular argue (PDF) that 'exclusive handset contracts divide wireless customers into haves and have nots.' But nationwide operators, including Verizon, maintain (PDF) that 'in the absence of exclusivity agreements, wireless carriers would have less incentive to develop and promote innovative handsets.' The Commerce Committee expects to hold a hearing on the issue tomorrow."

Slashdot Top Deals

Just because he's dead is no reason to lay off work.