[[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.
Commit feb21ebfac added a
safe_decode_utf8 function that avoids double decoding on Perl 5.20.
But the Perl behavior change actually happened in Encode.pm 2.53
(https://github.com/dankogai/p5-encode/pull/11). Although Perl 5.20
is the first Perl version to bundle an affected version of Encode.pm,
it’s also possible to upgrade Encode.pm independently; for example,
Fedora 20 has Perl 5.18.4 with Encode.pm 2.54. On such a system,
editing a non-ASCII file still fails with errors like
Error: Cannot decode string with wide characters at
/usr/lib64/perl5/vendor_perl/Encode.pm line 216.
There doesn’t seem to be any reason not to check Encode::is_utf8 on
old versions too, so just remove the version check altogether.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Bug-Debian: https://bugs.debian.org/776181
Mobile browsers typically assume that arbitrary web pages are
designed for a "desktop-sized" browser window (around 1000px)
and display that layout, zoomed out, in order to avoid breaking
naive designs that assume nobody will ever look at a website on
a phone or something. People who are actually doing "responsive
design" need to opt-in to mobile browsers rendering it at a
more normal size.
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.
srcfile_stat got called on a file from the underlay that no longer existed.
I am not 100% sure of the circumstances of that; I was able to reproduce
the bug but neglected to snapshot the tree, and then accidentially
got it to stop crashing. I know that a transient tag page got deleted using
the web interface to trigger the crash.
It seems that process_changed_files must have returned the file, despite it
being deleted. And since the file was not checked into git, it seems it
must have not been included in @IkiWiki::underlayfiles, which would have
caused process_changed_files to not return it.
I do not know why a transient tag page would not be in
@IkiWiki::underlayfiles. There is a bug here that I don't understand.
This is just a workaround -- run srcfile_stat such that it won't crash,
and if it is unable to stat a file, find_changed knows it's not changed,
so it's ok to skip it.
Also made find_new_files run srcfile_stat such that it won't crash, just
because I was there.
install prerequisite Perl modules in the systemwide locations. They may
have to be installed under the home directory, such as by using local::lib
(which is how the cPanel Perl-module installer works, on systems that use it).
For that to work, the local::lib-defined value for PERL5LIB must be in
the environment when Perl starts up. The former way %config{ENV} was handled
was too late, depending on the Perl code to unpack it from the storable and
put it into the environment.
Easy solution is to build the wrapper to repopulate the environment based on
%config{ENV} before ever exec'ing Perl (and then remove it from the storable
as there is nothing more that the Perl code will need to do with it).