Merge branch 'master' into autoconfig

Conflicts:

	IkiWiki/Plugin/git.pm
	debian/changelog
	po/ikiwiki.pot

6 files changed, 129 insertions, 30 deletions

diff --git a/doc/plugins/autoindex.mdwn b/doc/plugins/autoindex.mdwn
index 66e0163c2..03e2d12f3 100644
--- a/doc/plugins/autoindex.mdwn
+++ b/doc/plugins/autoindex.mdwn
@@ -2,6 +2,6 @@
 [[!tag type/useful]]
 
 This plugin searches for [[SubPages|ikiwiki/subpage]] with a missing parent
-page, and generates a parent page for them. The generated page content is
-controlled by the autoindex [[template|wikitemplates]], which by default,
-uses a [[map]] to list the SubPages.
+page, and generates the parent pages. The generated page content is
+controlled by the `autoindex.tmpl` [[template|wikitemplates]], which by
+default, uses a [[map]] to list the SubPages.
diff --git a/doc/plugins/contrib/unixauth.mdwn b/doc/plugins/contrib/unixauth.mdwn
index 12f885c33..2de6fc51f 100644
--- a/doc/plugins/contrib/unixauth.mdwn
+++ b/doc/plugins/contrib/unixauth.mdwn
@@ -3,9 +3,36 @@
 
 This plugin authenticates users against the Unix user database. It presents a similar UI to [[plugins/passwordauth]], but simpler, as there's no need to be able to register or change one's password.
 
