Re: [be] Packages (bibledit-web and build time mysql server checking)

[Jonathan Marsden]

Replying to myself,

On 12/28/2010 02:36 PM, Jonathan Marsden wrote:

> I started on this today.  I soon encountered something I am not sure
> how to handle -- bibledit-web seems to expect a working and
> configured mysql server at *build* time.

More comments and ideas related to packaging bibledit-web:

CONFIGURING TOO EARLY:

Looking further at the autotools configuration done in bibletime-web
0.2, other things that need to be settable per-installation, not at
build time, are apparently also being configured and defined at build
time.  These include the database server location, database admin user,
database admin password, database name, database user, database
password, bibledit admin user and password, and the location of the
webroot of the web server.  Some of these seem to be handled in
database/credentials.php and this is created by setup.php, but in that
case, why is the checking of MySQL at build time being done?

Why the code needs the mysql admin username and pw is a question in
itself -- wouldn't it be more secure to prompt for these when needed,
which hopefully is just for a one-time initial database setup, done at
(package) install time, not build time?

Since (at least in theory) one could set up multiple instances of
bibledit-web on a single server, each with their own database and each
with their own apache virtualhost, doing too much at build time seems to
me to reduce overall flexibility and capability.

Unless I am misunderstanding what the code does, I don't see how this
software can readily be packaged until many or all of these things are
moved from being defined and checked at build time to being settable in
a configuration file accessed (and checked, if appropriate) at run time.

DATABASE CREATION:

I think the setup.php code that creates the bibledit-web database
probably will need to be made usable as a script to be run at package
installation time, or maybe at first web login to bibledit-web.  Asking
users to point a browser at a URL just to do something non-interactive
seems unfriendly.  The web server needing to be able to delete the
bibledit-web php files (auto-deleting setup.php after running it) looks
like a security weakness; only the server admin should be able to edit
or delete those files, once installed.

LACK OF $(DESTDIR):

I've also found what seems to be the same kind of issue I found earlier
in the bibledit-gtk Makefiles, where an install-data-local target does
not use $(DESTDIR).  This time the issue is in web/Makefile.am where the
four lines under the install-data-local: target need $(DESTDIR) before
$(WEBROOT).

Fixing that still leaves it installing directly into the root of the
default host, /var/www/, which is not allowed, but that's a different
issue, more related to the "configuring too early" problem noted above.

SECURITY:

There is too much chmod -R 0777 going on (both in the Makefiles and then
also in some PHP code) than can be considered safe or secure for an
Internet-facing web server.  World writable files and directories are
almost never needed, and almost always a security risk.  Why would every
user on the web server machine need full access to all of these
bibledit-web files and directories?  Installed on a shared web hosting
server, this could quite easily allow other customers on that server to
do anything they like with your site, including add their own code, run
spambots as you, hand out malware to every unsuspecting user who uses
the bibledit-web site, etc.

I'm not sure that suggesting or assuming a MySQL root pw of "root" is
wise, either :)  If you are going to do setup from PHP, why not have
setup.php prompt for all the database info (host, dbname, adminuser,
adminpw, username, pw) and write some of it (hopefully not the
adminuser/adminpw!) to a config file?  It can do some of that already.

All uses of system() and exec() should probably specify a full path, so
users can't persuade your code to execute *their* chmod instead of the
system one, for instance.

I'd suggest you try to do a detailed security review as soon as
practical.  It seems odd to be using 1024bit ssh keypairs, but also
doing things like "chmod 0777" and assuming a dba password of "root".

INSTALLATION HELP:

The help button points to help/001ubuntu1004server.php but this is
specifically for 0.1, and the codebase is 0.2.  Are there any
differences?  Also, this file says in part:

  If the site is "site.com", then this will be something like:
  http://site.org/bibledit/setup.php

You can use either site.org or site.com, but they need to match :)
Using example.com is common for this kind of text, incidentally.

EMBEDDED LIBRARIES:

bibledit-web seems to have included a copy of the smarty library within
its codebase.  This is not allowed when packaging.  I'll need to change
it to use the system-supplied already-packaged version(s) of smarty and
smarty-gettext (does it actually use smarty-gettext, or just smarty?).

SUMMARY:

As far as I can see, the bibledit-web 0.2 codebase pretty much requires
that it be built from source, locally for each individual installation.
 That is the exact opposite of what packaged software does (build it
once, then distribute the resulting compiled binary package around the
world) :)  Since bibledit-gtk doesn't require this
unique-per-installation build, I'm not sure why bibledit-web does, or
what the benefit of this approach is.  I rather suspect that in trying
to make things "friendly" for people installing it from source, the
software has been made hard or impossible to install as a package.

Hoping we can find a good approach to packaging bibledit-web,

Jonathan