If for some reason you want to create <meta name="date" content="12345">,
this now requires [[!meta name="date" content="12345"]].
Signed-off-by: Simon McVittie <smcv@debian.org>
Unconditionally passing arbitrary numbers as flags turns out to be a
bad idea, because some of the "unused" values have historically had
side-effects internal to libdiscount. Detect whether the known flags
work by rendering short Markdown snippets the first time we htmlize,
checking whether each known flag is both necessary and sufficient.
Signed-off-by: Simon McVittie <smcv@debian.org>
An empty coder name used to detect the format implicitly, but has been
interpreted as a literal part of the filename since ImageMagick 6.9.8-3.
In newer versions, there does not seem to be any way to indicate that
a filename containing ':' is to be taken literally without first
knowing the decoder to use.
Signed-off-by: Simon McVittie <smcv@debian.org>
The Discount package in Debian historically enabled fenced code blocks,
PHP Markdown Extra-style definition lists, and an expanded character
set for tag names. Since Discount 2.2.0 those are runtime settings, so
enable them. Unfortunately Text::Markdown::Discount doesn't yet expose
the necessary constants:
https://rt.cpan.org/Public/Bug/Display.html?id=124188
The IDANCHOR option was historically also enabled in Debian, but is not
enabled here because ikiwiki does not enable the TOC option, and
IDANCHOR does nothing without TOC.
Closes: #888055
* emailauth: Fix cookie problem when user is on https and the cgiurl
uses http, by making the emailed login link use https.
* passwordauth: Use https for emailed password reset link when user
is on https.
Not entirely happy with this approach, but I don't currently see a
better one.
I have not verified that the passwordauth change fixes any problem,
other than the user getting a http link when they were using https.
The emailauth problem is verified fixed by this commit.
This commit was sponsored by Michael Magin.
This can happen if the user goes directly to /ikiwiki.cgi?do=login and
logs in, since nothing redirected them to there, there's no postsignin
value set. It can also happen when cookies are disabled, or perhaps
other problems.
Since git 2.11, git has stored the proposed push in a "quarantine
area" until it is accepted by the pre-receive hook, and passed
extra environment variables to the pre-receive hook so that it can
read objects from the quarantine area.
This fixes untrusted push on modern git versions.
Signed-off-by: Simon McVittie <smcv@debian.org>
On GNU/Linux, it isn't declared in stdio.h unless we define
_GNU_SOURCE, which we don't; using the implicit declaration risks
crashes on platforms where sizeof(pointer) != sizeof(int). On other
platforms it isn't guaranteed to exist at all.
Signed-off-by: Simon McVittie <smcv@debian.org>
Due to the use/abuse of CGI::Session to generate a token for the login
process, a new session database was created for each login, and left behind
afterwards. While each file is small, with many logings this could bloat
the size of /tmp significantly. Fixed by making CGI::Session write to
/dev/null, since there does not seem to be a way to entirely prevent the
writing.
This commit was sponsored by Henrik Riomar on Patreon.
Those were not in the original html5 spec, but have been added in the
whatwg html living standard and have wide browser support.
This commit was sponsored by John Peloquin on Patreon.
savestate is not the right place to write wiki content, and in particular
this breaks websetup if osm's dependencies are not installed, even if
the osm plugin is not actually enabled. (Closes: #719913)
This is not a full solution: it should be possible to render the PoI files
for only the maps that changed, from the format, changes or rendered
hook. However, getting that right would require more understanding of
this plugin, and this version is enough to not break websetup. This
version is the closest correct hook to the one where this previously
took place.
This still smuggles it past the sanitize step, but avoids having
other plugins that want to capture text content without markup
(notably toc) see the CSS as if it was text content.
reasoning: if headings have identifiers, they are probably more useful
anchors than the automatically generated anchors we build in the toc
plugin. this can happen if, for example, you use the `multimarkdown`
plugin, which inserts `id` tags for every header it encounters. this
also leverages the `headinganchors` plugin nicely.
keeps backwards-compatibility with old toc-generated #indexXhY
anchors.
This avoids misinterpreting initials ("C. S. Lewis was an author"),
the abbreviation for Monsieur ("M. Descartes was a philosopher") and
German page numbering ("S. 42") as ordered lists if they happen to
begin a line.
This only affects the default Discount implementation: Text::Markdown
and Text::MultiMarkdown do not have this feature anyway. A new
mdwn_alpha_list option can be used to restore the old interpretation.
The Perl binding defaults to MKD_NOHEADER|MKD_NOPANTS anyway, but
making them explicit means we can use other flags of our choice,
and makes it easier to justify why those flags are appropriate.
ikiwiki's web interface does not currently have UI for removing
multiple pages simultaneously, but the remove plugin is robust
against doing so. Use a clearer idiom to make that obvious.
These instances of code similar to OVE-20170111-0001 are not believed
to be exploitable, because defined(), length(), setpassword(),
userinfo_set() and the binary "." operator all have prototypes that
force the relevant argument to be evaluated in scalar context. However,
using a safer idiom makes mistakes less likely.
(cherry picked from commit 69230a2220f673c66b5ab875bfc759b32a241c0d)
Calling CGI::FormBuilder::field with a name argument in list context
returns zero or more user-specified values of the named field, even
if that field was not declared as supporting multiple values.
Passing the result of field as a function parameter counts as list
context. This is the same bad behaviour that is now discouraged
for CGI::param.
In this case we pass the multiple values to CGI::Session::param.
That accessor has six possible calling conventions, of which four are
documented. If an attacker passes (2*n + 1) values for the 'name'
field, for example name=a&name=b&name=c, we end up in one of the
undocumented calling conventions for param:
# equivalent to: (name => 'a', b => 'c')
$session->param('name', 'a', 'b', 'c')
and the 'b' session parameter is unexpectedly set to an
attacker-specified value.
In particular, if an attacker "bob" specifies
name=bob&name=name&name=alice, then authentication is carried out
for "bob" but the CGI::Session ends up containing {name => 'alice'},
an authentication bypass vulnerability.
This vulnerability is tracked as OVE-20170111-0001.
(cherry picked from commit e909eb93f4530a175d622360a8433e833ecf0254)
git_sha1 already puts "--" before its arguments, so
git_sha1_file($dir, 'doc/index.mdwn')
would have incorrectly invoked
git rev-list --max-count=1 HEAD -- -- doc/index.mdwn
If there is no file in the wiki named "--", that's harmless, because
it merely names the latest revision in which either "--" or
"doc/index.mdwn" changed. However, it could return incorrect results
if there is somehow a file named "--".
If we throw an exception (usually from run_or_die), in_git_dir won't
unshift the current directory from the stack. That's usually fine,
but in rcs_preprevert we catch exceptions and do some cleanup before
returning, for which we need the git directory to be the root and
not the temporary working tree.
Some of these might be relatively expensive to dereference or result
in messages being logged, and there's no reason why a search engine
should need to index them. (In particular, we'd probably prefer search
engines to index the rendered page, not its source code.)
We exclude .git/hooks from symlinking into the temporary working tree,
which avoids the commit hook being run for the temporary branch anyway.
This avoids the wiki not being updated if an orthogonal change is
received in process A, while process B prepares a revert that is
subsequently cancelled.
Otherwise, we have a time-of-check/time-of-use vulnerability:
rcs_preprevert previously looked at what changed in the commit we are
reverting, not at what would result from reverting it now. In
particular, if some files were renamed since the commit we are
reverting, a revert of changes that were within the designated
subdirectory and allowed by check_canchange() might now affect
files that are outside the designated subdirectory or disallowed
by check_canchange().
It is not sufficient to disable rename detection, since git older
than 2.8.0rc0 (in particular the version in Debian stable) silently
accepts and ignores the relevant options.
OVE-20161226-0002
This doesn't work prior to git 2.8: `git revert` silently ignores the
option and succeeds. We will have to fix CVE-2016-10026 some other way.
This reverts commit 9cada49ed6.
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
Otherwise, we have an authorization bypass vulnerability: rcs_preprevert
looks at what changed in the commit we are reverting, not at what would
result from reverting it now. In particular, if some files were renamed
since the commit we are reverting, a revert of changes that were within
the designated subdirectory and allowed by check_canchange() might now
affect files that are outside the designated subdirectory or disallowed
by check_canchange().
Signed-off-by: Simon McVittie <smcv@debian.org>
Simon McVittie
Joey Hess
intrigeri
Antoine Beaupré
Amitai Schleier