207 lines
9.2 KiB
Markdown
207 lines
9.2 KiB
Markdown
Sorry if you don't appreciate me lumping all of these patches together.
|
|
|
|
These are various fixes I had to make when installing Ikiwiki. Some are
|
|
due it being a non-Debian system, the others are actual bugs.
|
|
|
|
--- upstream/IkiWiki/Rcs/svn.pm 2006-09-16 01:11:55.000000000 +0100
|
|
+++ main/IkiWiki/Rcs/svn.pm 2006-09-16 01:12:50.000000000 +0100
|
|
@@ -34,7 +34,7 @@
|
|
my $field=shift;
|
|
my $file=shift;
|
|
|
|
- my $info=`LANG=C svn info $file`;
|
|
+ my $info=`svn info $file`;
|
|
my ($ret)=$info=~/^$field: (.*)$/m;
|
|
return $ret;
|
|
} #}}}
|
|
@@ -140,7 +140,7 @@
|
|
if $svn_version =~ /\d\.(\d)\.\d/ && $1 >= 2;
|
|
|
|
my $svn_url=svn_info("URL", $config{srcdir});
|
|
- my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url'`,
|
|
+ my $xml = XMLin(scalar `svn $svn_limit --xml -v log '$svn_url' --config-dir /tmp`,
|
|
ForceArray => [ 'logentry', 'path' ],
|
|
GroupTags => { paths => 'path' },
|
|
KeyAttr => { path => 'content' },
|
|
|
|
The first hunk of this patch is strange. It just failed to work with this
|
|
in place, and it took me a long time to figure it out. I realise what you
|
|
are trying to do, and it still works here as I use a similar LANG anyway.
|
|
|
|
For reference svn version 1.3.1 (r19032), my $LANG=en_GB.utf8, but I'm not
|
|
sure what the CGI was running under.
|
|
|
|
> That's strange. Is the problem to do with setting LANG=C or to do
|
|
> with the way it's set and exported on the same line as the svn info call?
|
|
> Can you reproduce the problem running svn info outside of ikiwiki?
|
|
> --[[Joey]]
|
|
|
|
>> I've now managed to reproduce the problem. I'll try and give some more information.
|
|
>> When going to the Recent Changes link I get
|
|
|
|
[Sat Sep 16 15:16:08 2006] [error] [client xxxx] svn: Can't check path '/home/jw2328/.subversion': Permission denied, referer: http://xxxxx/test/sandbox.html
|
|
[Sat Sep 16 15:16:08 2006] [error] [client xxxx] Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/site_perl/5.8.3/IkiWiki/Rcs/svn.pm line 145., referer: http://xxxx/test/sandbox.html
|
|
[Sat Sep 16 15:16:08 2006] [error] [client xxxxx] svn: Can't check path '/home/jw2328/.subversion': Permission denied, referer: http://xxxx/test/sandbox.html
|
|
[Sat Sep 16 15:16:09 2006] [error] [client xxxx] File does not exist: at /usr/lib/perl5/site_perl/5.8.3/IkiWiki/Rcs/svn.pm line 145, referer: http://xxxx/test/sandbox.html
|
|
[Sat Sep 16 15:16:09 2006] [error] [client xxxx] Premature end of script headers: ikitest, referer: http://xxxx/test/sandbox.html
|
|
|
|
>> which the $svn_url is causing the uninitialised value, due to the
|
|
>> LANG=C it seems, as if I remove it it goes away.
|
|
>> The file does not exist is due to the unreadable .subversion.
|
|
>> echoing the LANG before it is set shows that the variable is normally
|
|
>> empty for the user that is running it.
|
|
|
|
The second removes problems with cannot access /home/$user/.svnsomething in
|
|
the logs. I think this problem was also fatal (I should have reported these
|
|
sooner).
|
|
|
|
I can try and debug these problems if you could suggest some way to do so,
|
|
but I am probably losing the server in a couple of days, so I can't be of too
|
|
much help I'm afraid.
|
|
|
|
> I imagine that passing --config-dir /tmp would be either insecure or
|
|
> would limit ikiwiki use to one user per machine.
|
|
> `--config-dir /etc/subversion` might be better, though still a hack,
|
|
> since a user's real ~/.subversion might be needed to access some repos.
|
|
>
|
|
> Maybe I didn't notice this problem since I have a ~/.subversion
|
|
> everywhere that I've used ikiwiki. Hmm, no, I don't reproduce it, svn
|
|
> happily recreated the directory during an ikiwiki run after I moved it
|
|
> out of the way here. Maybe an issue with old versions of svn? Although
|
|
> AFIACR, svn has auto-created ~/.subversion for years.
|
|
>
|
|
> What's the error message? --[[Joey]]
|
|
|
|
>> `svn: Can't check path '/home/jw2328/.subversion': Permission denied,`
|
|
>> where jw2328 is my usual user.
|
|
>> I have restrictive permissions of 0700 on home dirs on the server,
|
|
>> and the CGI is running as uid apache, euid root. (Not my setup anymore).
|
|
>> The way I had it set up, was jw2328 owning thesource dir, and the svn repo,
|
|
>> with g+sw on them both. I ran sudo ikiwiki --setup though, as I was reluctant
|
|
>> to adjust permissions on my cgi-dir. This seems to be the root of the
|
|
>> problem.
|
|
|
|
----
|
|
|
|
--- IkiWiki/Plugin/search.pm
|
|
+++ IkiWiki/Plugin/search.pm
|
|
@@ -99,7 +99,7 @@
|
|
close TEMPLATE;
|
|
$cgi="$estdir/".IkiWiki::basename($config{cgiurl});
|
|
unlink($cgi);
|
|
- symlink("/usr/lib/estraier/estseek.cgi", $cgi) ||
|
|
+ symlink("/usr/local/libexec/estseek.cgi", $cgi) ||
|
|
error("symlink $cgi: $!");
|
|
} # }}}
|
|
|
|
obviously I'm not asking you to include this patch, but it would
|
|
be good if this sort of thing was configurable (at build time?). I can
|
|
have a go if you like, but I'm not sure what would be acceptable to
|
|
you.
|
|
|
|
> This should be made configurable via an option in %IkiWiki::config,
|
|
> the search plugin could register a getopt hook to handle it. --[[Joey]]
|
|
|
|
>> Like this? <http://jameswestby.net/scratch/estseek.diff>
|
|
|
|
----
|
|
|
|
--- IkiWiki.pm
|
|
+++ IkiWiki.pm
|
|
@@ -734,7 +734,18 @@
|
|
my $page=shift;
|
|
my $spec=shift;
|
|
|
|
- return eval pagespec_translate($spec);
|
|
+ my $pagespec = pagespec_translate($spec);
|
|
+
|
|
+ my $newpagespec;
|
|
+
|
|
+ local($1);
|
|
+ if ($pagespec =~ /(.*)/) {
|
|
+ $newpagespec = $1;
|
|
+ } else {
|
|
+ die "oh";
|
|
+ }
|
|
+
|
|
+ return eval $newpagespec;
|
|
} #}}}
|
|
|
|
sub match_glob ($$) { #{{{
|
|
|
|
This works around a silly, but extremely annoying, taint bug in older
|
|
versions of perl. I'm not sure of the details, but it means that either
|
|
values become tainted from nowhere, or they don't get untainted possibly.
|
|
This also affects backports to sarge. `"oh"` is not going to be very
|
|
informative if that code path is ever taken, but I hope that it never is.
|
|
|
|
> You're not the first person to report a problem here with older versions
|
|
> of perl and pagespec tainting. I suspect that this would work around it:
|
|
return eval possibly_foolish_untaint(pagespec_translate($spec));
|
|
> I'm _very_ uncomfortable putting that in the shipping version of ikiwiki,
|
|
> because pagespecs are potentially _insanely_ dangerous, given how they're
|
|
> evaled and all. The tainting is the only sanity check there is that
|
|
> `pagespec_translate` manages to clean up any possibly harmful perl code
|
|
> in a pagespec. It's good to have belt and suspenders here.
|
|
>
|
|
> For all I know, older versions of perl are keeping it tainted because
|
|
> `pagespec_translate` is somehow broken under old versions of perl and is
|
|
> in fact not fully untainting the pagespec. Ok, probably not, it's more
|
|
> likely that some of the regexps in there don't manage to clear the taint
|
|
> flag with old versions of perl, while still doing a perfectly ok job of
|
|
> sanitising the pagespec.
|
|
>
|
|
> I suppose that the version of perl ($^V) could be checked and the untaint
|
|
> only be called for the old version. Though it seems it would be better
|
|
> to try to debug this some first. Maybe instrumenting `pagespec_translate`
|
|
> with calls to Scalar::Utils's tainted() function and seeing which parts
|
|
> of pagespecs arn't getting untainted would be a good start.
|
|
>
|
|
> --[[Joey]]
|
|
|
|
>> It seems like it is always the (with instrumentation)
|
|
|
|
elsif ($word =~ /^(link|backlink|created_before|created_after|creation_month|creation_year|creation_day)\((.+)\)$/) {
|
|
warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
|
|
$code.=" match_$1(\$page, ".safequote($2).")";
|
|
warn("\$1 tainted=".tainted($1).", \$2 tainted=".tainted($2)." \$code tainted=".tainted($code));
|
|
warn("safequote tainted=".tainted(safequote($2)));
|
|
}
|
|
|
|
>> bit that causes it. With the following trace:
|
|
|
|
$1 tainted=0, $2 tainted=0 $code tainted=0 at IkiWiki.pm line 718.
|
|
$1 tainted=0, $2 tainted=0 $code tainted=1 at IkiWiki.pm line 720.
|
|
safequote tainted=0 at IkiWiki.pm line 721.
|
|
|
|
>> which shows that `$code` appears to become tainted from nowhere.
|
|
>> <http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200509.mbox/%3C3838.431C7D9B.5F152B8F.dev@spamassassin.apache.org%3E>
|
|
>> is what pointed me to find the problem/workaround.
|
|
|
|
|
|
|
|
----
|
|
|
|
As for backports there is a problem with the sarge version of libcgi-session-perl
|
|
and my sslcookie patch (complaints about a missing include file auto/CGI/Session/cookie.al IIRC).
|
|
This file does not and has not ever existed, but it appears to be fixed in
|
|
the backport of libcgi-session-perl that I did. That puts the dependency
|
|
required at somewhere between 3.95-2 and 4.14-1. This could then be added
|
|
to debian/control. It would mean one more package to backport, but stops the
|
|
bug if anyone actually uses my sslcookie option except me.
|
|
|
|
> May as well, done --[[Joey]]
|
|
|
|
>> Thanks.
|
|
|
|
As for backports I managed with
|
|
|
|
* ikiwiki_1.26
|
|
* libcgi-formbuilder-perl_3.03.01-1
|
|
* libcgi-session-perl_4.14-1
|
|
|
|
backported to sarge, with bpo in sources.list. This only covers Depends: though,
|
|
for instance hyperestraier needs to be backported, which I haven't got
|
|
round to yet as there is a chain to do.
|
|
|