Forgot your password?
typodupeerror

Comment: Re:Why? (Score 4, Insightful) 2219

by Arslan ibn Da'ud (#46181471) Attached to: Slashdot Tries Something New; Audience Responds!

There are MANY reasons to hate the beta but using Javascript is not one of them

Nonsense! Javascript slows down the browsing experience. Doesn't matter how fast your hardware is; it is always faster without Javascript. Not to mention security issues.

I sure hope someone at Dice is testing beta using lynx! (or links)

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

by Arslan ibn Da'ud (#38225564) Attached to: Book Review: The CERT Oracle Secure Coding Standard For Java

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

by Arslan ibn Da'ud (#38222384) Attached to: Book Review: The CERT Oracle Secure Coding Standard For Java

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

by Arslan ibn Da'ud (#38221848) Attached to: Book Review: The CERT Oracle Secure Coding Standard For Java

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) {
    Project.codingQuality--;
    completionDate = estimateRemainingWork( Project.codingQuality);
}

Comment: Re:750 pages? (Score 2) 66

by Arslan ibn Da'ud (#38221708) Attached to: Book Review: The CERT Oracle Secure Coding Standard For Java

Let me explain...no 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

by Arslan ibn Da'ud (#38221618) Attached to: Book Review: The CERT Oracle Secure Coding Standard For Java
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 babel...it 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

by Arslan ibn Da'ud (#28704421) Attached to: Staying Afloat In a Sea of iPhone Apps

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.)

When the weight of the paperwork equals the weight of the plane, the plane will fly. -- Donald Douglas

Working...