[development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
drupal at dwwright.net
Fri May 25 11:25:49 UTC 2007
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
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.
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.
More information about the development