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

Tao Starbow starbow at citris-uc.org
Fri May 25 15:55:24 UTC 2007


> As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:-
>
> a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source.
>   
Or you can see it as creating a tested version known to work with a 
given version of a drupal module.  This is the entire idea behind 
versioning!  Otherwise, if I create a drupal module that interfaces with 
a 3rd party code base, I need to: chase after their development; see if 
their latest version breaks my drupal wrapper; put info into the README 
like "only works with version 1.3.1" (which will be ignored by many 
admins); and then somehow deal with the possibility that the 3rd party 
might stop offering version 1.3.1 for download.
> b) Uses Drupal.Org resources to effectively host "someone elses work".
>   
Or you can see it as using drupal.org resources to make things much 
easier for drupal administrators.
> c) It's potentially a security risk, especially if maintainership is slack. Although problems aren't Drupal related directly it presents a sloppy view of the project as a whole imho.
>   
I am still not understanding this argument.  Right now I can create a 
Hackme module that, say, emails your database password to all of your 
users on instillation. I can upload this module as a project to 
Drupal.org and have it hosted by drupal cvs.  I, or any of the hundreds 
of other unaudited developers, can accidentally create modules that open 
up your site to cross site scripting.  The security risk of the current 
setup is pretty much infinite.  How does allowing 3rd party code 
increase it?  And how does making someone download that 3rd party code 
from a different source decrease it?


More information about the development mailing list