| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
It does not seem to have any more current URL, and in any case our
version is a fork.
|
| |
|
|
| |
intended interpretation
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of logging "bad file name %s" and attempting to call the
(string) filename as a subroutine, actually do the intended
sprintf operation.
|
| |
|
|
|
|
| |
The Debian security tracker gets timely updates, whereas the official
CVE pages hosted by MITRE tend to show up as "RESERVED" for several
weeks or months after assignment.
|
| |
|
|
| |
security.debian.org currently rejects HTTPS connections.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 "--".
|
| | |
|
| |
|
|
|
|
|
| |
Now that we have avoided using in_git_dir recursively, we don't need
the stack any more.
This reverts commit 39b8931ad31fe6b48afdc570caa459a0996c2092.
|
| |
|
|
|
| |
In the environment used on ci.debian.net, we have neither a name nor
an email address.
|
| |
|
|
|
|
|
|
| |
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 need the changes to take place at least 1 second after the first
rebuild, so that the changed files are seen to have changed.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks to the Debian security team for allocating these.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This avoids leaving the git directory in an inconsistent state if the
host system is rebooted while we are processing a revert.
|
| |
|
|
|
|
| |
This will be necessary when we use a secondary working tree to do
reverts without leaving the primary working tree in an inconsistent
state.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 9cada49ed6ad24556dbe9861ad5b0a9f526167f9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
The intention here seems to be that $prev may be undefined, and the
only way that can legitimately happen is for $params{token} to be
undefined too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was relying on running with an installed ikiwiki
and being able to copy in recentchanges.mdwn and wikiicons/ from the
underlay in /usr. The underlay in ./underlays/basewiki can't be used
(yet) because ikiwiki doesn't allow following symlinks, even from
underlays.
I'd like to make ikiwiki follow symlinks whose destinations can be
verified to be safe (for example making it willing to expose
/usr/share/javascript to the web, but not /etc/passwd), at least from
underlays, but this is security-sensitive so I'm not going to rush
into it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Sort in lexical order the pages that have the same number of hits.
|
| | |
|