[Bug 481536] Review Request: enano - Enano CMS, a php-based modular content management system

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=481536





--- Comment #17 from Dan Fuhry <dan at enanocms.org>  2009-05-31 12:13:11 EDT ---
Please excuse my confrontational disposition.

I'd like to know how MediaWiki made it into Fedora repositories, seeing as much
of the code it uses is also borrowed without being separately packaged. An
example of this would be phpWiki's diff engine - both Enano and MediaWiki use
this same code from phpWiki 1.3.3. By the standard you are holding us to,
MediaWiki would have had to split its diff engine out before it was accepted
into Fedora repositories. They don't even HAVE a centralized list of 3rd-party
code distributed with their package.

Like other web apps, Enano is not very much like a desktop application in the
way it is designed. It is a web application. We can't just distribute it with a
configure script that screams at you about dependent libraries until everything
is satisfied. On the Web, libraries are so small and APIs change so quickly
that bundling libraries is the only thing that makes sense. MediaWiki does it
like this, so why can't Enano?

We take security problems as seriously as anyone. Our turnaround time for
security releases is typically 4 hours from the time I'm alerted to it to the
time the tarballs are on the Web server and announcements are circulating. Neal
Gompa (King InuYasha), who built and plans to maintain the RPM, is the
second-highest person in the Enano project. If there's going to be a security
release, he knows about it as soon as I become aware of the vulnerability, and
sometimes sooner as he's our official QA contact.

Now on to API stabilization. Web developers love to break APIs. (Yes, I'm
guilty of this too.) By controlling the code ourselves, we ensure that there
are not any API changes that could cause Enano to break or somehow introduce a
security problem. When done properly - with proper porting and removal of
unneeded components, such as is done in Enano and MediaWiki - bundling can mean
that security is in fact INCREASED because only the core components involving
the heavy number crunching really stay; everything else is done by Enano.
Almost all GPL'ed PHP scripts are distributed as applications, not individual
libraries and toolkits. This is in contrast to Java applications, which you are
equating with PHP applications, but really are different in the sense that Java
components are separated into libraries rather than bundled and integrated
tightly with the core. This is an industry trend and not something the Enano
project really has control over. We have to go with the flow in this case.

Integration is crucial too: we also have our own API that bundled libraries
need to use, such as the code required to parse wikilinks and route CAPTCHA
images through Enano's URL and page management code. Proper integration doesn't
happen without this.

Another fun statistic: while Enano has a bunch of bundled libraries, none of
them ever make SQL queries or directly parse any sort of user input. So the two
biggest sources of security vulnerabilities - SQL injection and XSS - should
NEVER be present in any 3rd party code. The 80:20 rule applies to security
problems too: roughly 80% of security holes are caused by 20% of vulnerability
types.

In summary: we bundle for two reasons:
  1) We don't want API breakage, and
  2) Web apps are different from traditional ones; libraries often do too much
and need things to be stripped out in order to work correctly. We allow this
because the overhead, not the core functionality, is almost always where
security problems are.

If you're going to have someone review this package, it should be an
experienced web developer who understands this stuff. Web apps just are not
traditional desktop apps, and many web application security practices are
difficult to grasp from the perspective of someone who handles security of
desktop apps. They're not less secure, they're just different.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.