Closed
Bug 322190
Opened 19 years ago
Closed 12 years ago
error in regex in .htaccess files
Categories
(Bugzilla :: Installation & Upgrading, defect)
Bugzilla
Installation & Upgrading
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugzilla, Unassigned)
References
Details
Attachments
(1 file)
1.27 KB,
patch
|
wicked
:
review-
|
Details | Diff | Splinter Review |
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
Comment 1•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking2.20.1?
Flags: blocking2.18.5?
Flags: blocking2.16.11?
OS: Linux → All
Hardware: Other → All
Target Milestone: --- → Bugzilla 2.16
Comment 2•19 years ago
|
||
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
Comment 3•19 years ago
|
||
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 :)
Comment 4•19 years ago
|
||
(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 5•19 years ago
|
||
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)".
Comment 6•19 years ago
|
||
(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 7•19 years ago
|
||
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-
Comment 8•19 years ago
|
||
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
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•16 years ago
|
||
Bugzilla 2.20 is no longer supported. Retargetting to 2.22.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Updated•16 years ago
|
Target Milestone: Bugzilla 2.22 → ---
Comment 10•12 years ago
|
||
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.
Description
•