summaryrefslogtreecommitdiff
path: root/Utility/Tmp.hs
Commit message (Collapse)AuthorAge
* avoid warnings about not exported System.Directory.isSymbolicLinkGravatar Joey Hess2016-04-28
|
* Fix build with directory-1.2.6.2.Gravatar Joey Hess2016-04-28
| | | | | | It started exporting a isSymbolicLink which supports windows. But, git-annex does no use symlinks on windows yet and this conflicts with the function by the same name from unix-compat, so hide it.
* improve temp dir securityGravatar Joey Hess2015-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* avoid looping trying to make temp dir when the name is too longGravatar Joey Hess2015-12-06
| | | | | Only loop when directory creation fails due to the directory existing already.
* disable horrible tab warning, needed in every file that Setup.hs pulls inGravatar Joey Hess2015-05-10
| | | | | | | | This is certianly a cabal bug for not passing the build options in the cabal file when building Setup.hs. And, why oh why did ghc enable this warning by default? So unhappy with this choice.
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* generalize monadsGravatar Joey Hess2014-11-12
|
* unify exception handling into Utility.ExceptionGravatar Joey Hess2014-08-07
| | | | | | | | | | | | | | | | | | | | Removed old extensible-exceptions, only needed for very old ghc. Made webdav use Utility.Exception, to work after some changes in DAV's exception handling. Removed Annex.Exception. Mostly this was trivial, but note that tryAnnex is replaced with tryNonAsync and catchAnnex replaced with catchNonAsync. In theory that could be a behavior change, since the former caught all exceptions, and the latter don't catch async exceptions. However, in practice, nothing in the Annex monad uses async exceptions. Grepping for throwTo and killThread only find stuff in the assistant, which does not seem related. Command.Add.undo is changed to accept a SomeException, and things that use it for rollback now catch non-async exceptions, rather than only IOExceptions.
* lift types from IO to AnnexGravatar Joey Hess2014-07-29
| | | | | | | | | | | Some remotes like External need to run store and retrieve actions in Annex, not IO. In order to do that lift, I had to dive pretty deep into the utilities, making Utility.Gpg and Utility.Tmp be partly converted to using MonadIO, and Control.Monad.Catch for exception handling. There should be no behavior changes in this commit. This commit was sponsored by Michael Barabanov.
* Avoid leaving behind .tmp files when failing in some cases, including ↵Gravatar Joey Hess2014-06-09
| | | | importing files to a disk that is full.
* relicense general utility library code to BSDGravatar Joey Hess2014-05-10
| | | | | Omitted a couple of files what have had significant contributions from others.
* change a few renameFile's to renameGravatar Joey Hess2014-01-29
| | | | | AFAIK, none of these ever operate on directories, but nor do I want to explicitly check if they're files and fail if not.
* fixGravatar Joey Hess2013-12-30
|
* fixGravatar Joey Hess2013-12-30
|
* fix build failure in windows codeGravatar Joey Hess2013-12-30
|
* work around windows insanity that is 97.61% more brain-damaged than normalGravatar Joey Hess2013-12-29
|
* oopsGravatar Joey Hess2013-11-20
|
* merge with git-repairGravatar Joey Hess2013-11-19
|
* Fix a few bugs involving filenames that are at or near the filesystem's ↵Gravatar Joey Hess2013-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | maximum filename length limit. Started with a problem when running addurl on a really long url, because the whole url is munged into the filename. Ended up doing a fairly extensive review for places where filenames could get too large, although it's hard to say I'm not missed any.. Backend.Url had a 128 character limit, which is fine when the limit is 255, but not if it's a lot shorter on some systems. So check the pathconf() limit. Note that this could result in fromUrl creating different keys for the same url, if run on systems with different limits. I don't see this is likely to cause any problems. That can already happen when using addurl --fast, or if the content of an url changes. Both Command.AddUrl and Backend.Url assumed that urls don't contain a lot of multi-byte unicode, and would fail to truncate an url that did properly. A few places use a filename as the template to make a temp file. While that's nice in that the temp file name can be easily related back to the original filename, it could lead to `git annex add` failing to add a filename that was at or close to the maximum length. Note that in Command.Add.lockdown, the template is still derived from the filename, just with enough space left to turn it into a temp file. This is an important optimisation, because the assistant may lock down a bunch of files all at once, and using the same template for all of them would cause openTempFile to iterate through the same set of names, looking for an unused temp file. I'm not very happy with the relatedTemplate hack, but it avoids that slowdown. Backend.WORM does not limit the filename stored in the key. I have not tried to change that; so git annex add will fail on really long filenames when using the WORM backend. It seems better to preserve the invariant that a WORM key always contains the complete filename, since the filename is the only unique material in the key, other than mtime and size. Since nobody has complained about add failing (I think I saw it once?) on WORM, probably it's ok, or nobody but me uses it. There may be compatability problems if using git annex addurl --fast or the WORM backend on a system with the 255 limit and then trying to use that repo in a system with a smaller limit. I have not tried to deal with those. This commit was sponsored by Alexander Brem. Thanks!
* rename moduleGravatar Joey Hess2013-05-12