This fixes a problem sgran saw on alioth. Apparently nss-db sets errno to
ENOENT as a side effect trying to read an optional file, but succeeds
anyway. Then, somehow, errno remains set across the library calls made by
$).
So unset it first as a workaround; there's probably a nss-db, libc, and/or
perl bug underneath.
Something has changed in CGI.pm in perl 5.10. It used to not care
if STDIN was opened using :utf8, but now it'll mis-encode utf-8 values
when used that way by ikiwiki. Now I have to binmode(STDIN) before
instantiating the CGI object.
In 57bba4dac1, I changed from decoding
CGI::Formbuilder fields to utf-8, to decoding cgi parameters before setting
up the form object. As of perl 5.10, that approach no longer has any effect
(reason unknown). To get correctly encoded values in FormBuilder forms,
they must once again be decoded after the form is set up.
As noted in 57bba4da, this can cause one set of problems for
formbuilder_setup hooks if decode_form_utf8 is called before the hooks, and
a different set if it's called after. To avoid both sets of problems, call
it both before and after. (Only remaining problem is the sheer ugliness and
inefficiency of that..)
I think that these changes will also work with older perl versions, but I
haven't checked.
Also, in the case of the poll plugin, the cgi parameter needs to be
explcitly decoded before it is used to handle utf-8 values. (This may have
always been broken, not sure if it's related to perl 5.10 or not.)
* Add a Bundle::Ikiwiki to the source for use with CPAN to install *all*
the modules ikiwiki can use.
* Add a cpan directory containing a CPAN::MyConfig that can ease use of
CPAN to install in a home directory on shared hosting providers.
* With these changes, it's pretty easy to install onto nearlyfreespeech.net
and probably other shared hosting providers like dreamhost. Added
a tip page documentng the process for nearlyfreespeech.
This manifested as wikis with no locked pages treating them all as locked.
The bug was introduced in version 2.41.
Medium urgency upload due to above fix.
The fix involved embedding the session id in the forms, and not allowing the
forms to be submitted if the embedded id does not match the session id.
In the case of the preferences form, if the session id is not embedded,
then the CGI parameters are cleared. This avoids a secondary attack where the
link to the preferences form prefills password or other fields, and
the user hits "submit" without noticing these prefilled values.
In the case of the editpage form, the anonok plugin can allow anyone to edit,
and so I chose not to guard against CSRF attacks against users who are not
logged in. Otherwise, it also embeds the session id and checks it.
For page editing, I assume that the user will notice if content or commit
message is changed because of CGI parameters, and won't blndly hit save page.
So I didn't block those CGI paramters. (It's even possible to use those CGI
parameters, for good, not for evil, I guess..)
The only other CSRF attack I can think of in ikiwiki involves the poll plugin.
It's certianly possible to set up a link that causes the user to unknowingly
vote in a poll. However, the poll plugin is not intended to be used for things
that people would want to attack, since anyone can after all edit the poll page
and fill in any values they like. So this "attack" is ignorable.
During refresh of a wiki with 800 files, loadindex was using more total
time than any other function, and saveindex was also in the top ten.
Rewriting them to use Storable makes them three times as fast.
0.7 seconds is saved on my laptop in profiling mode.
About 12% of ikiwiki runtime was spent in pagespec_match. It was evaling
the same pagespec code over and over again. This changes pagespec_translate
to return memoized, precompiled functions that can be called to match against
a given pagespec.
This also allows getting rid of the weird variable scoping trick that had
to be in effect for pagespec_translate to be called -- the variables are
now just fed into the function it returns.
On my laptop, this drops build time for the docwiki from about 60 to 50
seconds.
Markdown is slow. Especially if it has to process an enormous page. The
most common enormous page is currently the recentchanges page, which gets
processed a lot, and contains very little actual markdown. Most of it is a
big <div>, which markdown skips ... slowly.
This is a rather sick optimisation to work around markdown's speed issues.
Now inline inserts a small, dummy div, allows markdown to quickly render
the actual page content, then replaces the dummy with the actual inlined
pages later.
Results: Rendering just a recentchanges page, with diffs included, dropped
from 4.5 seconds to 2.7 seconds on my laptop. Building the entire wiki
dropped from 46.6 seconds to 39.5 seconds.
(It would be better if inline were a *post*-processor directive.)
set to the destination page. This avoids need for hacks to munge the urls
in preview mode, which fixes several bugs.
* Several destpage fixes in plugins.
correct, and it's certianly not correct now, since the wiki is locked
before rcs_commit is ever called, and should not be unlocked by
rcs_commit either.
Markdown is such a splintered mess.. The current debian package provides
only Text::Markdown::Markdown, while all versions of Text::Markdown support
Text::Markdown::markdown, and old versions also support the capitalised version,
while new ones don't.
It's getting to the point where `grep /markdown/i %symbol_table` is the only
sane way to figure out what function to call..
* rcs_diff is a new function that rcs modules should implement.
* Implemented rcs_diff for git, svn, and tla (tla version untested).
Mercurial and monotone still todo.
Add special handling for <meta name="robots" ...> which needs not be
scrubbed as it's harmless.
Signed-off-by: martin f. krafft <madduck@madduck.net>
(cherry picked from commit b15d0299a7f7b147e89d8a202d6cca1c21491af2)
As was already done for linkfication, links generated in a prevew page
are relative to the top of the wiki, so it has to be told that the destpage
is there.
I was using "" to indicate this, but that may confuse some preprocessor
plugins, which treat parameters with an empry value specially (sparkline is one
such). Instead, use "/", which is more accurate anyway and works just as well.
which forced a scan of the page to make available metadata that
appeared after the inline directive. Problem is that scan made it forget
about any other files rendered due to the page. The scan also turns out
to be unnecessary now, since meta persistently stores state and it's
always available. So it was just removed.
Joey Hess
martin f. krafft
Adeodato Simó