summaryrefslogtreecommitdiff
path: root/Creds.hs
Commit message (Collapse)AuthorAge
* Avoid backtraces on expected failures when built with ghc 8; only use ↵Gravatar Joey Hess2016-11-15
| | | | | | | | | | | | | backtraces for unexpected errors. ghc 8 added backtraces on uncaught errors. This is great, but git-annex was using error in many places for a error message targeted at the user, in some known problem case. A backtrace only confuses such a message, so omit it. Notably, commands like git annex drop that failed due to eg, numcopies, used to use error, so had a backtrace. This commit was sponsored by Ethan Aubin.
* plumb RemoteGitConfig through to decryptCipherGravatar Joey Hess2016-05-23
|
* plumb RemoteGitConfig through to setRemoteCredPairGravatar Joey Hess2016-05-23
|
* Pass the various gnupg-options configs to gpg in several cases where they ↵Gravatar Joey Hess2016-05-23
| | | | | | | | | | | | were not before. Removed the instance LensGpgEncParams RemoteConfig because it encouraged code that does not take the RemoteGitConfig into account. RemoteType's setup was changed to take a RemoteGitConfig, although the only place that is able to provide a non-empty one is enableremote, when it's changing an existing remote. This led to several folow-on changes, and got RemoteGitConfig plumbed through.
* Added annex.gnupg-decrypt-options and ↵Gravatar Joey Hess2016-05-10
| | | | | | | | | | | remote.<name>.annex-gnupg-decrypt-options, which are passed to gpg when it's decrypting data. The naming is unofrtunately not consistent, but the gnupg-options were only used for encrypting, and it's too late to change that. It would be nice to have a third setting that is always passed to gnupg, but ~/.gnupg/options can be used to specify such global options when really needed.
* remove 163 lines of code without changing anything except importsGravatar Joey Hess2016-01-20
|
* support gpg.programGravatar Joey Hess2015-09-09
| | | | | | When gpg.program is configured, it's used to get the command to run for gpg. Useful on systems that have only a gpg2 command or want to use it instead of the gpg command.
* S3: Publically accessible buckets can be used without creds.Gravatar Joey Hess2015-06-05
|
* a few hlintsGravatar Joey Hess2015-04-11
|
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* enableremote: When the remote has creds, update the local creds cache file. ↵Gravatar Joey Hess2014-10-22
| | | | Before, the old version of the creds could be left there, and would continue to be used.
* note whether or not embedded creds are encryptedGravatar Joey Hess2014-10-21
|
* include creds location in infoGravatar Joey Hess2014-10-21
| | | | | | | | This is intended to let the user easily tell if a remote's creds are coming from info embedded in the repository, or instead from the environment, or perhaps are locally stored in a creds file. This commit was sponsored by Frédéric Schütz.
* error, don't warn about insecure credsGravatar Joey Hess2014-09-18
| | | | | | | | | | A one-time warning was not good enough. A hard error will force the user to notice the problem. Perhaps worth noting that git-annex enableremote already failed with an error, and nobody reported a bug. Suggests that not many people have used the insecure configuration, or if they did, they went to the bother to embedcreds, but never re-enabled the special remote.
* deal with old repositories with non-encrypted credsGravatar Joey Hess2014-09-18
| | | | | | | | | | | | | | | | | See 2fb7ad68637cc4e1092f835055a974f141808ca0 for backstory about how a repo could be in this state. When decryption fails, the repo must be using non-encrypted creds. Note that creds are encrypted/decrypted using the encryption cipher which is stored in the repo, so the decryption cannot fail due to missing gpg keys etc. (For !shared encryptiom, the cipher is iteself encrypted using some gpg key(s), and the decryption of the cipher happens earlier, so not affected by this change. Print a warning message for !shared repos, and continue on using the cipher. Wrote a page explaining what users hit by this bug should do. This commit was sponsored by Samuel Tardieu.
* glacier, S3: Fix bug that caused embedded creds to not be encypted using the ↵Gravatar Joey Hess2014-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | remote's key. encryptionSetup must be called before setRemoteCredPair. Otherwise, the RemoteConfig doesn't have the cipher in it, and so no cipher is used to encrypt the embedded creds. This is a security fix for non-shared encryption methods! For encryption=shared, there's no security problem, just an inconsistentency in whether the embedded creds are encrypted. This is very important to get right, so used some types to help ensure that setRemoteCredPair is only run after encryptionSetup. Note that the external special remote bypasses the type safety, since creds can be set after the initial remote config, if the external special remote program requests it. Also note that IA remotes never use encryption, so encryptionSetup is not run for them at all, and again the type safety is bypassed. This leaves two open questions: 1. What to do about S3 and glacier remotes that were set up using encryption=pubkey/hybrid with embedcreds? Such a git repo has a security hole embedded in it, and this needs to be communicated to the user. Is the changelog enough? 2. enableremote won't work in such a repo, because git-annex will try to decrypt the embedded creds, which are not encrypted, so fails. This needs to be dealt with, especially for ecryption=shared repos, which are not really broken, just inconsistently configured. Noticing that problem for encryption=shared is what led to commit cc54ff9e49260cd94f938e69e926a273e231ef4e, which tried to fix the problem by not decrypting the embedded creds. This commit was sponsored by Josh Taylor.
* Revert "S3, Glacier, WebDAV: Fix bug that prevented accessing the creds when ↵Gravatar Joey Hess2014-09-18
| | | | | | | | | | the repository was configured with encryption=shared embedcreds=yes." This reverts commit cc54ff9e49260cd94f938e69e926a273e231ef4e. I can find no basis for that commit and think that I made it in error. setRemoteCredPair always encrypts using the cipher from remoteCipher, even when the cipher is shared.
* S3, Glacier, WebDAV: Fix bug that prevented accessing the creds when the ↵Gravatar Joey Hess2014-08-12
| | | | | | | | | | | repository was configured with encryption=shared embedcreds=yes. Since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded. However, it then tried to always decrypt creds when encryption was used..
* webapp: Fix UI for removing XMPP connection.Gravatar Joey Hess2014-04-20
|
* plumb creds from webapp to initremoteGravatar Joey Hess2014-02-11
| | | | | Avoids abusing setting environment variables, which was always a hack and won't work on windows.
* Fix initremote with encryption=pubkey to work with S3, glacier, webdav, and ↵Gravatar Joey Hess2014-02-06
| | | | external special remotes.
* add credential storage support for external special remotes & update exampleGravatar Joey Hess2013-12-27
|
* fix windows buildGravatar Joey Hess2013-10-02
|
* successfully builds (except XMPP)Gravatar Joey Hess2013-09-22
|
* 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.
* squash compiler warnings on WindowsGravatar Joey Hess2013-08-04
|
* missed some __WINDOWS__ definesGravatar Joey Hess2013-08-04
|
* fix permission damage (thanks, Windows)Gravatar Joey Hess2013-05-11
|
* clean up from windows portingGravatar Joey Hess2013-05-11
|
* git-annex now builds on Windows (doesn't work)Gravatar Joey Hess2013-05-11
|
* fixup #if 0 stubs to use #ifndef mingw32_HOST_OSGravatar Joey Hess2013-05-10
| | | | | | That's needed in files used to build the configure program. For the other files, I'm keeping my __WINDOWS__ define, as I find that much easier to type. I may search and replace it to use the mingw32_HOST_OS thing later.
* stub out POSIX stuffGravatar Joey Hess2013-05-10
|
* fix for AndroidGravatar Joey Hess2013-05-09
|
* hlintGravatar Joey Hess2013-04-03
|
* GnuPG options for symmetric encryption.Gravatar guilhem2013-03-11
|
* webapp: Defaults to sharing box.com account info with friends, allowing ↵Gravatar Joey Hess2012-11-28
| | | | one-click enabling of the repository.
* 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.
* 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.
* factor out CredsGravatar Joey Hess2012-11-14