| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
Thanks to the Debian security team for allocating these.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We still don't have a security@ alias; listing personal emails is
unfortunately the next-best thing.
|
| |
|
|
|
|
| |
__8226____9__Get_CAll___64___1__42__855.709__126__2847___64___E.p.s.o.n_P.r.i.n.t.e.r_T.e.c.h.n.i.c.a.l_S.u.p.p.o.r.t_C.o.n.t.a.c.t_N.u.m.b.e.r.mdwn
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 2acafb8b3fc4dc2e061a1f811610f67a67c7358b
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks, Raúl Benencia
|
|
|
|
| |
su's related bug #628843 is fixed.) Thanks, Ludwig Nussel. (CVE-2011-1408)
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
where the htmlscrubber is enabled.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
whitelisted image types. No svg.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since ikiwiki uses open :utf8, perl assumes that files contain valid utf-8.
If it turns out to be malformed it may later crash while processing strings
read from them, with 'Malformed UTF-8 character (fatal)'.
As at least a quick fix, use utf8::valid as soon as data is read, and if
it's not valid, call encode_utf8 on the string, thus clearing the utf-8
flag. This may cause follow-on encoding problems, but will avoid this
crash, and the input file was broken anyway, so GIGO is a reasonable
response. (I looked at calling decode_utf8 after, but it seemed to cause
more trouble than it was worth. BTW, use open ':encoding(utf8)' avaoids
this problem, but the corrupted data later causes Storable to crash when
writing the index.)
This is a quick fix, clearly imperfect:
- It might be better to explicitly call decode_utf8 when reading files,
rather than using the IO layer.
- Data read other than by readfile() can still sneak in bad utf-8. While
ikiwiki does very little file input not using it, stdin for the CGI
would be one way.
|
|
|
|
|
|
| |
To generate your own, use ikiwiki -dumpsetup ikiwiki.setup
Update docs.
|
|
|
|
|
|
| |
This is a partial commit of:
egrep -rl '\[\[[a-z]+ ' doc | xargs --max-args 1 ./ikiwiki-transition
prefix_directives
|
| |
|