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>
SVG scaling by img directives has subtly changed; where before size=wxh
would preserve aspect ratio, this cannot be done when passing them through
and so specifying both a width and height can change the SVG's aspect
ratio.
(This patch looks significantly more complex than it was, because a large
block of code had to be indented.)
[smcv: drop trailing whitespace, fix some spelling]
This mitigates CVE-2016-3714. Wiki administrators who know that they
have prevented arbitrary code execution via other formats can re-enable
the other formats if desired.
A site administrator might unwisely set allowed_attachments to
something like '*.jpg or *.png'; if they do, an attacker could attach,
for example, a SVG file named attachment.jpg.
This mitigates CVE-2016-3714.
If the relative link from the (page generating the) RSS to the target
would start with "./" or "../", just concatenating it with the URL to
the directory containing the RSS is not sufficient. Go via
URI::new_abs to fix this.
Now I'm going to get bug reports about wanting the URLs to be
protocol-relative, but we can't win there as long as we generate RSS,
because RSS doesn't have well-defined semantics for relative URLs
(and the W3C's validator complains about them). If absolute URLs are
a problem for you, please use Atom feeds.
$im->Read() takes a filename-like argument with several sets of special
syntax. Most of the possible metacharacters are escaped by the
default `wiki_file_chars` (and in any case not particularly disruptive),
but the colon ":" is not.
It seems the way to force ImageMagick to treat colons within the
filename as literal is to prepend a colon, so do that.
This avoids nasty surprises on upgrade if a site is using httpauth,
or passwordauth with an account_creation_password, and relying on
only a select group of users being able to edit the site. We can revisit
this for ikiwiki 4.
This was needed due to emailauth, but I've also wrapped all IP address
exposure in cloak(), although the function doesn't yet cloak IP addresses.
(One IP address I didn't cloak is the one that appears on the password
reset email template. That is expected to be the user's own IP address,
so ok to show it to them.)
Thanks to smcv for the pointer to
http://xmlns.com/foaf/spec/#term_mbox_sha1sum
There's no real problem if they do change it, except they may get confused
and expect to be able to log in with the changed email and get the same
user account.
This makes the email not be displayed on the wiki, so spammers won't find
it there.
Note that the full email address is still put into the comment template.
The email is also used as the username of the git commit message
(when posting comments or page edits). May want to revisit this later.
This includes some CSS changes to names of elements.
Also, added Email login button (doesn't work yet of course),
and brought back the small openid login buttons. Demoted yahoo and verison
to small buttons. This makes the big buttons be the main login types, and
the small buttons be provider-specific helpers.
[[forum/refresh_and_setup]] indicates some confusion between --setup
and -setup. Both work, but it's clearer if we stick to one in
documentation and code.
A 2012 commit to [[plugins/theme]] claims that "-setup" is required
and "--setup" won't work, but I cannot find any evidence in ikiwiki's
source code that this has ever been the case.
We're running under "use strict" here, so if CGI->param's array-context
misbehaviour passes an extra non-ref parameter, it shouldn't be executed
anyway... but it's as well to be safe.
[commit message added by smcv]
CGI->param has the misfeature that it is context-sensitive, and in
particular can expand to more than one scalar in function calls.
This led to a security vulnerability in Bugzilla, and recent versions
of CGI.pm will warn when it is used in this way.
In the situations where we do want to cope with more than one parameter
of the same name, CGI->param_fetch (which always returns an
array-reference) makes the intention clearer.
[commit message added by smcv]
When CGI->param is called in list context, such as in function
parameters, it expands to all the potentially multiple values
of the parameter: for instance, if we parse query string a=b&a=c&d=e
and call func($cgi->param('a')), that's equivalent to func('b', 'c').
Most of the functions we're calling do not expect that.
I do not believe this is an exploitable security vulnerability in
ikiwiki, but it was exploitable in Bugzilla.
According to caniuse.com, a significant fraction of Web users are
still using Internet Explorer versions that do not support HTML5
sectioning elements. However, claiming we're XHTML 1.0 Strict
means we can't use features invented in the last 12 years, even if
they degrade gracefully in older browsers (like the role and placeholder
attributes).
This means our output is no longer valid according to any particular
DTD. Real browsers and other non-validator user-agents have never
cared about DTD compliance anyway, so I don't think this is a real loss.
checksessionexpiry's signature changed from
(CGI::Session, CGI->param('sid')) to (CGI, CGI::Session) in commit
985b229b, but editpage still passed the sid as a useless third
parameter, and this was later cargo-culted into remove, rename and
recentchanges.
The intention was that signed-in users (for instance via httpauth,
passwordauth or openid) are already adequately identified, but
there's nothing to indicate who an anonymous commenter is unless
their IP address is recorded.
The old name still works, if its value is numeric.
This name allows a non-numeric "show" to mean the same thing
it does for [[!map]] (show title, show description, etc.).
The `time` variable contains a fixed-format time, guaranteed suitable
for parsing by timedate.
The `formatted_time` variable contains the same time formatted by
IkiWiki::formattime.
I want to make GUIDs for my RSS feeds that don't change when I move
pages around. To that end, I've used UUID::Tiny to generate a
version 4 (random) UUID that is presented in a `uuid` variable in
the template.
At that point, you can do something like this:
[[!meta guid="urn:uuid:<TMPL_VAR uuid>"]]
Simon McVittie
intrigeri
Joey Hess
Amitai Schlair
Florian Wagner
Louis
Joey Hess
Louis
Jonathon Anderson