summaryrefslogtreecommitdiff
path: root/Crypto.hs
Commit message (Collapse)AuthorAge
* renameGravatar Joey Hess2011-07-05
|
* rename modules for data types into Types/ directoryGravatar Joey Hess2011-06-01
|
* simplified a bunch of Maybe handlingGravatar Joey Hess2011-05-15
|
* factor out base64 codeGravatar Joey Hess2011-05-01
|
* S3: When encryption is enabled, the Amazon S3 login credentials are stored, ↵Gravatar Joey Hess2011-05-01
| | | | encrypted, in .git-annex/remotes.log, so environment variables need not be set after the remote is initialized.
* Revert "Use haskell Crypto library instead of haskell SHA library.a"Gravatar Joey Hess2011-04-26
| | | | | | | | | This reverts commit 892593c5efacbc084d19af4b5d7164ededaea7ff. Conflicts: Crypto.hs debian/control
* add test to ensure hmac remains stableGravatar Joey Hess2011-04-21
|
* Use haskell Crypto library instead of haskell SHA library.aGravatar Joey Hess2011-04-21
| | | | Since hS3 needs Crypto anyway, this actually reduces dependencies.
* bup: Avoid memory leak when transferring encrypted data.Gravatar Joey Hess2011-04-19
| | | | | | | | | | | | | | | | | | | | | | | | This was a most surprising leak. It occurred in the process that is forked off to feed data to gpg. That process was passed a lazy ByteString of input, and ghc seemed to not GC the ByteString as it was lazily read and consumed, so memory slowly leaked as the file was read and passed through gpg to bup. To fix it, I simply changed the feeder to take an IO action that returns the lazy bytestring, and fed the result directly to hPut. AFAICS, this should change nothing WRT buffering. But somehow it makes ghc's GC do the right thing. Probably I triggered some weakness in ghc's GC (version 6.12.1). (Note that S3 still has this leak, and others too. Fixing it will involve another dance with the type system.) Update: One theory I have is that this has something to do with the forking of the feeder process. Perhaps, when the ByteString is produced before the fork, ghc decides it need to hold a pointer to the start of it, for some reason -- maybe it doesn't realize that it is only used in the forked process.
* Fix stalls in S3 when transferring encrypted data.Gravatar Joey Hess2011-04-19
| | | | | | | | | | | | | | | | | | | Stalls were caused by code that did approximatly: content' <- liftIO $ withEncryptedContent cipher content return store content' The return evaluated without actually reading content from S3, and so the cleanup code began waiting on gpg to exit before gpg could send all its data. Fixing it involved moving the `store` type action into the IO monad: liftIO $ withEncryptedContent cipher content store Which was a bit of a pain to do, thank you type system, but avoids the problem as now the whole content is consumed, and stored, before cleanup.
* enable gpg batch mode when GPG_AGENT_INFO is setGravatar Joey Hess2011-04-19
|
* initremote: show gpg keysGravatar Joey Hess2011-04-17
|
* Don't run gpg in batch mode, so it can prompt for passphrase when there is ↵Gravatar Joey Hess2011-04-17
| | | | no agent.
* cleanupGravatar Joey Hess2011-04-17
|
* looked up HMAC block size detailsGravatar Joey Hess2011-04-17
|
* hmacSha1 wants the secret key as first parameterGravatar Joey Hess2011-04-17
| | | | | | I was offline last night and going by function signatures, and unable to tell which was which. Note sure it matters to HMAC which comes first; better safe than sorry.
* use different parts of cipher for hmac and gpgGravatar Joey Hess2011-04-17
| | | | | | | Per bugs/S3_bucket_uses_the_same_key_for_encryption_and_hashing It may be paranoid to worry about the cipher being recovered from hmac keys, but yes.. let's be paranoid.
* fix stall while storing encrypted data in bupGravatar Joey Hess2011-04-17
| | | | | | Forking a new process rather than relying on a thread to feed gpg. The feeder thread was stalling, probably when the main thread got to the point it was wait()ing on the gpg to exit.
* proper encrypted keysGravatar Joey Hess2011-04-16
| | | | | | For HMAC, using the Data.Digest.Pure.SHA library. I have been avoiding this library for checksumming generally, since it's (probably) not as fast as external utilities, but it's fine to use it for HMAC.
* full encryption support for directory special remotesGravatar Joey Hess2011-04-16
|
* add cipher field to AnnexStateGravatar Joey Hess2011-04-16
|
* crypto library almost completeGravatar Joey Hess2011-04-16
| | | | | Piping data through gpg with symmetric cipher is working. Only Key encryption is not done.
* encryption key management workingGravatar Joey Hess2011-04-16
| | | | | Encrypted remotes don't yet encrypt data, but git annex initremote can be used to generate a cipher and add additional gpg keys that can use it.
* addGravatar Joey Hess2011-04-15