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

[Andrew ft]

Here is a practical interim suggestion:

-Split the TinyMCE module into two parts:
 1. a Drupal module
 2. a second module which is just a container for the TinyMCE libraries
patched for Drupal and ready to go.
-Host the first module on Drupal.org and the second externally
-Make the first module dependent on the second with clear instructions about
where to get it from.

That way TinyMCE will still show up on the statistics as one of the most
downloaded modules (which was one of the main reasons for not hosting the
whole thing offsite), but we avoid all the arguments about hosting foreign
code in the CVS.

I firmly believe that in the case of TinyMCE an exception should be made to
allow the modified library into CVS, but this might be a step towards that
goal without upsetting anyone.


On 5/25/07, Tao Starbow <starbow at citris-uc.org> wrote:
>
>
> > 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070525/120fb744/attachment.htm