Re: [Koha-devel] Issues for README.txt and Makefile.PL

[Thomas Dukleth]

Reply inline:


On Mon, November 26, 2007 11:42 am, MJ Ray wrote:
> "Thomas Dukleth" <address@hidden> wrote: [...]
>> As I was preparing some proposed fixes, Joshua Ferraro informed me that
>> there are various pending fixes from a few people.  Some of the pending
>> fixes will not be pushed up to the Koha git repository because they
>> conflict with other more complete fixes.  [...]
>
> That seems like the wrong solution to me.  If people aren't creating
> and pushing unannounced fixes to the main repo fast enough, the
> conflicts are their lookout IMO.  For example, I didn't know Galen
> Charlton was also working on the PL_FILES problems until your email.

1.  SHARING OF COMMITS.

There is an issue that there is no efficient mechanism for seeing what
others have committed until the commits have been approved and pushed to
the main repository.  A mechanism needs to be provided at some point for
sharing people's local git repositories and allowing anyone to see commits
pending for the main repository.  I do not suggest that this needs
attention now but should be well considered when there is time to do so.

This might be nothing more than just a listing of links to various
contributors public local Koha git repositories, which would have a little
extra value if gitweb has been applied to them.  Cloning them on koha.org
is another possibility.

The absence of such a system has not yet been a serious issue for me
personally, but I see the prospect that collaborative work may be slowed
at some future point without some system for sharing work which may not
even be ready to be pushed up to the main repository.


2.  THIS CASE.

The presumption for this particular case was that conflicts would be
likely, therefore, not everyone's fixes would be pushed up to the main
repository.

More significantly for this case, the suggestion to me was that with so
many people working on the installer I could better use my time by working
on something else and merely sharing my thoughts with those taking the
lead on the installer.


3.  DEBIAN PACKAGES.

>
> A few comments on the other aspects:
>
>> [...] Vincent Danjean has some supplementary Debian packages at
>> http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html and
>> MJ
>> Ray has some at http://serene.ttllp.co.uk/~mjr/ .  At some point, these
>> should be placed in repository for apt to use.
>
> They will be placed in the main repositories.  Vincent Danjean has
> pushed some packages to pkg-perl just this weekend.
>

I assume that they will be in Debian testing at this point.  Will they
also be provided for apt in a manner tied to Debian Etch via backports or
an independent Etch based repository?


4.  FILE GLOBBING.

>> Changing general file globbing from * to *.* for using the '.' in
>> filenames can fix that problem.  However, that solution is not robust if
>> files are not in *.* form and at least needs a specific correction for
>> .htaccess as the only file which does not match the pattern.
>
> A better fix might be to check that glob returns are files with -f or
> at least ! -d.

Thanks for that correction.

Unusually for me, I did not persist until I found the correct
documentation for glob.  I only spent a few seconds in a couple of Perl
references which did not list any options other than simple pattern
matching expressions.  I believe that glob derives it function externally
to Perl but I still did not take the time to look.


5.  FILE OWNERSHIP.

>> The webserver user should be read and ownership of the necessary files
>> should be changed to the webserver user when running make install.
>
> Why?  That seems like a serious security risk, leaving the web
> application able to change the file-based configuration if exploited.
>
> I think that is one thing which should be left to defaults, with the
> sysadmin tightening things if needed.
>

I did not put that correctly.  I should have said group ownership.  The
group owner should not have permission to change files which the group
owner does not need to change.

The installation process should be able to produce a working Koha
installation with the least manual configuration necessary.  The more
obstacles required to see a test installation of Koha running well,
however minor, the less widespread interest in using Koha is likely to be.
 [I do not mean that Koha should have a silly installation which presumes
that the person installing does not need to know anything.  That would not
happen with Koha, although, I suspect such simple installations help the
adoption of some MS Window ILS systems.]


6.  HTTPD CONFIGURATION.

6.1.  PERMISSIONS.

>> Using the ScriptAlias directives is considered a security vulnerability.
>
> By whom?  It's not mentioned in
> http://httpd.apache.org/docs/2.2/howto/cgi.html
> - in fact, it seems to suggest the reverse.
>

I do not have any obvious authority to identify readily available.  I
believe that the problem as I have seen it described is that ScriptAlias
is too permissive in what it allows.

I realised just after I sent this message that I had forgotten to include
strictly limited directory based permissions.  I believe that AddHandler
cgi-script .pl or something similar which only provides for executing
explicitly provided file extensions is at least a little safer than
ScriptAlias.

>> Alias directives, rewrite rules or some other more secure method should
>> be
>> substituted for ScriptAlias directives.
>


6.2.  EXTRA REQUIREMENTS.

> Rewrite rules would add extra requirements for Koha hosting.  Not sure
> whether that's a problem or not.

Rewrite rules would add an extra requirement so they should perhaps be an
included option even if many may prefer them.  Some rewrite rules are
currently provided by default.

The most flexible solution may be to have the user select preferences in
Makefile.PL for how to have the default koha-httpd.conf configured.  Other
options should still be available as comments if the user wants to change
something.

Minimal options should be possible but more powerful options should be
available.

[...]


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
212-674-3783