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

[Derek Wright]

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.