Closed Bug 322190 Opened 19 years ago Closed 12 years ago

error in regex in .htaccess files

Categories

(Bugzilla :: Installation & Upgrading, defect)

defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

Details

Attachments

(1 file)

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.
Assignee: installation → wurblzap
Status: UNCONFIRMED → ASSIGNED
Attachment #207444 - Flags: review?
Flags: blocking2.20.1?
Flags: blocking2.18.5?
Flags: blocking2.16.11?
OS: Linux → All
Hardware: Other → All
Target Milestone: --- → Bugzilla 2.16
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.
Flags: blocking2.20.1?
Flags: blocking2.20.1-
Flags: blocking2.18.5?
Flags: blocking2.18.5-
Flags: blocking2.16.11?
Flags: blocking2.16.11-
Target Milestone: Bugzilla 2.16 → Bugzilla 2.20
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?
Attachment #207444 - Flags: review? → review-
Ok... I don't think I can make it work then without potentially conflicting with manually edited .htaccess files...
Assignee: wurblzap → installation
Status: ASSIGNED → UNCONFIRMED
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bugzilla 2.20 is no longer supported. Retargetting to 2.22.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Target Milestone: Bugzilla 2.22 → ---
Depends on: 560733
Now that .htaccess is in the bzr repo, this is no longer an issue.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: