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

[Ashraf Amayreh]

> 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.

On 5/21/07, Michael Favia <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.
>
> Arguments "for" such a centralization:
> * Ease of installation/upgrading use for user base.
> * Less trouble diagnosing issues on modules with third party libraries
> because you have 1 fewer variable.
> * Core Update Status Module to alert users automatically of new versions
> that include may include security updates.
> * The average module maintainer is probably going to be paying more
> attention to the upstream project than the user and is thus more likely
> to be aware of issues and also has the power to roll in the fixes and
> release thereby notifying everyone involved.
> * Module incompatibilities often require that people get a specific
> version of 3rd party library/code and this can be tough to instruct
> people to follow.
> * fewer unnecessary bugs regarding library mismatches, etc
>
> Arguments "against" such a  centralization:
> * Third party libraries can and will fall behind the official source
> with regards to vulnerabilities, security patches, etc a vigi=lant user
> might know or fix theses issues faster.
> * Duplication of code management with upstream.
> * licensing (discussed LGPL, etc)
> * module developer under less pressure to upgrade module to work with
> newest upstream version slows down innovation, etc
>
> I for one think that a good argument is made for centralizing this code
> management and easing the burden of our users without impacting the
> module developers (it is optional right?) I don't see how it can't be a
> mitigating factor for migrating users off of old libraries if you accept
> the proposition that the average maintainer follows the upstream project
> closer than the average user. But perhaps this is flawed logic.
>
> --
> Michael Favia                   michael at favias.org
> tel. 512.585.5650        http://michael.favias.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070521/92713619/attachment.htm