[drupal-devel] [bug] Bootstrap patch fixes

Thu Jun 30 17:48:29 UTC 2005

Issue status update for http://drupal.org/node/25600

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     bug reports
 Priority:     critical
 Assigned to:  chx
 Reported by:  kubaZygmunt
 Updated by:   moshe weitzman
 Status:       patch

the 'we shouldn't use 3rd party libraries' argument is hogwash.  that
was recenyly followed up with 'look where that got us recently' which
is even more stupid. security problems happen in your own code, and in
other people's code. we've had several security mistakes of our own,
and those mistakes have persisted a long time.

the benefit of 3rd party libraries is that you don't have to write
them, debug them, document them, or maintain them. if someone here is
willing to do all of this for XMLRPC then great. But thats extremely
unlikely so we either have to drop the whole feature set or use a 3rd
party library.

as you can tell, i favor #2 as well - switching libraries so we can do
conditional inclusion.

moshe weitzman

Previous comments:
------------------------------------------------------------------------

June 23, 2005 - 06:28 : kubaZygmunt

Attachment: http://drupal.org/files/issues/bootstrap.diff (422 bytes)

I've found that new cvs version doesn't get properly db_prefix.

In bootstrap.inc (function _drupal_bootstrap($phase) )
I added another global variable $db_prefix, and then it goes .

I don't know if my solution is good because on my local site I can't
see any blocks and on my internet site I have some caching and I can't
see anything :)

------------------------------------------------------------------------

June 23, 2005 - 07:45 : kubaZygmunt

Above I've put my patch

------------------------------------------------------------------------

June 23, 2005 - 07:56 : Jaza

Attachment: http://drupal.org/files/issues/db_prefix_global.patch (582 bytes)

Also noticed this bug, when trying to install a fresh CVS snapshot.
Attached is my patch against CVS HEAD (same as kubaZygmunt's,
basically).

------------------------------------------------------------------------

June 23, 2005 - 08:10 : chx

Yes, this is a bug, if you look at the bootstrap patch, there were
versions when I thought variables in settings.php should be written as
$GLOBALS['something'] but then introduced global $something . Forgot
when that something is db_prefix .

------------------------------------------------------------------------

June 28, 2005 - 00:26 : Jaza

Can this patch be applied to HEAD please? This is not something that
should be left sitting around in the issues list. Chx has identified
that it was a simple honest mistake on his part, and has indicated that
the submitted patch(es) will fix the mistake.

Until this patch is applied, anyone who tries to install HEAD using db
prefixes will get a fatal error. It doesn't get much more critical than
that :-p.

------------------------------------------------------------------------

June 30, 2005 - 09:56 : Bart Jansens

Attachment: http://drupal.org/files/issues/20050630.bootstrap-prefix-update.patch (1.21 KB)

There is another related problem, it is no longer possible to override
variables in settings.php.
And update.php no longer works.

Updated patch attached.

------------------------------------------------------------------------

June 30, 2005 - 10:04 : chx

Attachment: http://drupal.org/files/issues/20050630.bootstrap-patch.patch (2.92 KB)

Oh, and XML-RPC client is broken too. I talked with walkah and we found
it the best to move xmlrpc.inc to modules which use them.

------------------------------------------------------------------------

June 30, 2005 - 10:09 : chx

Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB)

some more xml-rpc fixes.

------------------------------------------------------------------------

June 30, 2005 - 10:20 : Steven

Making XML-RPC a conditional include was discussed a while ago, and
decided against due to problems with the class persistency. Why is this
now possible?

------------------------------------------------------------------------

June 30, 2005 - 12:36 : walkah

basically - it's not. the problem is, well, the xmlrpc.inc is not very
well written. It requires  / depends on several global variables, etc.
which leads to a fair bit of the scoping issues. If you look at what
PEAR has done with this (since their XML-RPC module is based on the
same original code)... you'll notice lots of $GLOBALS['...'] usage (see
http://cvs.php.net/co.php/pear/XML_RPC/RPC.php) . Basically, I think we
have 3 options:

1) keep banging on this old code to make it work.
2) switch libraries to either PEAR::XML-RPC or something like incutio's
(http://scripts.incutio.com/xmlrpc/)
3) re-write our own custom xml-rpc library 

personally, I'd +1 #2 - since #1 is ugly, and #3 I personally don't
have time for, and I'd rather see our developer resources going to more
interesting things.

that said, i know there are those with strong feelings against 3rd
party libraries... but this needs to get fixed quickly. blogapi and
drupal dist_auth are both currently broken in HEAD. (isn't there anyone
else here that tests XML-RPC stuff??)

------------------------------------------------------------------------

June 30, 2005 - 12:38 : walkah

just to follow up.. chx's patch in #7 only fixes XMLRPC servers...
anything that uses XML-RPC client (i.e. drupal_auth or ping) will still
be busted.