<div>Here is a practical interim suggestion:</div>
<div>&nbsp;</div>
<div>-Split the TinyMCE module into two parts:</div>
<div>&nbsp;1. a Drupal module</div>
<div>&nbsp;2.&nbsp;a second&nbsp;module which is just a container for&nbsp;the TinyMCE libraries patched for Drupal and ready to go.</div>
<div>-Host the first module on <a href="http://Drupal.org">Drupal.org</a> and the second externally</div>
<div>-Make the first module dependent on the second with clear instructions about where to get it from.</div>
<div>&nbsp;</div>
<div>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.
</div>
<div>&nbsp;</div>
<div>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.<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 5/25/07, <b class="gmail_sendername">Tao Starbow</b> &lt;<a href="mailto:starbow@citris-uc.org">starbow@citris-uc.org</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>&gt; As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:-<br>
&gt;<br>&gt; a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source.<br>&gt;<br>Or you can see it as creating a tested version known to work with a<br>given version of a drupal module.&nbsp;&nbsp;This is the entire idea behind
<br>versioning!&nbsp;&nbsp;Otherwise, if I create a drupal module that interfaces with<br>a 3rd party code base, I need to: chase after their development; see if<br>their latest version breaks my drupal wrapper; put info into the README
<br>like &quot;only works with version 1.3.1&quot; (which will be ignored by many<br>admins); and then somehow deal with the possibility that the 3rd party<br>might stop offering version 1.3.1 for download.<br>&gt; b) Uses 
Drupal.Org resources to effectively host &quot;someone elses work&quot;.<br>&gt;<br>Or you can see it as using <a href="http://drupal.org">drupal.org</a> resources to make things much<br>easier for drupal administrators.<br>
&gt; c) It&#39;s potentially a security risk, especially if maintainership is slack. Although problems aren&#39;t Drupal related directly it presents a sloppy view of the project as a whole imho.<br>&gt;<br>I am still not understanding this argument.&nbsp;&nbsp;Right now I can create a
<br>Hackme module that, say, emails your database password to all of your<br>users on instillation. I can upload this module as a project to<br><a href="http://Drupal.org">Drupal.org</a> and have it hosted by drupal cvs.&nbsp;&nbsp;I, or any of the hundreds
<br>of other unaudited developers, can accidentally create modules that open<br>up your site to cross site scripting.&nbsp;&nbsp;The security risk of the current<br>setup is pretty much infinite.&nbsp;&nbsp;How does allowing 3rd party code<br>
increase it?&nbsp;&nbsp;And how does making someone download that 3rd party code<br>from a different source decrease it?<br></blockquote></div><br>