| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
were present. Probably caused by a change to what git status displays in this situation. Fixed by treating files git thinks are modified the same as typechanged files.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://bugs.debian.org/807341
* Fix insecure temporary permissions when git-annex repair is used in
in a corrupted git repository.
Other calls to withTmpDir didn't leak any potentially private data,
but repair clones the git repository to a temp directory which is made
using the user's umask. Thus, it might expose a git repo that is
otherwise locked down.
* Fix potential denial of service attack when creating temp dirs.
Since withTmpDir used easily predictable temporary directory names,
an attacker could create foo.0, foo.1, etc and as long as it managed to
keep ahead of it, could prevent it from ever returning.
I'd rate this as a low utility DOS attack. Most attackers in a position
to do this could just fill up the disk /tmp is on to prevent anything
from writing temp files. And few parts of git-annex use withTmpDir
anyway, so DOS potential is quite low.
Examined all callers of withTmpDir and satisfied myself that
switching to mkdtmp and so getting a mode 700 temp dir wouldn't break any
of them.
Note that withTmpDirIn continues to not force temp dir to 700.
But it's only used for temp directories inside .git/annex/wherever/
so that is not a problem.
Also re-audited all other uses of temp files and dirs in git-annex.
|
| |
|
|
| |
In unstable now.
|
| | |
|
| |
|
|
| |
file it was sending tickled bugs in some php WebDAV server.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Was not putting it inside the temp dir, but next to it!
This was just wrong, and it led to a longer filename that desired being
used, leading to some bug reports.
|
| |
|
|
|
|
|
| |
been dropped.
Before it crashed trying to lock the not-present content and prevented
dropping anything else. Instead, succeed.
|
| |
|
|
|
|
|
|
| |
written to ~/.config/git-annex/autostart
and ignore any such relative paths in the file
This was a reversion caused by the relative path changes in 5.20150113.
|
| |
|
|
|
|
|
|
|
| |
content of the url is downloaded. (Not when using --fast or --relaxed.)
importfeed just calls addurl functions, so inherits this from it.
Note that addurl still generates a temp file, and uses that key to download
the file. It just adds it to the work tree at the end when the file is small.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When core.sharedRepository is set, annex object files are not made mode
444, since that prevents a user other than the file owner from locking
them. Instead, a mode such as 664 is used in this case.
|
| |
|
|
| |
gcrypt.
|
| |
|
|
|
| |
Including in addurl, and get --from web, but also in S3 and External
special remotes when a web url is known for content in those remotes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
local git repo, and from a remote git repo.
Had everything available, just didn't combine the progress meter with the
other places progress is sent to update it. (And to a remote repo already
did show progress.)
Most special remotes should already display progress meters with -J,
same as without it. One exception to this is the web, since it relies on
wget/curl progress display without -J. Still todo..
|
| | |
|
| |
|
|
|
| |
To avoid creation of unnecessary trigger calling out to ldconfig
via activate-noawait which is not present on older releases (e.g. squeeze)
|
| |
|
|
|
|
|
| |
This was in the cabal file earlier, and was removed because it broke the
android cross build. Moving to the git-annex target of the Makefile
will make it be used for Debian packages etc but not android cross builds
or make fast or when users build with cabal.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(not actually used anywhere yet)
|
| |
|
|
|
|
|
| |
missed before.
It was used for regular pull, but not for regular push, tagged push, or the
fallback fetching.
|
| | |
|
| |
|
|
|
| |
keyLocations doesn't return locations in dead repos, but if we're fscking a
dead repo, we want to look at what locations are actually logged for it.
|
| |
|
|
|
|
|
| |
desktop file, and base completion file, same as the regular git-annex.deb.
It already had a doc-base file relating to the html documentation, and
there's no reason not to include the other stuff.
|
| |
|
|
| |
into $HOME/.ssh
|
| | |
|
| |
|
|
| |
support that; avoid crashing on such invalid encoding.
|
| |
|
|
|
|
| |
of the annex back to the file, because other files may point to that same content. Instead, copy the injected file content out to recover.
That was not a data loss, but it came close!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
replaceFile created a temp file, which was guaranteed to not overlap with
another temp file. However, makeAnnexLink then deleted that file, in
preparation for making the symlink in its place. This caused a race, since
some other replaceFile could create a temp file, using the same name!
I was able to reproduce the race easily running git-annex add -J10 in a
directory with 100 files (all with different contents). Some files would
get ingested into the annex, but their annex links would fail to be added.
There could be other situations where this same problem could occur.
Perhaps when the assistant is adding a file, if the user manually also ran
git-annex add. Perhaps in cases not involving adding a file.
The new replaceFile makes a temprary directory, which is guaranteed to be
unique, and doesn't make a temp file in there. makeAnnexLink can thus
create the symlink without problem and the race is avoided.
Audited all calls to replaceFile to make sure that the old behavior of
providing an empty temp file was not relied on.
The general problem of asking for a temp file and deleting it as part of
the process of using it could reach beyond replaceFile. Did some quick
audits and didn't find other cases of it. Probably only symlink creation
stuff would tend to make that mistake, mostly.
|
| |
|
|
| |
moves file contents around.
|
| |
|
|
| |
to is not a directort, but perhaps an annexed file.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Output without -Jn should be unchanged from before. With -Jn,
concurrent-output is used for messages, but regions are not used yet, so
it's a mess.
|
| |
|
|
|
| |
Seems that some changes to the cabal file a few months ago resulted in a
git-annex that broke stackage infrastructure.
|
| |
|
|
|
|
|
|
|
| |
display a warning, but continue successfully.
Installing the desktop file etc is a niceity of git-annex's cabal install,
but not a requirement.
closes https://github.com/fpco/stackage/issues/726
|
| |
|
|
| |
run as root, since that is not a systemwide install, but to /root, and so generating a systemwide desktop file is not right.
|
| | |
|
| |
|
|
|
|
| |
* Fix failure to build with aws-0.13.0.
* When built with aws-0.13.0, the S3 special remote can be used to create
google nearline buckets, by setting storageclass=NEARLINE.
|
| |
|
|
| |
seems it now prefers repo in this case, although historically it may have preferred repo.git.
|
| |
|
|
| |
and accept either the uuid or the description in leu if the name.
|
| | |
|
| |
|
|
| |
available, which should be more portable.
|
Joey Hess
Yaroslav Halchenko
Henrik Ahlgren