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

Sun May 31 18:10:48 UTC 2009

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 #18 from Toshio Ernie Kuratomi <a.badger at gmail.com>  2009-05-31 14:10:46 EDT ---
(In reply to comment #17)
> Please excuse my confrontational disposition.
> 
The problem with confrontational dispositions are that they leave the
impression that the party being confrontational is unwilling to learn and
adapt.  At that point, it's often not worthwhile to continue a conversation
because no progress will be made.

> 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.
> 
Sorry if my quick grep for license incompatibilities confused you.  Your
example falls outside the scope of the no bundled library requirement because
the file is not a library.  Even though no duplication of code would lead to
more security in an ideal world, there are a number of issues that prevent us
from doing this reasonably.  The requirement that libraries not be bundled is a
good compromise since libraries are packaged separately, released on their own
timelines, and exist to be used in this way.

Since the code you point out has been copy and pasted between three
applications, I'd say that it's a great candidate for spinning off into its own
library so all three projects can share the maintainance burden and addition of
new features.

If you can point out a place where Mediawiki is bundling a library I'll be
happy to open a bug report and pursue the mediawiki packager to get that fixed.

Incompatible licensing or even problems with people including unlicensed code
is a separate issue from bundled libraries as they can exist independent of
each other.  However, projects that bundle libraries often have license issues
as well as they stem from the same root cause: upstream not understanding all
the implications of including code that they do not originate.

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

This is certainly a developer way of looking at things.  However, the claim
that web applications are special is false.  There are web applications that
distribute with scripts that check that necessary functionality is available. 
There are desktop applications that have to deal with small libraries and
quickly changing APIs.  We've made the decision in Fedora that convenience in
this area does not trump security.  Instead we evolve solutions to the problems
you face.

Sometimes we port code to newer versions of libraries for you and send the
patches back to you.  In other instances we create parallel installable
versions of the libraries your application depends on.  Compromises that
address both API instability and security exist.

> MediaWiki does it
> like this, so why can't Enano?
> 
If mediawiki bundles libraries, I'll file a bug and either the maintainer will
fix it or I'll talk with the PHP SIG about the best way to fix the issues.

> 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.
> 
This shows that you are good at reacting to security issues which is certainly
good.  It doesn't show that you are good at proactively designing secure
systems.  It doesn't show that you are paying attention to the security issues
that are popping up in the third-party code you are bundling.  It doesn't show
that you are evaluating the third party code you incorporate for security
issues.

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

This is only partially true but has offsetting costs as well.  The partially
true part is that if you are using function A but not B from a library, it
doesn't matter if you strip function B from the library or use the system
version, a security flaw in function A will affect you in either case and a
security flaw in function B will not affect you.

If you are removing functionality from function A to do your work, then yes,
you can increase security.  But the cost is that you have to make invasive
local changes to the code which takes time, could possibly introduce other
security flaws into the code, and which makes backporting new fixes from the
upstream for that code harder.

> 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.
> 
Recently there's been a lot more dependencies on http://pear.php.net/ modules
cropping up in php applications so I'd dispute your idea that this is a trend. 
Perhaps, "the way applications have been coded in the past" would be more
accurate.  Contributing the common code you rely on to PEAR and maintaining
them there is a way that Enano can go against hte flow and help the greater PHP
community as well.  Regardless, the blocker is on things that are separately
bundled libraries, not things that you've copy-and-pasted out of random other
applications (despite the problems that can crop up here as well).

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

If you want an experienced web application developer to review this package, I
can take over the review.  But seeing as I've been explaining the problem with
bundling libraries, that particular blocker would remain.

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