Tell `git revert` not to follow renames (CVE-2016-10026)

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>

Update changelog

Reference CVE-2016-4561 in 3.20141016.3 changelog

img test: exercise upper-case extensions for image files

Detect image type from .JPG just like .jpg (etc.).

3.20141016.3 (for jessie-security)

Do not recommend mimetype(image/*)

Not all image file types are safe for general use: in particular,
image/svg+xml is known to be vulnerable to CVE-2016-3714 under some
ImageMagick configurations.

Document the security fixes in this release

add more details of CVE-2015-2793

update for recent XSS

img: make img_allowed_formats case-insensitive

update test suite for svg passthrough by img directive

Remove build dependency libmagickcore-6.q16-2-extra which was only there
for this test.

img: Add back support for SVG images, bypassing ImageMagick and simply passing the SVG through to the browser

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]

Changelog

img: check magic number before giving common formats to ImageMagick

This mitigates CVE-2016-3714 and similar vulnerabilities by
avoiding passing obviously-wrong input to ImageMagick decoders.

img: restrict to JPEG, PNG and GIF images by default

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.

Update structure of img test from master

Originally from commit cdfb4ab "Run autopkgtest tests using autodep8 and
the pkg-perl team's infrastructure", cherry-picked here to be able to
apply subsequent test coverage extensions in this test.

img test: set old timestamp on source file that will change

This is so that the test will pass even if it takes less than 1 second.

img test: skip testing PDFs if unsupported

img test: use the right filenames when testing that deletion occurs

Also use a less misleading name for the sample SVG: it is no longer empty.
Since commit 105f285a it has contained a blue square.

img: force common Web formats to be interpreted according to extension

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.

HTML-escape error messages (OVE-20160505-0012)

The instance in cgierror() is a potential cross-site scripting attack,
because an attacker could conceivably cause some module to raise an
exception that includes attacker-supplied HTML in its message, for
example via a crafted filename. (OVE-20160505-0012)

The instances in preprocess() is just correctness. It is not a
cross-site scripting attack, because an attacker could equally well
write the desired HTML themselves; the sanitize hook is what
protects us from cross-site scripting here.

img: stop ImageMagick trying to be clever if filenames contain a colon

$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.

Release 3.20141016.2

Fix XSS in openid selector. Thanks, Raghav Bisht.

Conflicts:
debian/changelog
doc/bugs/XSS_Alert...__33____33____33__.html

note that the two potential FTBFSs do not actually affect buildds

The relevant tests are skipped on buildds because they don't have
libipc-run-perl or inkscape.

release candidate

Work around Debian #771047: use a non-blank SVG for the regression test

Inkscape loses the bounding box of a SVG with no content when it
converts it to EPS, and ImageMagick does not have a special case for
converting SVG to PNG with Inkscape in one step (which Inkscape can do);
it prefers to convert SVG to EPS with Inkscape, then EPS to whatever.

close debian bug I opened about blogspam

blogspam uses JSON instead of RPC::XML now.

Update blogspam to the 2.0 API.

Set Debian package maintainer to Simon McVittie as I'm retiring from Debian.

Add missing build-depends on libcgi-formbuilder-perl, needed for t/relativity.t

Merge remote-tracking branch 'refs/remotes/dgit/dgit/sid'

release

debian: fix some wrong paths in the copyright file

debian: rename debian/link to debian/links so the intended symlinks appear

close a bug

Drop unused python-support dependency

changelog so far

build-depend on libcgi-pm-perl too, for tests

Explicitly depend on CGI.pm, which is no longer in Perl core

I was going to depend on the version that has CGI->param_fetch,
but that has been supported since 2.37, which is older than oldstable.

IkiWiki::Plugin::openid: as a precaution, do not call non-coderefs

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]

Call CGI->param_fetch instead of CGI->param in array context

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]

Make sure we do not pass multiple CGI parameters in function calls

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.

Added a comment: It was an Apache problem...

branch

comment

Replace PayPal and Flattr buttons with text links

In particular, this avoids loading third-party resources from the
offline documentation (see
<https://lintian.debian.org/tags/privacy-breach-donation.html>).

mention pagespec_alias patches

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

as usual, macports hasn't moved

Added a comment

Added a comment

one report suffices; not yet clear there's a bug

clarify

findings and questions

Do not pass ignored sid parameter to checksessionexpiry

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.

comments: don't log remote IP address for signed-in users

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.

google search plugin: use https for the search

default User-Agent changed

Set default User-Agent to something that doesn't mention libwww-perl

It appears that both the open-source and proprietary rulesets for
ModSecurity default to blacklisting requests that say they are
from libwww-perl, presumably because some script kiddies use libwww-perl
and are too inept to set a User-Agent that is "too big to blacklist",
like Chrome or the iPhone browser or something. This seems doomed to
failure but whatever.

removed

Added a comment

help Markdown make a list

Added a comment: fixed in a recent release, I think

Replace shebang paths with the build-time $(PERL).

On non-Debian systems, /usr/bin/perl might not be the best available
Perl interpreter. Use whichever perl was used to run Makefile.PL,
unless it was "/usr/bin/perl", in which case there's nothing to do.

Extract test subs for each site. No change meant.

Extract run_cgi(). No functional change intended.

Extract check_generated_content(). Same output.

Extract check_cgi_mode_bits(). No change intended.

Extract thoroughly_rebuild(), a slight test change.

I didn't try to parameterize when a test should fail when we can't
remove ikiwiki.cgi because there already isn't one. (Hooray, natural
language.) Instead, we stop worrying about it and always tolerate
ENOENT.

Extract write_setup_file(). No functional change.

Test output differs only by the line numbers of the TODO items.

clarify further

clarify

That's not how that directive is used, and if you want to try stuff out please edit the sandbox instead

This reverts commit 856819a733d90a2ca259a5a3b03cc5d84f72e931

alternative plan

simplify IPC::Run check (same behavior)

exclude openid/troubleshooting

Added a comment

Added a comment

Added a comment

more fixes

Document another fix

In html5 mode, generate a host- or protocol-relative <base> for the CGI

This increases the number of situations in which we do the right thing.

Add reverse_proxy option which hard-codes cgiurl in CGI output

This solves several people's issues with the CGI trying to be
too clever when IkiWiki is placed behind a reverse-proxy.

Avoid mixed content when cgiurl is https but url is not