summaryrefslogtreecommitdiff
path: root/Remote/Helper
Commit message (Collapse)AuthorAge
* map: Work when there are gcrypt remotes.Gravatar Joey Hess2013-11-04
|
* directory, webdav: Fix bug introduced in version 4.20131002 that caused the ↵Gravatar Joey Hess2013-10-26
| | | | chunkcount file to not be written. Work around repositories without such a file, so files can still be retreived from them.
* fix inverted logic when determining whether to write a chunkcount fileGravatar Joey Hess2013-10-26
| | | | | | late-night hlint bit me on this one.. Reviewed f32cb2cf1576db1395f77bd5f7f0c0a3e86c1334 and the rest of it seems ok
* remove __WINDOWS__ ifdefGravatar Joey Hess2013-10-06
|
* fix transferring to gcrypt repo from direct mode repoGravatar Joey Hess2013-10-01
| | | | | | | | | | | | | | | | | | recvkey was told it was receiving a HMAC key from a direct mode repo, and that confused it into rejecting the transfer, since it has no way to verify a key using that backend, since there is no HMAC backend. I considered making recvkey skip verification in the case of an unknown backend. However, that could lead to bad results; a key can legitimately be in the annex with a backend that the remote git-annex-shell doesn't know about. Better to keep it rejecting if it cannot verify. Instead, made the gcrypt special remote not set the direct mode flag when sending (and receiving) files. Also, added some recvkey messages when its checks fail, since otherwise all that is shown is a confusing error message from rsync when the remote git-annex-shell exits nonzero.
* hlintGravatar Joey Hess2013-09-25
|
* factor out more ssh stuff from git remoteGravatar Joey Hess2013-09-24
| | | | | This has the dual benefits of making Remote.Git shorter, and letting Remote.GCrypt use these utilities.
* partially complete gcrypt remote (local send done; rest not)Gravatar Joey Hess2013-09-07
| | | | | | | | | | | | | | | | | | | | | | | | This is a git-remote-gcrypt encrypted special remote. Only sending files in to the remote works, and only for local repositories. Most of the work so far has involved making initremote work. A particular problem is that remote setup in this case needs to generate its own uuid, derivied from the gcrypt-id. That required some larger changes in the code to support. For ssh remotes, this will probably just reuse Remote.Rsync's code, so should be easy enough. And for downloading from a web remote, I will need to factor out the part of Remote.Git that does that. One particular thing that will need work is supporting hot-swapping a local gcrypt remote. I think it needs to store the gcrypt-id in the git config of the local remote, so that it can check it every time, and compare with the cached annex-uuid for the remote. If there is a mismatch, it can change both the cached annex-uuid and the gcrypt-id. That should work, and I laid some groundwork for it by already reading the remote's config when it's local. (Also needed for other reasons.) This commit was sponsored by Daniel Callahan.
* rename constructor for clariyGravatar Joey Hess2013-09-05
|
* Leverage an ambiguities between CiphersGravatar guilhem2013-09-05
| | | | | | | | | Cipher is now a datatype data Cipher = Cipher String | MacOnlyCipher String which makes more precise its interpretation MAC-only vs. MAC + used to derive a key for symmetric crypto.
* tabsGravatar Joey Hess2013-09-04
|
* unimportant tweakGravatar Joey Hess2013-09-04
| | | | fix something my internal haskell parser does a double take at
* replace an over-explained Bool with a data typeGravatar Joey Hess2013-09-04
| | | | | This also highlights several places where a Read/Show or similar for the new data type could avoid redundant strings.
* Encryption defaults to 'hybrid'Gravatar guilhem2013-09-04
| | | | When a keyid= is specified while encryption= is absent.
* Allow public-key encryption of file content.Gravatar guilhem2013-09-03
| | | | | | | | | | | | With the initremote parameters "encryption=pubkey keyid=788A3F4C". /!\ Adding or removing a key has NO effect on files that have already been copied to the remote. Hence using keyid+= and keyid-= with such remotes should be used with care, and make little sense unless the point is to replace a (sub-)key by another. /!\ Also, a test case has been added to ensure that the cipher and file contents are encrypted as specified by the chosen encryption scheme.
* Allow revocation of OpenPGP keys.Gravatar guilhem2013-08-29
| | | | | | | | | | | | | | | | | | | | | | | /!\ It is to be noted that revoking a key does NOT necessarily prevent the owner of its private part from accessing data on the remote /!\ The only sound use of `keyid-=` is probably to replace a (sub-)key by another, where the private part of both is owned by the same person/entity: git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C Reference: http://git-annex.branchable.com/bugs/Using_a_revoked_GPG_key/ * Other change introduced by this patch: New keys now need to be added with option `keyid+=`, and the scheme specified (upon initremote only) with `encryption=`. The motivation for this change is to open for new schemes, e.g., strict asymmetric encryption. git annex initremote myremote encryption=hybrid keyid=2512E3C7 git annex enableremote myremote keyid+=788A3F4C
* avoid more build warnings on WindowsGravatar Joey Hess2013-08-04
|
* squash compiler warnings on WindowsGravatar Joey Hess2013-08-04
|
* print encryption setup message before actionGravatar Joey Hess2013-05-18
|
* fix permission damage (thanks, Windows)Gravatar Joey Hess2013-05-11
|
* git-annex now builds on Windows (doesn't work)Gravatar Joey Hess2013-05-11
|
* expose Control.Monad.joinGravatar Joey Hess2013-04-22
| | | | | I think I've been looking for that function for some time. Ie, I remember wanting to collapse Just Nothing to Nothing.
* fix tab damageGravatar Joey Hess2013-04-13
|
* Allow rsync to use other remote shells.Gravatar guilhem2013-04-13
| | | | | | Introduced a new per-remote option 'annex-rsync-transport' to specify the remote shell that it to be used with rsync. In case the value is 'ssh', connections are cached unless 'sshcaching' is unset.
* connect existing meters to the transfer log for downloadsGravatar Joey Hess2013-04-11
| | | | | | | | | | | | | | Most remotes have meters in their implementations of retrieveKeyFile already. Simply hooking these up to the transfer log makes that information available. Easy peasy. This is particularly valuable information for encrypted remotes, which otherwise bypass the assistant's polling of temp files, and so don't have good progress bars yet. Still some work to do here (see progressbars.mdwn changes), but this is entirely an improvement from the lack of progress bars for encrypted downloads.
* changelog & minor style fixesGravatar Joey Hess2013-04-06
|
* Generate ciphers with a better entropy.Gravatar guilhem2013-04-06
| | | | | | | | | | Unless highRandomQuality=false (or --fast) is set, use Libgcypt's 'GCRY_VERY_STRONG_RANDOM' level by default for cipher generation, like it's done for OpenPGP key generation. On the assistant side, the random quality is left to the old (lower) level, in order not to scare the user with an enless page load due to the blocking PRNG waiting for IO actions.
* Allow other MAC algorithms in the Remote Config.Gravatar guilhem2013-03-29
|
* webapp: Progess bar fixes for many types of special remotes.Gravatar Joey Hess2013-03-28
| | | | | | | | | | | | | There was confusion in different parts of the progress bar code about whether an update contained the total number of bytes transferred, or the number of bytes transferred since the last update. One way this bug showed up was progress bars that seemed to stick at zero for a long time. In order to fix it comprehensively, I add a new BytesProcessed data type, that is explicitly a total quantity of bytes, not a delta. Note that this doesn't necessarily fix every problem with progress bars. Particularly, buffering can now cause progress bars to seem to run ahead of transfers, reaching 100% when data is still being uploaded.
* split cost out into its own moduleGravatar Joey Hess2013-03-13
| | | | | Added a function to insert a new cost into a list, which could be used to asjust costs after a drag and drop.
* git subcommand cleanupGravatar Joey Hess2013-03-03
| | | | | | Pass subcommand as a regular param, which allows passing git parameters like -c before it. This was already done in the pipeing set of functions, but not the command running set.
* show errorsGravatar Joey Hess2013-01-02
|
* type based git config handling for remotesGravatar Joey Hess2013-01-01
| | | | | Still a couple of places that use git config ad-hoc, but this is most of it done.
* webapp: S3 and Glacier forms now have a select list of all ↵Gravatar Joey Hess2012-12-01
| | | | currently-supported AWS regions.
* avoid unnecessary MaybeGravatar Joey Hess2012-11-30
|
* Amazon Glacier special remote; 100% workingGravatar Joey Hess2012-11-20
|
* Allow controlling whether login credentials for S3 and webdav are committed ↵Gravatar Joey Hess2012-11-19
| | | | to the repository, by setting embedcreds=yes|no when running initremote.
* directory special remote: Made more efficient and robust.Gravatar Joey Hess2012-11-19
| | | | | | | | | Files are now written to a tmp directory in the remote, and once all chunks are written, etc, it's moved into the final place atomically. For now, checkpresent still checks every single chunk of a file, because the old method could leave partially transferred files with some chunks present and others not.
* S3: Added progress display for uploading and downloading.Gravatar Joey Hess2012-11-18
|
* simplifyGravatar Joey Hess2012-11-18
|
* better streaming while encrypting/decryptingGravatar Joey Hess2012-11-18
| | | | | | Both the directory and webdav special remotes used to have to buffer the whole file contents before it could be decrypted, as they read from chunks. Now the chunks are streamed through gpg with no buffering.
* webdav now checks presence of and receives chunked contentGravatar Joey Hess2012-11-16
| | | | | Note that receiving encrypted chunked content currently involves buffering. (So does doing so with the directory special remote.)
* generic chunked content helperGravatar Joey Hess2012-11-16
| | | | | However, directory still uses its optimzed chunked file writer, as it uses less memory than the generic one in the helper.
* where indentingGravatar Joey Hess2012-11-11
|
* store S3 creds in a 600 mode file inside the local git repoGravatar Joey Hess2012-09-26
|
* unify typesGravatar Joey Hess2012-09-21
|
* add a progress callback to storeKey, and threaded it all the way throughGravatar Joey Hess2012-09-19
| | | | | | | | Transfer info files are updated when the callback is called, updating the number of bytes transferred. Left unused p variables at every place the callback should be used. Which is rather a lot..
* pass associatedfile and remoteuuid to git-annex-shellGravatar Joey Hess2012-07-02
| | | | | | | | This *almost* works. Along the way, I noticed that the --uuid parameter was being accidentially passed after the --, so that has never been actually used by git-annex-shell to verify it's running in the expected repository. Oops. Fixed.
* record transfer information on local git remotesGravatar Joey Hess2012-07-01
| | | | | | | | | | | | | | | In order to record a semi-useful filename associated with the key, this required plumbing the filename all the way through to the remotes' storeKey and retrieveKeyFile. Note that there is potential for deadlock here, narrowly avoided. Suppose the repos are A and B. A sends file foo to B, and at the same time, B gets file foo from A. So, A locks its upload transfer info file, and then locks B's download transfer info file. At the same time, B is taking the two locks in the opposite order. This is only not a deadlock because the lock code does not wait, and aborts. So one of A or B's transfers will be aborted and the other transfer will continue. Whew!
* Clean up handling of git directory and git worktree.Gravatar Joey Hess2012-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Baked into the code was an assumption that a repository's git directory could be determined by adding ".git" to its work tree (or nothing for bare repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are used to separate the two. This was attacked at the type level, by storing the gitdir and worktree separately, so Nothing for the worktree means a bare repo. A complication arose because we don't learn where a repository is bare until its configuration is read. So another Location type handles repositories that have not had their config read yet. I am not entirely happy with this being a Location type, rather than representing them entirely separate from the Git type. The new code is not worse than the old, but better types could enforce more safety. Added support for core.worktree. Overriding it with -c isn't supported because it's not really clear what to do if a git repo's config is read, is not bare, and is then overridden to bare. What is the right git directory in this case? I will worry about this if/when someone has a use case for overriding core.worktree with -c. (See Git.Config.updateLocation) Also removed and renamed some functions like gitDir and workTree that misused git's terminology. One minor regression is known: git annex add in a bare repository does not print a nice error message, but runs git ls-files in a way that fails earlier with a less nice error message. This is because before --work-tree was always passed to git commands, even in a bare repo, while now it's not.