The input to filter hooks is meant to be the content of a source file
on disk. If we only filter once per (page, destpage) pair, and a page
is inlined into the same destpage more than once, then the second
occurrence will render as the result of htmlizing .po source as if
it was Markdown (or whatever the type of the corresponding master page
is), which is never going to end well.
The alreadyfiltered mechanism was added in commit 1e874b3f to avoid
preprocessing loops, but I'm not sure where it could lead to a loop:
filter hooks are only called from IkiWiki::filter, which is only called
on page content from disk or on proposed content being previewed.
According to <https://bugs.debian.org/911356#41>, deleting the
alreadyfiltered mechanism resolves the problem, as well as simplifying
the code.
Closes: #911356
Tested-by: intrigeri
CGI::FormBuilder->field has behaviour similar to the CGI.pm misfeature
we avoided in f4ec7b0. Force it into scalar context where it is used
in an argument list.
This prevents two (relatively minor) commit metadata forgery
vulnerabilities:
* In the comments plugin, an attacker who was able to post a comment
could give it a user-specified author and author-URL even if the wiki
configuration did not allow for that, by crafting multiple values
to other fields.
* In the editpage plugin, an attacker who was able to edit a page
could potentially forge commit authorship by crafting multiple values
for the rcsinfo field.
The remaining plugins changed in this commit appear to have been
protected by use of explicit scalar prototypes for the called functions,
but have been changed anyway to make them more obviously correct.
In particular, checkpassword() in passwordauth has a known prototype,
so an attacker cannot trick it into treating multiple values of the
name field as being the username, password and field to check for.
OVE-20161226-0001
Previously, prune("wiki/srcdir/sandbox/test.mdwn") could delete srcdir
or even wiki, if they happened to be empty. This is rarely what you
want: there's usually some base directory (destdir, srcdir, transientdir
or another subdirectory of wikistatedir) beyond which you do not want to
delete.
Foo->Bar->can("method") works just as well, even if Foo::Bar is not
loaded. Using UNIVERSAL::can is deprecated.
But, I was unable to easily eliminate conditional.pm's use of UNIVERSAL::can
Oddly, this hadn't caused any visible breakage. Possibly inline,
which is the only thing to use targetpage, resolves the function
to the "real" one before po gets loaded?
If the inline plugin is not being loaded, or is perhaps loaded after po
(when IkiWiki::Setup::getsetup loads all the plugins, for example),
po should not inject its custom rootpage sub, as that will lead to a
redefinition error message when inline loads.
The lack of $from will probably hurt setups using po_link_to = current,
but at least we can fix the blocker bug that prevents any wiki using the po
plugin to build.
The po rescan hook re-runs the scan hooks, and runs the preprocess ones in scan
mode, both on the po-to-markup converted content. This way, plugins such as meta
are given a chance to gather correct information, rather than ugly/buggy escaped
data it did gather from unconverted PO files.
This reverts commit 4cf185e781.
That commit broke t/po.t (probably the test case only is testing too
close the the old implementation and needs correcting).
Also, we have not decided how to want to represent it yet, so I'm not
ready for this change.
Conflicts:
IkiWiki/Plugin/po.pm
doc/plugins/po.mdwn
... after having audited the po4a Xml and Xhtml modules for security issues.
Signed-off-by: intrigeri <intrigeri@boum.org>
(cherry picked from commit a128c256a5)
Set it to true every time IkiWiki::filter is called on a full page's content.
This is a much nicer solution, for the po plugin, than previous whitelisting
using caller().
Simon McVittie
Joey Hess
Mesar Hameed
Joey Hess
intrigeri