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@xxxxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review