responses

diff --git a/doc/patchqueue/various_fixes.mdwn b/doc/patchqueue/various_fixes.mdwn
index 9ffd17b30427a3d17d459b47ab7d021c3a353909..8de4974e47ca194a56698f0c3bd69c5cfa6e6deb 100644 (file)
--- a/doc/patchqueue/various_fixes.mdwn
+++ b/doc/patchqueue/various_fixes.mdwn
@@ -31,6 +31,11 @@ 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]]
+
 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). 
@@ -39,6 +44,21 @@ 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]]
+
+----
+
     --- IkiWiki/Plugin/search.pm
     +++ IkiWiki/Plugin/search.pm
     @@ -99,7 +99,7 @@
@@ -55,6 +75,11 @@ 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]]
+
+----
+
     --- IkiWiki.pm
     +++ IkiWiki.pm
     @@ -734,7 +734,18 @@
@@ -84,6 +109,32 @@ 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]]
+
+----
+
 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 
@@ -92,6 +143,8 @@ 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]]
+
 As for backports I managed with 
 
  * ikiwiki_1.26