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