[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
ontwerpwerk at webcommunicatie.org
Mon May 21 22:10:50 UTC 2007
Ashraf Amayreh schreef:
> It's very simple. When there is a security fix released for the 3rd party code then our repository necessarily will be some time behind -- if the maintainer is sloppy then seriously behind. I do not want Drupal distributing insecure code. Solve this problem and we can move on.
> So asking the users to download this insecure code from somewhere else is somehow solving it? Seriously, all of our modules that rely on external code are outdated as soon as the next release of that external code comes out. FCKeditor module for example requires users to download version 3.2 to work with the module, so you're definitely not enforcing any security by making the developer's life harder. When the FCKeditor developer upgrades his module to work with the latest version I'm sure he'd much more rather update the external code than write tutorials and wade through tons of support requests. This is in fact promoting security.
> When the module writer decides to support the next version of the external code then he will definitely HAVE TO upgrade the external code in his module, if he's not going to support the new release then it's all the same weather he includes the outdated code or asks users to download this outdated code elsewhere. What am I getting at? The only thing that we gain by forcing the code outside of the repository is a pain for the user and a double pain for the developer who has to do the installation and waste more time documenting it and even more time replying to support requests for it. So rather than concentrate on improving his module and upgrading it to the new external code he'd be wasting it writing tutorials over and over again for support issues. This is definitely a loss-loss deal. Any gains by keeping this code outside is simply an illusion.
As the developer who's doing the FCKeditor module at the moment this is
I realize that this discussion seems to say any external code, but from
previous discussions like this I gather that everyone means WYSIWYG
editors, because they are the prime suspects that always come up.
Supporting a component like FCKeditor will not be easier with the
component included in the module package, there is too much server
specific configuration needed to configure a monster like that...
Unfortunately that does indeed mean that a lot of the support requests
are from users that cannot even read a fscking README.txt, and that's
also something I tried to prevent in the development version. But the
other big part of the support request are actually for people who don't
understand the drupal filter system.
Yes, creating tutorials to install a FCKeditor is tedious work, but
someone has to do it...
Why not to add it to the drupal CVS repository:
If the FCKeditor were uploaded into CVS that would mean that there would
be ~500 extra files in the repository, which just isn't clean and
proper. CVS is for tracking development, and since no-one in their right
mind will be developing for the FCKeditor or tinyMCE project in the
drupal repository (that would be a fork of those projects) it does not
make sense to include those files in there either. Those 500 files will
just be doing nothing there and taking up resources like a fax modem in
a centrino laptop.
A guideline could be that if a project has a repository of their own,
and even a complete developer community - don't even think about
importing it into the drupal repository.
The profit on the security site will be exacly nothing... a WYSIWYG is
insecure by design (file uploads for FCKeditor with the builtin browser
are a nightmare for sercurity minded people, the editors need liberal
filters to have all browser dependent markup come through, and the
If you're lagging a version behind for tinyMCE or FCKeditor you're not
more or less secure, you will only have different features (by the it's
not a bug it's a feature, definition)
All in all, I'm for the current way of handling stuff, a large component
should not be included in the drupal cvs repository. There are some
drawbacks to it, but they arent worth the trouble we'd be getting
ourselves into by doing that.
(now if someone would make a jQuery WYSIWYG that is aware of the drupal
filter system and integrates with drupal node, user and file/image
handling then it would be a different story)
More information about the development