User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 The .htaccess file in the bugzilla root (presumably created by checksetup.pl) contains the following regex error: On line 5: <FilesMatch ^(localconfig.js|localconfig.rdf)$> Should read: <FilesMatch ^(localconfig\.js|localconfig\.rdf)$> There may be other similar errors elsewhere, I have not checked. Reproducible: Didn't try

You're right. Since the patch to bug 70907, checksetup.pl doesn't add this line to your .htaccess file any more. So if you're using version 2.21 or later, you can safely remove this FilesMatch block. (Maybe we should make checksetup.pl remove it?) The attached cares about older versions; it's built against 2.20 but applies to 2.18 and 2.16 as well.

This is pretty minor, because "." means "any character" in a regex. It's too minor to fix for 2.16 or 2.18, and too minor to be a blocker for anything.

The '.' doesn't stop it from working, but it makes .htaccess allow access to more files than we intended (e.g. a potentially sensitive localconfig-js somebody might have written), so if we were a little paranoid, we could make this an (admittedly minor) sec bug :)

(In reply to comment #3) > The '.' doesn't stop it from working, but it makes .htaccess allow access to > more files than we intended (e.g. a potentially sensitive localconfig-js > somebody might have written), so if we were a little paranoid, we could make > this an (admittedly minor) sec bug :) Okay. But we certainly don't file sec bugs against files that aren't actually *in Bugzilla*. :-) Somebody could also make a file called "take-over-my-computer.cgi" and put it in the Bugzilla directory, and that wouldn't really be our concern. :-) So the whole thing still seems pretty minor to me.

Comment on attachment 207444 [details] [diff] [review] Patch 1.0 for the 2.20 branch >+ else { >+ # 2006-01-03 Bug 322190 >+ if ($oldaccess =~ s/\^\(localconfig\.js\|localconfig\.rdf\)\$/\^\(localconfig\\\.js\|localconfig\\\.rdf\)\$/) { >+ $repaired = 1; >+ } >+ if ($repaired) { >+ print "Repairing .htaccess...\n"; >+ open HTACCESS, '>', '.htaccess'; >+ print HTACCESS $oldaccess; >+ close HTACCESS; >+ } This patch looks wrong to me. You should move >+ if ($oldaccess =~ s/\^\(localconfig\.js\|localconfig\.rdf\)\$/\^\(localconfig\\\.js\|localconfig\\\.rdf\)\$/) { >+ $repaired = 1; >+ } before the existing "if ($repaired)".

(In reply to comment #5) No, we'd end up with a duplicated FilesMatch block -- the existing if ($repaired) block adds one of its own. We're doing our repairs here only if the previous repairs happened with an older version of checksetup.pl, adding the FilesMatch block in a broken fashion.

Comment on attachment 207444 [details] [diff] [review] Patch 1.0 for the 2.20 branch (In reply to comment #6) > No, we'd end up with a duplicated FilesMatch block -- the existing if > ($repaired) block adds one of its own. We're doing our repairs here only if the Actually we already end up with two blocks, thanks to bug 319241. Happens when the *.pm blocking is added. This is getting very messy. Having a dedicated block in this file that we can just replace begins to sound very good idea.. I have two blocks and this patch only changed first so that's why I gave r-. Maybe you could strip all incorrect blocks from the file and add a correct one?

Ok... I don't think I can make it work then without potentially conflicting with manually edited .htaccess files...

Bugzilla 2.20 is no longer supported. Retargetting to 2.22.

Now that .htaccess is in the bzr repo, this is no longer an issue.