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