Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
I've been watching this thread for a while and think it's time to chime in (on a personal basis, not as a d.o CVS Admin). Developers need to be aware that Core has it's own CVS repository to Contrib and it's policies are decided solely by the Core Committers team, so using the "jQuery got in" is a moot point imho. 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. b) Uses Drupal.Org resources to effectively host "someone elses work". 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 of the personal opinion however that, where effective, certain pieces of work should be allowed into Contrib when it meets a certain criteria or benchmark. For example, where a 3rd party library is heavily modified to make it more suitable directly and solely for use with Drupal and hence the target is audience is Drupal specific. Such a decision would be based on a case by case merit of "how that commit makes Drupal end users lives so much the better". The only argument against this that I can think of is "who and how makes the decision" as it's basically more work on a volunteer workforce. Well, I suppose discussions like this are the best way :) I think it's fair to say that if such a policy existed, this thread has demonstrated (to me at least) that the maintainers of TinyMCE have successfully argued their case and would be the first Contrib "to pass the acid test" and be permitted to commit it's 3rd party library assuming they have the kind backing of the original authors of the 3rd party library. But I'm still of the opinion that generally (and blindly) committing 3rd party libraries (especially unmodified versions) into Contrib CVS should not happen. </2p> --Andy (AjK)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 andy@spiders-lair.com schrieb:
I've been watching this thread for a while and think it's time to chime in (on a personal basis, not as a d.o CVS Admin).
Developers need to be aware that Core has it's own CVS repository to Contrib and it's policies are decided solely by the Core Committers team, so using the "jQuery got in" is a moot point imho.
Indeed.
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. b) Uses Drupal.Org resources to effectively host "someone elses work". 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.
d) Since ususally no modificatiosn are made to the 3rd party code, there is absolutely no reason to keep in in a revision control system.
I am of the personal opinion however that, where effective, certain pieces of work should be allowed into Contrib when it meets a certain criteria or benchmark. For example, where a 3rd party library is heavily modified to make it more suitable directly and solely for use with Drupal and hence the target is audience is Drupal specific. Such a decision would be based on a case by case merit of "how that commit makes Drupal end users lives so much the better". The only argument against this that I can think of is "who and how makes the decision" as it's basically more work on a volunteer workforce. Well, I suppose discussions like this are the best way :)
We've had always had the ruls that you can commit "modified code". Modified in the sense to match Drupal better. This is however limited to the actual changed files.
I think it's fair to say that if such a policy existed, this thread has demonstrated (to me at least) that the maintainers of TinyMCE have successfully argued their case and would be the first Contrib "to pass the acid test" and be permitted to commit it's 3rd party library assuming they have the kind backing of the original authors of the 3rd party library.
Well, to me it hasn't. There is still no need to host the plethora of files that come with a JS editor in our CVS. As I see it it would be sufficient to host the changed config files in our CVS. Everything else could be taken care of by advanced packaging scripts.
But I'm still of the opinion that generally (and blindly) committing 3rd party libraries (especially unmodified versions) into Contrib CVS should not happen.
Should not and will not. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGVq3Jfg6TFvELooQRAtHiAJ454PtBtzVHmSFLvrvUPAcXrTe+VQCePKAj f1u64dW6iPvxWYGIClEztTE= =Np5q -----END PGP SIGNATURE-----
On May 25, 2007, at 2:35 AM, Gerhard Killesreiter wrote:
As I see it it would be sufficient to host the changed config files in our CVS. Everything else could be taken care of by advanced packaging scripts.
in the abstract, this is true. in reality, this is a nightmare, as i've already explained. the plumbing already exists to make projects and release nodes for 3rd party libraries, have proper dependencies, notifications when you need to upgrade, a way to share the same library among N drupal modules, etc, etc. the relatively weak "security" argument has been effectively refuted, IMHO. there's really not that much of a size/ performance cost from the CVS back-end side of things, either. the only thing standing between the people who want to leverage this functionality to make drupal easier to install and use is our own insistence on a policy that's only partially enforced anyway. some people are already ignoring this policy and getting the nice benefits right now. if we embraced this reality for some reasonable cases, others could do it tomorrow. in contrast, the code to get the packaging script smart enough to solve this problem will take many hours, lots of testing, a *major* friggin' security audit, a whole new level of complication for maintainers to learn, and a potentially vastly scarier thing for the CVS admins to have to monitor and audit ("just exactly where are you pointing the d.o packaging script to download sources from, random contrib maintainer?"). at least when the code is in our repo, it's easy to see what it is. if all that's in the repo is a URL to some tarball somewhere on the web, the potential for trojans, human error, transient site failures, etc, are all *much* higher. true, a malicious contrib maintainer could still put anything bad in their contrib they want, but at least we *could* audit that. if they just point to a reasonable looking URL, it'd be that much harder for us to see what's actually happening (sure, we could untar the packaged releases and inspect those, but we already don't have the resources to audit the commits to the repo as they're coming in -- we're certainly not going to start regularly auditing all the packaged tarballs). furthermore, they might point to a valid URL, but that other site might be compromised and sending out trojan'ed tarballs, which d.o would be happily downloading and packaging. :( in addition to fetching a tarball from a URL, we'd have to worry about at least an svn client to fetch with, if not git and others, along with cvs. plus, how would the maintainer specify how to unpackage the thing we download, where to put it, how to apply patches, move customized config files into the right places, etc, etc, without effectively giving everyone with a CVS account to our contrib repo shell access on the d.o servers? we'd have to basically hard-code a bunch of potential shell actions in some very restrictive sandbox and hope a) we got it all right and b) made it all flexible enough for people to use. it would be at least weeks, if not months (depending on who actually steps up to help write the code and how much funding is raised to sponsor their/our/my labor) before it was in a state that could be deployed for real on d.o. and, then it'd be a whole new full-time (unpaid) job for me to maintain it all, answer the endless stream of questions when people don't read the docs i'd have to spend hours writing, etc, etc. no thanks. killes: if you were going to be the one to solve all these problems and write this uber packaging script, all the docs, and maintain it forever, i'd be more sympathetic to your strict position on the philosophical right vs. wrong of committing 3rd party code into our contrib repo. however, i'm 95% sure this is going to fall to my shoulders if its ever going to get done, and therefore, i'm quite opposed to the "let's just get dww to spend hundreds of hours solving this for us" implication of your reply. and, hypothetically, if we had hundreds of hours of my time and/or many thousands of dollars to spend sponsoring some infrastructure work, is this really the best use of that time/money? if there was no alternative, that'd be one thing. but in this case, the alternative is easy and simple: stop being so stubborn about a policy that lots of long-time contributors to the project (not just the WYSIWYG crowd and the occasional do-nothing complainers in this thread) are in favor of relaxing under certain conditions. i'll say it again: if this proposal for "smarter packaging scripts to fetch 3rd party code" were an issue in the project queue, i'd set to "won't fix" on sight. -derek p.s. no, i'm not sure about the "hundreds" of hours, that's just a wild guess. my estimates for how much time it would take to design, build, test, deploy, document, and support the release system were so wildly unrealistic and low (in drupal terms, i was young, stupid, and still optimistic back then), that i'm now jaded when considering how long such things actually take. p.p.s. no, i'm also not advocating everyone should check in every possible 3rd party thing no matter what. i still think we need some level of control on this, and weigh it on a case-by-case basis.
On May 25, 2007, at 12:29 AM, andy@spiders-lair.com 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. b) Uses Drupal.Org resources to effectively host "someone elses work". 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.
a.) We wouldn't be distributing the library by itself; it would be packaged with some higher-level code. Nowhere on d.o would it say "If you want this library, get it here!" b.) As it relates to Drupal Core, contributed modules are ALREADY someone else's work. As it relates to Drupal as a whole, including GPL code form other sources is the very spirit of open source (as Jeff just said.) c.) If the maintainership is slack, the security risk is already there; the sloppy view of Drupal as a whole will already be there. It makes no difference if a 3rd party library is involved. Also, as a counterpoint: a good maintainer will monitor updates to a 3rd party library. And the good maintainer will always be more secure than the average user. I keep seeing the "security risk" reason repeated. But it seems people are really talking about the /perceived/ security of Drupal as a whole and not the /actual/ security of the average user's installation. Contrib modules are much more likely to get updated by the average user now that we have Update Status. But forcing a user to download and install a separate library means that library will most likely never be updated again. For /actual/ security, we need to allow 3rd party libs in Drupal's CVS (for the reason in c above). As a compromise, we could make contrib authors apply for special 3rd party library inclusion into CVS as Derek suggested and to then trust them to keep that 3rd party library well maintained. The CVS 3rd party lib application could be approved or denied based on the maintainers proven track record on previous modules. So newbie developers would be denied and maintainers like JJeff would need co-maintainers before the start of the project. (I'm not picking on you, Jeff! I love your code!) For /perceived/ security, maybe the best way to fix contrib from affecting Drupal core's good name is to put the distribution of contrib on a separate domain or sub-domain. Like 3rd- party.drupal.org or unofficial.drupal.org... Thoughts? - John
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?
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@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?
It looks like that's where we are headed. I encourage anyone interested in helping to improve TinyMCE (both the module and the Drupal specific version of TinyMCE itself) to join the TinyMCE Development group ( http://groups.drupal.org/tinymce-development). It was never my intention to incite such a long debate on the issue of 3rd party libraries. The truth is I can't do what Gerhard does from Drupal.org, so this could have ended when he said this would be too much of an issue for the people maintaining CVS. IMHO the 3rd party policy is going to need to be revised for JQuery plugins, but I've conceded that we need to find a home for at least part of TinyMCE. We're looking for feedback on the (next) best place to host Drupal specific development (http://groups.drupal.org/node/3364) now. If you have suggestions, please join that group and make your suggestions there or email me directly. I think everyone has had enough of this thread. - Kevin Reynen On 5/25/07, Andrew ft <andrewft@gmail.com> wrote:
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@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?
-Make the first module dependent on the second with clear instructions
about where to get it from. <http://tinymce.moxiecode.com/download.php>
TinyMCE,already does this for some other CMS's
participants (8)
-
Andrew ft -
andy＠spiders-lair.com -
Derek Wright -
Gerhard Killesreiter -
John -
Kevin Reynen -
Michael Hess -
Tao Starbow