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

[Michael Favia]

Ashraf Amayreh wrote:
> > 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.
I think you replied to the wrong message than the one you intended to. I 
was quoting Karoly there. As you can see below. You and I are in 
complete agreement on this bit. It is actually one of the points of my 
email.
>
> On 5/21/07, *Michael Favia* <michael at favias.org 
> <mailto:michael at favias.org>> wrote:
>
>     Karoly Negyesi wrote:
>     >> I don't understand what's so inconvenient in allowing external
>     files.
>     >>
>     > 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.
>     >
>     Im of the alternative opinion that most module maintainers will be a
>     little more keyed into upstream progress for third party code than the
>     average module user. While it doesnt solve your problem of "I do not
>     want Drupal distributing insecure code." It does mitigate the real
>     problem of drupal users actually using insecure code on their websites
>     as it is outdated, etc. Why not centralize the management of the
>     code,
>     this is one of the purposes of version control systems in the first
>     place. To avoid duplication of effort. This isnt drupal core we are
>     talking about these are contrib modules that im sure have a number of
>     flaws anyway because of their less robust testing and security
>     audits.
>

-- 
Michael Favia                   michael at favias.org
tel. 512.585.5650        http://michael.favias.org