Net Data Design, LLC Blog

While there are some that say that a MySQL/InnoDB “monopoly” isn’t healthy in the long run. What is a bit puzzling is the Oracle acquisition of Innobase Oy (the makers of InnoDB) a few years ago. The question in regards to this acquisition is whether Oracle is serious about seeing MySQL grow and prosper, or was that a means to get a strangle-hold on a vital piece of MySQL?

To Oracle’s credit, they have published  a press release stating their commitments regarding their acquisition of MySQL by way of acquiring Sun. Personally, I’m not buying it.

For years Oracle worked, behind the scenes to discredit MySQL and tried hard to understand how their customers could ever consider using such an “immature” product instead of their lead product. In fact, it was so important to Oracle that they offered some very substantial discounts to customers who were using MySQL and Oracle. The good news is that this strategy didn’t work. MySQL had and has a staunch following that has always been a little leery of Oracle.

I’ve been a CTO at two locations that used Oracle and have found their practices to be cut-throat, sometimes bordering on ruthless. Is Oracle a serious threat to the open-source community? In my estimation, it certainly is, more than most of my colleagues, although a huge percentage of them would agree that this acquisition is not good for MySQL. Does Oracle participate in the open-source community? Sure, in a manner that supports themselves through commercial offerings. This is not the true spirit of open-source and leads to a slippery slope.

I’ve posted a poll on the right of this post, feel free to participate.

A serious SQL injection attack has injected a malicious iframe on more than 100,000 susceptible websites. ScanSafe reports that the injected iframe loads malicious content from 318x.com, which eventually leads to the installation of a rootkit-enabled variant of the Buzus backdoor trojan. A Google search on the iframe resulted in over 132,000 hits as of December 10, 2009.

Keep in mind that 99.9% of these attacks stem from poor coding. It very important to implore beginners (and some more experienced programmers) to code against them. In brief:

• Constrain Data, Check for known good data by validating for type, length, format, and range.
• Use type-safe SQL parameters for data access. Use parameters with stored procedures or dynamically constructed SQL command strings.
• Use a low-permission database account for data access.
• Hide data errors, don’t give clues at to what maybe acceptable to the database.

Now, there is a reason the items above look simple. They Are!

All we need are programmers that will listen and not take short cuts.