-[pwauth](http://www.unixpapa.com/pwauth/) must be installed and working. In particular, it must be configured to recognize the UID of the calling web server, or authentication will always fail. Set `pwauth_path` to the full path of your pwauth binary.
+To authenticate, either [checkpassword](http://cr.yp.to/checkpwd.html) or [pwauth](http://www.unixpapa.com/pwauth/) must be installed and configured. `checkpassword` is strongly preferred. If your web server runs as an unprivileged user -- as it darn well should! -- then `checkpassword` needs to be setuid root. (Or your ikiwiki CGI wrapper, I guess, but don't do that.) Other checkpassword implementations are available, notably [checkpassword-pam](http://checkpasswd-pam.sourceforge.net/).
 
-As [with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike with passwordauth, sniffing these credentials can get an attacker much further than mere wiki access. SSL with this plugin is a __must__.
+Config variables that affect the behavior of `unixauth`:
+
+* `unixauth_type`: defaults to unset, can be "checkpassword" or "pwauth"
+* `unixauth_command`: defaults to unset, should contain the full path and any arguments
+* `unixauth_requiressl`: defaults to 1, can be 0
+* `sslcookie`: needs to be 1 if `unixauth_requiressl` is 1 (perhaps this should be done automatically?)
+
+__Security__: [As with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike passwordauth, sniffing `unixauth` credentials can get an attacker much further than mere wiki access. Therefore, this plugin defaults to not even _displaying_ the login form fields unless we're running under SSL. Nobody should be able to do anything remotely dumb until the admin has done at least a little thinking. After that, dumb things are always possible. ;-)
+
+`unixauth` tests for the presence of the `HTTPS` environment variable. `Wrapper.pm` needs to be tweaked to pass it through; without that, the plugin fails closed.
+
+[[!toggle id="diff" text="Wrapper.pm.diff"]]
+
+[[!toggleable id="diff" text="""
+
+    --- Wrapper.pm.orig 2008-07-29 00:09:10.000000000 -0400
+    +++ Wrapper.pm
+    @@ -28,7 +28,7 @@ sub gen_wrapper () { #{{{
+        my @envsave;
+        push @envsave, qw{REMOTE_ADDR QUERY_STRING REQUEST_METHOD REQUEST_URI
+                       CONTENT_TYPE CONTENT_LENGTH GATEWAY_INTERFACE
+    -                  HTTP_COOKIE REMOTE_USER} if $config{cgi};
+    +                  HTTP_COOKIE REMOTE_USER HTTPS} if $config{cgi};
+        my $envsave="";
+        foreach my $var (@envsave) {
+                $envsave.=<<"EOF"
+
+"""]]
 
 [[!toggle id="code" text="unixauth.pm"]]
 
@@ -40,13 +67,26 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
         }
     
         my $ret=0;
-        if (! exists $config{pwauth_path}) {
-                $config{pwauth_path}="/usr/libexec/pwauth";
+        if (! exists $config{unixauth_type}) {
+                # admin needs to carefully think over his configuration
+                return 0;
+        }
+        elsif ($config{unixauth_type} eq "checkpassword") {
+                open UNIXAUTH, "|$config{unixauth_command} true 3<&0" or die("Could not run $config{unixauth_type}");
+                print UNIXAUTH "$user\0$password\0Y123456\0";
+                close UNIXAUTH;
+                $ret=!($?>>8);
+        }
+        elsif ($config{unixauth_type} eq "pwauth") {
+                open UNIXAUTH, "|$config{unixauth_command}" or die("Could not run $config{unixauth_type}");
+                print UNIXAUTH "$user\n$password\n";
+                close UNIXAUTH;
+                $ret=!($?>>8);
+        }
+        else {
+                # no such authentication type
+                return 0;
         }
-        open PWAUTH, "|$config{pwauth_path}" or die("Could not run pwauth");
-        print PWAUTH "$user\n$password\n";
-        close PWAUTH;
-        $ret=!($?>>8);
     
         if ($ret) {
             my $userinfo=IkiWiki::userinfo_retrieve();
@@ -69,6 +109,17 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
         my $session=$params{session};
         my $cgi=$params{cgi};
     
+        # if not under SSL, die before even showing a login form,
+        # unless the admin explicitly says it's fine
+        if (! exists $config{unixauth_requiressl}) {
+                $config{unixauth_requiressl} = 1;
+        }
+        if ($config{unixauth_requiressl}) {
+            if ((! $config{sslcookie}) || (! exists $ENV{'HTTPS'})) {
+                die("SSL required to login. Contact your administrator.<br>");
+            }
+        }
+    
         if ($form->title eq "signin") {
                 $form->field(name => "name", required => 0);
                 $form->field(name => "password", type => "password", required => 0);
@@ -93,6 +144,7 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
                                 );
                         }
                         
+                        # XXX is this reachable? looks like no
                         elsif ($submittype eq "Login") {
                                 $form->field( 
                                         name => "name",
diff --git a/doc/plugins/contrib/unixauth/discussion.mdwn b/doc/plugins/contrib/unixauth/discussion.mdwn
new file mode 100644
index 000000000..c4f5ff269
--- /dev/null
+++ b/doc/plugins/contrib/unixauth/discussion.mdwn
@@ -0,0 +1,32 @@
+The security of this plugin scares me. As noted in the plugin
+documentation, you basically have to use it with SSL, since snooping on the
+login password doesn't give you an essentially useless account -- it gives
+you an actual account on the machine!
+
+Also, apparently pwauth defers *all* auth attempts if one fails, and it
+does this by using a lock file, and sleeping after a failed auth attempt.
+Which is needed to avoid brute-forcing, since this is a significant
+password.. but how will that interact with ikiwiki? Well, ikiwiki _also_
+uses a lock file. So, at a minimum, someone can not only try to brute-force
+the pwauth password, but the ikiwiki processes that stack up due to that
+will also keep ikiwiki's lock held. Which basically DOSes the wiki for
+everyone else; noone else can try to log in, or log out, or edit a page,
+all of which require taking the lock.
+
+So I don't think I'll be accepting this plugin into ikiwiki itself..
+--[[Joey]]
+
+Thanks for the comments. That's definitely an undesirable interaction between pwauth and ikiwiki; in my current application it wouldn't be a serious problem, but I'd like this plugin to be general-purpose and safe enough for inclusion in ikiwiki. It's the system-users-are-wiki-users idea I'm married to here, not pwauth itself; can you suggest another approach I might take?
+-- [[schmonz]]
+
+> Have you considered using [[plugins/httpauth]] and then the appropriate apache module?  There are apache modules like [mod_authnz_external](http://unixpapa.com/mod_auth_external.html) that might help.  The advantage of these solutions is that they usually make the security implications explicit.  -- Will
+
+Actually, yes. That's how I made sure I had pwauth working to begin with. I'm partial to the form-based approach because I'm not aware of any way to reliably "log out" browsers from HTTP authentication. If that *is* reliably possible, then I worked way too hard for no reason. ;-)
+-- [[schmonz]]
+
+I've added support for [checkpassword](http://cr.yp.to/checkpwd/interface.html), since those generally don't have any rate-limiting cleverness to interfere with ikiwiki's, and made a few other changes. Please check out the plugin docs again and let me know if this is closer to being acceptable.
+-- [[schmonz]]
+
+> I actually think that the rate limiting is a good thing. After all,
+> ikiwiki doesn't do its own login rate limiting. Just need to find a way
+> to disentangle the two locks. --[[Joey]]
diff --git a/doc/plugins/creole.mdwn b/doc/plugins/creole.mdwn
index b6861ab26..ed347e2c5 100644
--- a/doc/plugins/creole.mdwn
+++ b/doc/plugins/creole.mdwn
@@ -12,5 +12,5 @@ wiki markup formats, so should be fairly easy to guess at. There is also a
 [CheatSheet](http://www.wikicreole.org/wiki/CheatSheet).
 
 Links are standard [[WikiLinks|ikiwiki/WikiLink]]. Links and
-[[PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded,
+[[ikiwiki/PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded,
 since this happens before the creole format is processed.
diff --git a/doc/plugins/creole/discussion.mdwn b/doc/plugins/creole/discussion.mdwn
new file mode 100644
index 000000000..a31f9cf83
--- /dev/null
+++ b/doc/plugins/creole/discussion.mdwn
@@ -0,0 +1,7 @@
+I've installed Text::WikiCreole 0.05 and enabled the plugin, but I get an error when rebuilding the wiki: `Undefined subroutine &IkiWiki::Plugin::creole::creole_custombarelinks called at /usr/pkg-20080723/lib/perl5/vendor_perl/5.8.0/IkiWiki/Plugin/creole.pm line 23`. Is there a newer Text::WikiCreole I'm not finding online?
+-- [[schmonz]]
+
+> There's a patch in the debian package of libtext-wikicreole-perl that
+> adds that option. I'm not sure what the status of it being released
+> upstream is, though IIRC I was assured it would not be a problem.
+> --[[Joey]]
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 04b6ea8e9..77210d35c 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -128,26 +128,34 @@ of a plugin.
 
         hook(type => "preprocess", id => "foo", call => \&preprocess);
 
-Replace "foo" with the command name that will be used inside brackets for
-the preprocessor directive.
-
-Each time the directive is processed, the referenced function (`preprocess`
-in the example above) is called, and is passed named parameters. A "page"
-parameter gives the name of the page that embedded the preprocessor
-directive, while a "destpage" parameter gives the name of the page the
-content is going to (different for inlined pages), and a "preview"
-parameter is set to a true value if the page is being previewed. All
-parameters included in the directive are included as named parameters as
-well. Whatever the function returns goes onto the page in place of the
+Replace "foo" with the command name that will be used for the preprocessor
 directive.
 
-An optional "scan" parameter, if set to a true value, makes the hook be
-called during the preliminary scan that ikiwiki makes of updated pages,
-before begining to render pages. This parameter should be set to true if
-the hook modifies data in `%links`. Note that doing so will make the hook
-be run twice per page build, so avoid doing it for expensive hooks. (As an
-optimisation, if your preprocessor hook is called in a void contets, you
-can assume it's being run in scan mode.)
+Each time the directive is processed, the referenced function (`preprocess`
+in the example above) is called. Whatever the function returns goes onto
+the page in place of the directive. Or, if the function aborts using
+`error()`, the directive will be replaced with the error message.
+
+The function is passed named parameters. First come the parameters set
+in the preprocessor directive. These are passed in the same order as
+they're in the directive, and if the preprocessor directive contains a bare
+parameter (example: `\[[!foo param]]`), that parameter will be passed with
+an empty value.
+
+After the parameters from the preprocessor directive some additional ones
+are passed: A "page" parameter gives the name of the page that embedded the
+preprocessor directive, while a "destpage" parameter gives the name of the
+page the content is going to (different for inlined pages), and a "preview"
+parameter is set to a true value if the page is being previewed.
+
+If `hook` is passed an optional "scan" parameter, set to a true value, this
+makes the hook be called during the preliminary scan that ikiwiki makes of
+updated pages, before begining to render pages. This should be done if the
+hook modifies data in `%links`. Note that doing so will make the hook be
+run twice per page build, so avoid doing it for expensive hooks. (As an
+optimisation, if your preprocessor hook is called in a void context, you
+can assume it's being run in scan mode, and avoid doing expensive things at
+that point.)
 
 Note that if the [[htmlscrubber]] is enabled, html in
 [[ikiwiki/PreProcessorDirective]] output is sanitised, which may limit what