| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
Otherwise, recent git releases show renames as renames, and we do not
see that newdir/test5 was affected.
Bug-Debian: https://bugs.debian.org/835612
|
| | |
|
| | |
|
| |
|
|
|
| |
This makes it harder to test, and if we're invoking git anyway,
a couple of extra subprocesses are no big deal.
|
| |
|
|
|
|
|
| |
in .git/config
This resolves commit errors in versions of git that require a non-trivial
committer identity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
banned_users
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
|
| |
|
|
| |
-s ours.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git's behaviour when doing "git push origin" is configurable, and the
default is going to change in 2.0. In particular, if you've set
push.default to "nothing", the regression test will warn:
fatal: You didn't specify any refspecs to push, and push.default
is "nothing".
'git push origin' failed: at .../lib/IkiWiki/Plugin/git.pm line 220.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
querying git to find the files that were changed, rather than looking at the work tree. Not enabled by default as it can break some setups where not all files get committed to git.
|
| |
|
|
|
|
|
|
|
| |
Not sure if this is needed to avoid it trying to run an editor. Probably
there is never a controlling terminal and probably git notices and does
nothing. But I'm just copying what I have in git-annex assistant here.
(Although with a much worse git version comparion, that only really works due
to luck.)
|
| |
|
|
| |
commits with an empty commit message.
|
| |
|
|
| |
All existing tests pass.
|
| |
|
|
|
|
| |
A file may have no git sha1 if it's in the underlay, or just is not checked
into git. This debug message doesn't add any value and is potentially
confusing.
|
| |
|
|
|
| |
ikiwiki source files can contain at least one character that
needs to be escaped in an url: +
|
| |
|
|
|
|
|
|
|
|
|
| |
When the wiki is in a subdir of the git repo, a web revert would show
in recentchanges as eg, doc/index, instead of just index.
This happened because decode_git_file caches a $prefix that is dependant
on the $git_dir setting, and the revert code runs with a different
$git_dir, which polluted the $prefix for later.
Fix this by adding a with_git_dir that juggles the variables properly.
|
| |
|
|
| |
When reverting, an add is a remove, and a remove is an add.
|
| |
|
|
| |
changes to attachments.
|
| | |
|
| |
|
|
| |
reading in enormous commits.
|
| |
|
|
| |
like recentchanges files that are not normally checked in, when fixing links after rename.
|
| | |
|
| |
|
|
| |
Signed-off-by: Tuomas Jormola <tj@solitudo.net>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I understand the need to avoid chdir when running git_parse_changes
for receive now. At that point, the changes have not been pushed to
the srcdir's repo yet. When running the same code for preprevert,
chdir to the srcdir is ok, and necessary.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|