Clarification regarding the Board's decision on SQLNinja

[Jared K. Smith]

As many of you are well aware, the Fedora Board made a decision not to
include the SQLNinja package at our November 8th meeting.  In the
meantime, I've received quite a bit of feedback, and I'd like to take
this opportunity to provide a bit of clarification on the Board’s
decision.  (Much of this text came from a comment I made on a blog
post earlier this week -- but several people prodded me and told me it
would be better posted here.)

Much of the feedback in the press and the feedback that I've received
personally seems to come from a false assumption that the Fedora Board
is somehow going after any program that *could* be used maliciously.
That is not our intention at all. I think the discussion is much more
nuanced than that, so please allow me to explain if I may.

In our Board meeting last week, we looked at SQLNinja specifically.
Our goal wasn't to set precedent for how to handle all such packages
in the future -- we simple set out with the goal of deciding whether
or not SQLNinja should be part of Fedora.

In the specific case of the SQLNinja tool, it’s obviously very
squarely within the gray area between “security professional tool” and
“script-kiddie weapon”. Since it’s in the gray area and was flagged
for legal review, Spot took the first stab at it, and determined that
it does in fact add some additional legal risk to Fedora to carry the
SQLNinja package.  But because that risk is currently unclear, he
brought it to the Board for further consideration.  Let me also point
out that the legal risk wasn’t the only reason we decided not to carry
it. As I’ve articulated previously on the advisory-board list, there
were several questions we asked ourselves as we made the
determination:

* Does the application have the potential to increase our legal
liability in a significant way?
* Does the application have significant legitimate uses outside of
attacking a system?
* How does the application market itself? As a security tool? As an
easy way to exploit others?
* How difficult would it be for knowledgeable security professional to
build, versus an unskilled script-kiddie?
* Is this an application that could be easily hosted in a third-party
repository instead of Fedora?

Considering these questions against the other security tools that were
commonly mentioned in feedback I received (such as tcpdump), it is
pretty easy to see how they’re different than SQLNinja. I should also
note that much of the objections to our decision were against blocking
security tools in general, not the SQLNinja package specifically.  (In
my own limited investigation, I have yet to find a single security
professional who was actively using the tool before our decision.
Others have since pointed out that they know of people actively using
SQLNinja.)  I should also point out that the SQLNinja package is
already available in one of the more popular third-party repositories,
so it's readily available to Fedora users, even if we choose not to
package it in the official Fedora repositories.

Given the level of feedback on this issue, however, the Fedora Board
voted to revisit this decision once they have some additional
information regarding the risks that SQLNinja might pose to Fedora.

Thanks for your comments and suggestions on this matter.

--
Jared Smith
Fedora Project Leader