Reply inline: On Mon, November 26, 2007 11:42 am, MJ Ray wrote:

"Thomas Dukleth" <kohadevel@agogme.com> 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