From: chris <ju...@ho...> - 2007-10-17 18:41:00
|
>>> Plugin systems, by their very nature in web apps, come with risk and >>> they force the user to trust the specific developer of the plugin. >>> >>>> I raised a security point on the wiki about the possibility to hack >>>> Mantis with plugins. A plugin could be a malicious code, we need to >>>> find something to prevent that. You can not control what an administrator does or does not put on their system. Nothing keeps them from hacking the core code currently and unintentionally introducing vulnerabilities. Which just also says that any other script running on the same system has access to mantis, and could just as easily muck with it. As an example, the current mantis integration with Dokuwiki exposes mantis to all Dokuwiki plugins, and gives those plugins a simple way to find the location of mantis. Adding plugin support in my opinion reduces the likelihood of problems, because now common features/issues are solved with wider peer review, and generally is solved (or soon reviewed) by someone with more competence in php/mantis than a lone system administrator trying to get something to work. It seems to me that the current discussion is attributing a lot of problems to the concept of plugins while those problems are likely more related to how you are wanting to host/present mantis plugins, and the level of trust conveyed by the mantis team from hosting them. Personally, I think Dokuwiki is a good case study for a plugin system, as well as security/trust being conveyed. That all said, obviously mantis shouldn't be negligent in its implementation of security systems pertaining to itself, but I would be hard pressed to extend the meaning of "itself" to 3rd party plugins. Good documentation, and best practice examples go a long way to creating a thriving peer reviewed plugin development community. chris |