[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

[Lodewijk Evers]

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 
my cue...
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 it:
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.

Security:
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 
javascript loaded is magnitudes more than jQuery)
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)


Regards,
Lodewijk Evers
Ontwerpwerk