Slashdot Mirror
Oracle Patch Day Becoming Irrelevant
mocirac wak writes "Oracle's scheduled quarterly patch day is becoming more and more irrelevant. Oracle critical patches announced in the April 2006 CPU are still not available for download and the ETA is now set for May 15. The whole idea of a patch day was to let DBAs get prepared for testing and deployment. What's the use of having a patch day when there are no patches to download?" From the article: "... Oracle's explanation that patch testing is not yet done points to serious shortcomings and an absence of a good patch development process. 'For such a big organization with a lot of financial resources, they should be ready to handle this without problems. But they are amateurs on everything security related,' Cerrudo said. 'They spend a lot of time creating these patches. Then, patch day comes around and the patches aren't available. Then, when the patches are finally released, it's normal to find that they are incomplete and fail to address the actual vulnerability,' he added."
Just because they are a large, successful company doesn't mean schedules are solid and sufficient resources are made available. Microsoft is wildly successful, but faces the same problems. World of Warcraft is wildly successful, but faces the same problems. Ultimately, we still have people involved and people make mistakes. People estimate incorrectly. Stuff happens (c).
If you have an alternative and they are able to serve you better, migrate. If not, suck it up and be thankful the mistakes of your vendor give you a well paying job.
Heaven forbid that a company take its time testing a patch to make sure it's up to some level of standard. The poster even pointed out that historically, there've been problems with the patches in the past. Maybe patch day should move to quarterly updates for all but the most extreme patches in order to increate quality.
Anyone involved with software knows that NOTHING gets done on schedule. Smells of a marketing idea that got pushed onto the developers. I mean, it is a good idea...just not very practical.
Blar.
"Oracle promised them on May 1. Now they are saying some will come on May 10 and others will come on May 15. It's clear they are having big problems," Cerrudo said.
He said Oracle's explanation that patch testing is not yet done points to serious shortcomings and an absence of a good patch development process.
"For such a big organization with a lot of financial resources, they should be ready to handle this without problems. But they are amateurs on everything security related," Cerrudo said.
"They spend a lot of time creating these patches. Then, patch day comes around and the patches aren't available. Then, when the patches are finally released, it's normal to find that they are incomplete and fail to address the actual vulnerability," he added.
Oracle has been falling down on the job for years, making it virtually impossible for DBAs to keep up with patches and keep their systems tuned. They hem and haw, obfuscate and prevaricate, and still manage to retain their commanding market share. Sound like anyone else we know?
Again, Oracle should have gotten into the Linux biz 5 years ago -- now it's too late. At this point they should think about cleaning their own house and stay out of the OS business until they have a firm grip on their DB. This constant inability to stay on top of critical problems points a wider, systemic problem that would infect any Linux development program they acquired. Time for Larry Ellison to retire to a tiny island in the Pacific somehwere and let some new blood fix Oracle before it implodes under its own weight and become an IT black hole.
GetOuttaMySpace - The Anti-Social Network
I worked on a big project involving Oracle software and after a lot of research, we decided to only use the core database and write our own interfaces to more reliable, more secure open-source systems. When I discovered how convoluted the company's own product line and support process was, I dumped the stock. It doesn't surprise me one bit that they can't meet deadlines of this nature. The internal structure of the organization from my perspective was always a bloody mess.
Have you seen Oracle's security record recently?
Anyone who reads bugtraq or the like will know it is shocking.
Take a look at http://www.securityfocus.com/archive/1/432399 this for an example
Though their database is their flagship product, they have been way too distracted with their substandard Oracle Applications suite. If they really want to do well, they should focus on what they do best and stop wasting their time trying to push poorly written web applications. (I should know, I have to use their worthless timecard and expense system every week.)
"These aren't random complaints from unhappy researchers," Newman said, referring to the comments from Kornbrust and Cerrudo. "They need to admit their procedures aren't working and seek help getting it fixed."
/. community for help. So what advice can you give to 'Larry'?
This Week on Ask Slashdot...
'Larry' has a company that sells database software and he's trying to get developers to release security patches that are both trouble free and actually fix security holes and other problems...and then finally get them to do all of this on time.
"Microsoft isn't good at security. We're good at that and I don't think sending a memo is going to help," 'Larry' states. Now he's turning to the
What if the Hokey Pokey really is what it's all about?
A lot of big business runs on Oracle. Governments, Banks, Corporations, etc. Rushing out a patch with fatal flaws, exploitable flaws would potentially cause more damage to the word than the worst predictions of Y2K. I am glad that Oracle are thoroughly testing the patches before they roll them out. I know the DBA's will test the patches, but there is no substitute for vendors testing the patches.
"Sure there's porn and piracy on the Web but there's probably a downside too."
I could be missing the point here, and these are minor (yet critical) patches, but if they are, how come they are taking so much time to develop?
Note to self: Stop putting jokes in my insightful comments so I can get something other than +1 Funny!
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
First, patches are inevitable for any application or system. Humans write code and humans make mistakes. Patches are like security incidents; if you think you don't have them (or in the case of patches, don't need them), you aren't looking hard enough. To the comment above about why patches are needed (and to all you "my system is totally secure" Mac-heads out there)...even OpenBSD, with all its code review processes for every release, has security vulnerabilities from time to time (go ahead, look them up). QA/QC process just can't find every little bug before release.
Second, patches for something as critical as Oracle is within most enterprises, MUST be fully examined and qualified. The comment above about being a year or two behind on patches because patches might break stuff, is relevant here. Again, humans write code and humans make mistakes, even on code meant to fix other broken code. Look at Apple's recent patch-to-fix-a-patch-to-fix-a-patch issue from several weeks back. I applaud Oracle for trying to get quality patches out. However, I would say that there comes a point when you just have to feel comfortable with the patch you have and get it out the door. Better to look like you're doing something while you get things together, even if what you do is not ideal, than to look like you're doing nothing and appear incompetent or unresponsive.
Basically...this is not uncommon across the software industry.
Most of the companies are not mature and entrenched with bureocracy. Staff probably turns over twice a year now when a decade ago devoted "well paid" developers worked long hours to make sure a patch or update was ready for release.
Now from my perspective, as a DBA responsible for installing and overseeing the installation of software patches on database and application servers, I can't really say this is happening any longer.
I don't simply patch Oracle becasue they say it's "critical". Updates and patching is only done if needed to keep the applcation going and to keep users working. If the risk of not patching comes into play then we patch.
Unfortunately for us, many software makers they have discovered the joys of consulting fees to bolster fading profit and market share, rather than actually delivering quality service and product to existing customers.
Particulary in smaller software makers. Selling the sizzle and delivering the bacon later is all too common now. And many times you end up with something much less than "bacon".
Anyone who works with canned apps in a large heterogenous IS environment knows what I am talking about.
And "we" the customers are partly to blame for allowing software makers to have thier way with us. I for one refuse to "pay" to vendors develop working patches for their software...there are a thousand and one ways for software vendors to take advantage of clients. It is up to the IT professionals to hold them to contracts and simple concepts like the delivery of software, updates and patches that actually work as claimed.
So it is up to us to demand full documentation, and READ IT. Test the systems completely and be more "critical" of the vendors claims...if you have to be hard ass to do so...so be it.
Lest we forget, Oracle as a database system is exponenetially more complex than Unix itself, and in fact will probably come to include a linux distro before its all over. Oracle is a funny company, they make REALLY REALLY good databases (no... I mean it), but then they go out and release buggy features with holes in em. The truth? Most of these holes are in shit like ONames (the oracle version of computer browser... Let me expand on this a bit, for 8i Onames had a security hole that was fixable by using the ip address instead of UNC names for target boxes. Easy to workaround, and really more of an annoyance). Long story short, Oracle's the BEST at databases, not because they have some great code team somewhere in a closet doing innovative things but because they've been working on the same core product since 1977.
It's the same story each release, Oracle marketing trumpets up the latest and greatest Java Parser! then everyone ignores it and goes back to Listeners (which consequently have very few bugs at this point).
So yeah, patches are important, and yeah I apply em, but with Oracle ONLY (and maybe Solaris) to me this is indeed not a big deal.
chitlenz
Imagination is the silver lining of Intelligence.
I'm an Oracle DBA by trade and was able to patch my test systems running Oracle 9iR2 within days of the scheduled release date.
The article makes it sound like the target date was missed entirely, and while I know there are delays for some releases, others were made available as planned.
Why do I get the feeling that most of the complaining here is by people who don't actually use the product?
How we got this far on the myth that software development can't be controlled is beyond me. Some old fasion project managment will keep any project on track, but we devs have managed to convince the managers that software development can't be estimated. Construct a Skyscraper and it's no problem to have a time line, but code an app... whoa, that has so many issues. Does construction have zero surprises along the way?
The truth of the matter is development is slow from lack of focus, and it starts with us the developers. Put down the damn Ruby on Rails book and focus on the language and tools you are actually using. (you can still do all the ruby you want at home). If ruby makes sense, then the company as a whole will move to it so we can all focus on it, but as long as you "do your own thing" you are part of the problem.
Oracle has the people, the money, and yes - the time. If it's still not working, then they don't have the method. Software development is not a special and unique snowflake - it can be managed like everything else.