> 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@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@favias.org
tel. 512.585.5650        http://michael.favias.org