Re: [development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
On 5/23/2007 7:27:59 AM, Scott McLewin (drupal@mclewin.com) wrote:
When third party libraries become popular they benefit from a move into core, like jQuery did, and at that point they become the responsibility of the CVS maintainers to manage. This is a perfectly healthy progression, but it is one that has 'handle
You make it sound like this is a common occurrence. As far as I know, jQuery was a special case, and it's highly unlikely that, say, TinyMCE would become part of core. Michelle
Michelle Cox wrote:
On 5/23/2007 7:27:59 AM, Scott McLewin (drupal@mclewin.com) wrote:
When third party libraries become popular they benefit from a move into core, like jQuery did, and at that point they become the responsibility
You make it sound like this is a common occurrence. As far as I know, jQuery was a special case, and it's highly unlikely that, say, TinyMCE would become part of core.
I cannot speak to the frequency. As Drupal's popularity increases, I do believe we will see more incorporation of third party libraries in contrib modules, and as I wrote earlier today (in my time zone) I think managing a common version of those third party libraries within core for modules to share is indeed added work for the core maintainers. I don't buy Karoly's security argument as the driving reason for why we have a problem with this 'foreign' code, but I do believe we have a looming problem with the management of third party libraries. I'll be pleased to be wrong on this point. Scott
Scott McLewin wrote:
Michelle Cox wrote:
On 5/23/2007 7:27:59 AM, Scott McLewin (drupal@mclewin.com) wrote:
When third party libraries become popular they benefit from a move into core, like jQuery did, and at that point they become the responsibility
You make it sound like this is a common occurrence. As far as I know, jQuery was a special case, and it's highly unlikely that, say, TinyMCE would become part of core.
I cannot speak to the frequency. As Drupal's popularity increases, I do believe we will see more incorporation of third party libraries in contrib modules, and as I wrote earlier today (in my time zone) I think managing a common version of those third party libraries within core for modules to share is indeed added work for the core maintainers.
I don't buy Karoly's security argument as the driving reason for why we have a problem with this 'foreign' code, but I do believe we have a looming problem with the management of third party libraries. I'll be pleased to be wrong on this point. Perhaps to address this concern, we could create a dedicated module that simply provides the third party library in question and little or no additional functionality as required by drupal. The the modules that depend on it can do just that in the info files. Avoids duplication and centralizes the management and ability to audit for security issues too boot.
-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
Quoting Michael Favia <michael@favias.org>:
Perhaps to address this concern, we could create a dedicated module that simply provides the third party library in question and little or no additional functionality as required by drupal. The the modules that depend on it can do just that in the info files. Avoids duplication and centralizes the management and ability to audit for security issues too boot.
Rather than a ``module'' what if we have a lib directory to put the third party libraries into. The info file would still depend on it. Earnie
aps to address this concern, we could create a dedicated module that simply provides the third party library in question and little or no additional functionality as required by drupal. The the modules that depend on it can do just that in the info files. Avoids duplication and centralizes the management and ability to audit for security issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this. Round 2... ding, ding Nedjo asked about the 3rd party library issue (http://drupal.org/node/124978), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them. Jeff includes unmodified? versions of jquery.js 1.1.2 and compat.1.0.js ( http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update. The interface.js (78k) included in the JQuery_interface is available from the developer at http://interface.eyecon.ro/changelog I also found it here... http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/interface.js http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/interface.js Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well... http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins ( http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce/plugins). By dropping the _src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug-ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself. For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now. I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it. - Kevin Reynen On 5/24/07, Tao Starbow <starbow@citris-uc.org> wrote:
aps to address this concern, we could create a dedicated module that simply provides the third party library in question and little or no additional functionality as required by drupal. The the modules that depend on it can do just that in the info files. Avoids duplication and centralizes the management and ability to audit for security issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
At this point a number of merits for both directions have come out here. Currently the policy is to not have them in CVS. What would it take to change that policy? On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this.
Round 2... ding, ding
Nedjo asked about the 3rd party library issue ( http://drupal.org/ node/124978), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them.
Jeff includes unmodified? versions of jquery.js 1.1.2 and compat. 1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update. The interface.js (78k) included in the JQuery_interface is available from the developer at http:// interface.eyecon.ro/changelog
I also found it here...
http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/ interface.js http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/ interface.js
Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well...
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce
TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins ( http://trac.wordpress.org/browser/trunk/wp-includes/js/ tinymce/plugins). By dropping the _src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug- ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself.
For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now.
I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it.
- Kevin Reynen
On 5/24/07, Tao Starbow <starbow@citris-uc.org> wrote:
aps to address this concern, we could create a dedicated module that simply provides the third party library in question and little or no additional functionality as required by drupal. The the modules that depend on it can do just that in the info files. Avoids duplication and centralizes the management and ability to audit for security issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site. Matthew Farina wrote:
At this point a number of merits for both directions have come out here. Currently the policy is to not have them in CVS. What would it take to change that policy?
On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this.
Round 2... ding, ding
Nedjo asked about the 3rd party library issue ( http://drupal.org/node/124978), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them.
Jeff includes unmodified? versions of jquery.js 1.1.2 and compat.1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update. The interface.js (78k) included in the JQuery_interface is available from the developer at http://interface.eyecon.ro/changelog
I also found it here...
http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/interface.js http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/interface.js <http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/interface.js>
Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well...
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce <http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce>
TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins ( http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce/plugins). By dropping the _src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug-ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself.
For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now.
I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it.
- Kevin Reynen
On 5/24/07, *Tao Starbow* <starbow@citris-uc.org <mailto:starbow@citris-uc.org>> wrote:
> aps to address this concern, we could create a dedicated module that > simply provides the third party library in question and little or no > additional functionality as required by drupal. The the modules that > depend on it can do just that in the info files. Avoids duplication > and centralizes the management and ability to audit for security > issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site.
I was not going to weigh in on this, but I provided a quote to a client several weeks ago, they made the choose to do the work themsevles in wordpress. Today I got a call from them, talking about<http://it.slashdot.org/it/07/05/24/167223.shtml> asking me if I was still willing to do the work. I tried to explain to them that drupal can suffer from the same issues. (They did not really understand but that is ok for the purpose of this email) If we start allowing chunks of code in, I think it would end up being a huge security issue for drupal over all. If a site gets compromised, it won't be X module, that was a security issue, it will be drupal that is the security issue. just my 2 cents, Michael
I don't understand this argument. We all already know there are insecure modules available for download from the Drupal CVS. That is just the nature of an unaudited contribution system. It is up to each module maintainer to make their project secure, and we all do it to varying levels of ability and diligence. If a project maintainer includes 3rd party GPL code in a module, they are putting their personal reputation on the line, exactly the same if they don't include 3rd party code. Besides the slashdot article is about insecure WordPress plugins that shipped with the core package. Michael Hess wrote:
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site.
I was not going to weigh in on this, but I provided a quote to a client several weeks ago, they made the choose to do the work themsevles in wordpress.
Today I got a call from them, talking about<http://it.slashdot.org/it/07/05/24/167223.shtml> asking me if I was still willing to do the work. I tried to explain to them that drupal can suffer from the same issues. (They did not really understand but that is ok for the purpose of this email)
If we start allowing chunks of code in, I think it would end up being a huge security issue for drupal over all.
If a site gets compromised, it won't be X module, that was a security issue, it will be drupal that is the security issue.
just my 2 cents, Michael
I agree with you in principle, but the problem is that end users don't consider contributed modules to be separate from core. As more and more contributed modules become vulnerable to these kinds of issues, Drupal as a whole begins to look bad. That's the primary reason for the restrictions on importing foreign stuff into Drupal CVS. It annoys the hell out of me on occasion, but I can see their point, too. Tao Starbow wrote:
I don't understand this argument. We all already know there are insecure modules available for download from the Drupal CVS. That is just the nature of an unaudited contribution system. It is up to each module maintainer to make their project secure, and we all do it to varying levels of ability and diligence. If a project maintainer includes 3rd party GPL code in a module, they are putting their personal reputation on the line, exactly the same if they don't include 3rd party code.
Besides the slashdot article is about insecure WordPress plugins that shipped with the core package.
Michael Hess wrote:
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site.
I was not going to weigh in on this, but I provided a quote to a client several weeks ago, they made the choose to do the work themsevles in wordpress.
Today I got a call from them, talking about<http://it.slashdot.org/it/07/05/24/167223.shtml> asking me if I was still willing to do the work. I tried to explain to them that drupal can suffer from the same issues. (They did not really understand but that is ok for the purpose of this email)
If we start allowing chunks of code in, I think it would end up being a huge security issue for drupal over all.
If a site gets compromised, it won't be X module, that was a security issue, it will be drupal that is the security issue.
just my 2 cents, Michael
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
Can someone explain what would be the difference between including a configured TinyMCE and TinyMCE from moxiecode? Would it just be the configuration file or more? I'm starting to wonder if going with a ftp/sftp approach (like Joomla) has wouldn't be a bad idea. We could keep the code out or our repository yet have the installer pull it down and put it in the right place/give a simple upload window as a step with instructions where to download it. In the case of TinyMCE, if it's just the config file that could be written via this ftp/sftp functionality. And, maybe not allowing the change to CVS policy would give incentive to write the ftp functionality. Just some thoughts.... Matt On May 24, 2007, at 6:31 PM, Sean Robertson wrote:
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site.
Matthew Farina wrote:
At this point a number of merits for both directions have come out here. Currently the policy is to not have them in CVS. What would it take to change that policy? On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this. Round 2... ding, ding
Nedjo asked about the 3rd party library issue ( http://drupal.org/ node/124978), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them.
Jeff includes unmodified? versions of jquery.js 1.1.2 and compat. 1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update. The interface.js (78k) included in the JQuery_interface is available from the developer at http:// interface.eyecon.ro/changelog
I also found it here...
http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/ interface.js http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/ interface.js <http://trac.bbpress.org/browser/trunk/bb-includes/ js/jquery/interface.js>
Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well...
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce <http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce>
TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins ( http://trac.wordpress.org/browser/trunk/wp-includes/js/ tinymce/plugins). By dropping the _src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug- ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself. For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now.
I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it.
- Kevin Reynen
On 5/24/07, *Tao Starbow* <starbow@citris-uc.org <mailto:starbow@citris-uc.org>> wrote:
> aps to address this concern, we could create a dedicated module that > simply provides the third party library in question and little or no > additional functionality as required by drupal. The the modules that > depend on it can do just that in the info files. Avoids duplication > and centralizes the management and ability to audit for security > issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves. After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks! Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense. The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml). The question isn't am I going to provide a Drupal friendly version of TinyMCE. I am. The only question is where will Drupal users interested in TinyMCE downlaod that version from? I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure. If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame? The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change. - Kevin On 5/24/07, Matthew Farina <matt@mattfarina.com> wrote:
Can someone explain what would be the difference between including a configured TinyMCE and TinyMCE from moxiecode? Would it just be the configuration file or more?
I'm starting to wonder if going with a ftp/sftp approach (like Joomla) has wouldn't be a bad idea. We could keep the code out or our repository yet have the installer pull it down and put it in the right place/give a simple upload window as a step with instructions where to download it.
In the case of TinyMCE, if it's just the config file that could be written via this ftp/sftp functionality.
And, maybe not allowing the change to CVS policy would give incentive to write the ftp functionality.
Just some thoughts....
Matt
On May 24, 2007, at 6:31 PM, Sean Robertson wrote:
I would like to see a Drupal-optimized TinyMCE package. It'd make it a lot easier on me if it had standard Drupal-related plugins already installed so I didn't have to do that manually for every site.
Matthew Farina wrote:
At this point a number of merits for both directions have come out here. Currently the policy is to not have them in CVS. What would it take to change that policy? On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this. Round 2... ding, ding
Nedjo asked about the 3rd party library issue ( http://drupal.org/ node/124978), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them.
Jeff includes unmodified? versions of jquery.js 1.1.2 and compat. 1.0.js (http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update. The interface.js (78k) included in the JQuery_interface is available from the developer at http:// interface.eyecon.ro/changelog
I also found it here...
http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/ interface.js http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/ interface.js <http://trac.bbpress.org/browser/trunk/bb-includes/ js/jquery/interface.js>
Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well...
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce <http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce>
TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins ( http://trac.wordpress.org/browser/trunk/wp-includes/js/ tinymce/plugins). By dropping the _src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug- ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself. For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now.
I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it.
- Kevin Reynen
On 5/24/07, *Tao Starbow* <starbow@citris-uc.org <mailto:starbow@citris-uc.org>> wrote:
> aps to address this concern, we could create a dedicated module that > simply provides the third party library in question and little or no > additional functionality as required by drupal. The the modules that > depend on it can do just that in the info files. Avoids duplication > and centralizes the management and ability to audit for security > issues too boot.
This is the approach Jeff Robins has taken with his jQuery_update and jQuery_interface modules, and I think it works very well. This approach leverages Drupal's project versioning and dependency systems to keep the 3rd party (GPL) code insync with the Drupal code, and simplifies instillation.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
I think Kevin makes a compelling case. To me, the process of installing TinyMCE is real a pain, and I think having such a Drupal-customized version in CVS makes perfect sense in order to take advantage of the packaging, and to use CVS for tracking of the files changed, etc. -Peter On 5/24/07, Kevin Reynen <kreynen@gmail.com> wrote:
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves.
After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks!
Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense.
The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml).
The question isn't am I going to provide a Drupal friendly version of TinyMCE.
I am.
The only question is where will Drupal users interested in TinyMCE downlaod that version from?
I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure.
If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame?
The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change.
- Kevin
To be perfectly honest, I think what we really need here is a Drupal-specific WYSIWYG editor. Maybe we can reuse some Tiny6MCE code, but ultimately, I think we'll do better when there is a WYSIWYG editor in core. Peter Wolanin wrote:
I think Kevin makes a compelling case. To me, the process of installing TinyMCE is real a pain, and I think having such a Drupal-customized version in CVS makes perfect sense in order to take advantage of the packaging, and to use CVS for tracking of the files changed, etc.
-Peter
On 5/24/07, Kevin Reynen <kreynen@gmail.com> wrote:
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves.
After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks!
Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense.
The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml).
The question isn't am I going to provide a Drupal friendly version of TinyMCE.
I am.
The only question is where will Drupal users interested in TinyMCE downlaod that version from?
I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure.
If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame?
The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change.
- Kevin
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
With the code freeze a matter of days away I don't see a WYSIWYG editor in core for D6 so the immediate path forward would be something else. On May 24, 2007, at 10:29 PM, Sean Robertson wrote:
To be perfectly honest, I think what we really need here is a Drupal-specific WYSIWYG editor. Maybe we can reuse some Tiny6MCE code, but ultimately, I think we'll do better when there is a WYSIWYG editor in core.
Peter Wolanin wrote:
I think Kevin makes a compelling case. To me, the process of installing TinyMCE is real a pain, and I think having such a Drupal-customized version in CVS makes perfect sense in order to take advantage of the packaging, and to use CVS for tracking of the files changed, etc. -Peter On 5/24/07, Kevin Reynen <kreynen@gmail.com> wrote:
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves.
After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks!
Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense.
The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml).
The question isn't am I going to provide a Drupal friendly version of TinyMCE.
I am.
The only question is where will Drupal users interested in TinyMCE downlaod that version from?
I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure.
If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame?
The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change.
- Kevin
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
It could happen in a contributed module, but mainly I see relying on external code as a bad idea. This is a really big complaint from end users that I would very much like to see addressed and I'm not sure the current 'download someone else's code' approach is sufficient. Matthew Farina wrote:
With the code freeze a matter of days away I don't see a WYSIWYG editor in core for D6 so the immediate path forward would be something else.
On May 24, 2007, at 10:29 PM, Sean Robertson wrote:
To be perfectly honest, I think what we really need here is a Drupal-specific WYSIWYG editor. Maybe we can reuse some Tiny6MCE code, but ultimately, I think we'll do better when there is a WYSIWYG editor in core.
Peter Wolanin wrote:
I think Kevin makes a compelling case. To me, the process of installing TinyMCE is real a pain, and I think having such a Drupal-customized version in CVS makes perfect sense in order to take advantage of the packaging, and to use CVS for tracking of the files changed, etc. -Peter On 5/24/07, Kevin Reynen <kreynen@gmail.com> wrote:
In TinyMCE case, it's not just a config file. When you download TinyMCE from Moxicode you get lots of extra files (examples, _src.js, translated icons, etc). The current install process has the user download the full TinyMCE package and throw it into the TinyMCE module folder. So currently, TinyMCE users have more than twice the code they need on their sites unless they planning on doing some custom TinyMCE development or they are deleting those extra files themselves.
After going through the regular module install process TinyMCE shows up... but the fun doesn't stop there folks!
Because TinyMCE isn't Drupal specific, Moxiecode tries to filter out potentially malicious HTML by default which often conflicts with Drupal's Input format. Unlike Drupal where the HTML is changed on display, TinyMCE alters the HTML when the WYSIWYG toolbar is applied to the text field. If TinyMCE is set to be shown by default, the original "bad" HTML is deleted as soon as the edit page is loaded. Tags like <script> and <embed> are deleted even when they are manually added using the HTML button. When using TinyMCE with Drupal, this double filter makes no sense.
The process to change the valid HTML allowed by TinyMCE is less than user friendly (http://groups.drupal.org/node/4114#validhtml).
The question isn't am I going to provide a Drupal friendly version of TinyMCE.
I am.
The only question is where will Drupal users interested in TinyMCE downlaod that version from?
I just cannot follow the logic that having me host 90% of the code needed to install the module on a site I maintain makes Drupal more secure... nor can I wrap my head around how automating the process of downloading code from sites other than Drupal.org would make Drupal installs more secure.
If there is an exploit in TinyMCE that compromises Drupal installs tomorrow, there are going to be a lot of sites comprised. Is the fact that TinyMCE is currently a two step install going to change who people blame for their Drupal site being compromised? Will making TinyMCE easier to install change who gets the blame?
The only argument I've heard for keeping 3rd party code out of CVS that makes sense to me is that the size and number of files would create performance issues. I don't know enough about CVS to know what a reasonable amount of code might be, but since there are already respected developers ignoring the 0K policy it seems like something is going to have to change.
- Kevin
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
What exactly does "foreign code" mean?!? If we write it from scratch, it's not foreign, right? What if we copy some of the code from another GPL project? What if we only slightly modify another GPL project, perhaps just enough to make it work with Drupal? Well then it can't be downloaded from the original source. Are you telling me that this can't be included in the contrib repository? This sort of modification is the entire spirit of the GPL! It's about freedom and growth. By not allowing it into the repository, we are actually diverging from the spirit of the GPL. How modified does a project need to be in order to be considered "native" Drupal code? I would submit that it DOES NOT need to be modified at all in order to be considered Drupal code. In the case of Drupal 5's JQuery, Drupal includes JQuery version 1.0.3 which is now fully deprecated in the JQuery community. Many of the JQuery plug-in maintainers do not continue to distribute plug-ins that function with 1.0.x and so there is no way to link to these plugins and ask users to download them elsewhere. So in the form of the old versions of these plugins, we have unmodified code, that for all intents and purposes, only works with Drupal and can only be found in the Drupal code repository. We have a great resource with the Drupal CVS repository. I think that we should be as accepting as possible in order to foster creativity and growth. The GPL and Source Forge both provide examples as to the spirit of this openness. I think we should take notes. The larger that Drupal becomes, the more "gray area" code will emerge. I believe the rules for code inclusion should be very very simple: All code must be GPLed. Don't get me wrong, I would be ALL FOR allowing LGPLed code into the repository, but I also understand that the line needs to be drawn somewhere. But I think when people talk about *not* allowing at-one- time-external GPLed code into the Drupal repository, they're simply on crack. -Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Robbins schrieb:
What exactly does "foreign code" mean?!? If we write it from scratch,
Everything that is not a theme, a theme-engine, or a module (or an .inc file depending on a module).
it's not foreign, right? What if we copy some of the code from another GPL project?
If you just copy a PHP function from some other project, this is not a problem, I think. If you start moving more code into our repository just for "convenience" of your users (ie because you want it to be packaged) then I'd consider that abuse.
What if we only slightly modify another GPL project, perhaps just enough to make it work with Drupal? Well then it can't be downloaded from the original source. Are you telling me that this can't be included in the contrib repository?
I haven't seen such a modification yet.
This sort of modification is the entire spirit of the GPL! It's about freedom and growth. By not allowing it into the repository, we are actually diverging from the spirit of the GPL.
See above.
How modified does a project need to be in order to be considered "native" Drupal code? I would submit that it DOES NOT need to be modified at all in order to be considered Drupal code.
Well, I don't share that point of view.
In the case of Drupal 5's JQuery, Drupal includes JQuery version 1.0.3 which is now fully deprecated in the JQuery community.
Yes.
Many of the JQuery plug-in maintainers do not continue to distribute plug-ins that function with 1.0.x and so there is no way to link to these plugins and ask users to download them elsewhere. So in the form of the old versions of these plugins, we have unmodified code, that for all intents and purposes, only works with Drupal and can only be found in the Drupal code repository.
Have you seen me complaining about this? I doubt it. If GPLed code cannot be downloaded elsewhere, then of course you can include it in the repo.
We have a great resource with the Drupal CVS repository. I think that we should be as accepting as possible in order to foster creativity and growth. The GPL and Source Forge both provide examples as to the spirit of this openness. I think we should take notes. The larger that Drupal becomes, the more "gray area" code will emerge. I believe the rules for code inclusion should be very very simple: All code must be GPLed.
If you have a look at http://drupal.org/user/227 you'll see that I have 534 commits to the fckeditor project listed. This is from when I removed all these 534 files that fckeditor apparently shipped with (nowadays I'd simple edit the repository directly). Wouldn't you agree that having all there 534 files in our cvs is a bad idea?
Don't get me wrong, I would be ALL FOR allowing LGPLed code into the repository, but I also understand that the line needs to be drawn somewhere. But I think when people talk about *not* allowing at-one-time-external GPLed code into the Drupal repository, they're simply on crack.
Think what you want, I've explained the rules of the game. This is my last reply in this already too long thread. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGVuK2fg6TFvELooQRAgKjAKCaNpVilOAF97MYastXppvael0qjwCgyvn/ IyWWexy9lRfdemmU72ErPng= =inRW -----END PGP SIGNATURE-----
participants (12)
-
Earnie Boyd -
Gerhard Killesreiter -
Jeff Robbins -
Kevin Reynen -
Matthew Farina -
Michael Favia -
Michael Hess -
Michelle Cox -
Peter Wolanin -
Scott McLewin -
Sean Robertson -
Tao Starbow