January 2012 - web-devel

[ANNOUNCE] First release of crypto-conduit
by Felipe Almeida Lessa 08 Jan '12

08 Jan '12

Hello! I'm pleased to announce the first release of crypto-conduit [1]! The crypto-api [2] package provides APIs for many cryptographic operations, such as cryptographic hashes and block ciphers. This new crypto-conduit package allows you to use many of these operations with conduits [3], giving you safe I/O using constant memory and no leaks. As an example, here's how you could get the SHA1 hash a file: import Crypto.Conduit -- from crypto-conduit import Crypto.Hash.SHA1 (SHA1) -- from cryptohash import Data.Conduit -- from conduit import Data.Conduit.Binary (sourceFile) -- from conduit main = do hash <- runResourceT $ sourceFile "my-file" $$ sinkHash print (hash :: SHA1) The code snippet above, despite having only "sourceFile ... $$ sinkHash" on its core, guarantees that the file handle is not kept open and uses a constant amount of memory. Sweet! Please break this package! Although it comes with a test suite, it has just seen the light of the day. Cheers, =) [1] http://hackage.haskell.org/package/crypto-conduit [2] http://hackage.haskell.org/package/crypto-api [3] http://hackage.haskell.org/package/conduit -- Felipe.

5 13

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 08 Jan '12

08 Jan '12

To use the hash, I have to convert it to a ByteString, and then I suddenly have lost all this safety. I don't really see how there is any real safety gained. That said, just exposing a direct method of getting to that ByteString without cereal (as Thomas proposed) would be an improvement. Aristid 2012/1/8 Vincent Hanquez <tab(a)snarc.org>: > On 01/08/2012 04:12 AM, Aristid Breitkreuz wrote: >> >> Why? I don't actually need the hash object for anything, usually. All >> I need is the ByteString, and then I need to learn how to use the >> cereal package to get it... > > The whole rationale i believe, is having meaningful types associated to your > values so that the type checker can do its job. i.e. you don't start mixing > a hash (in binary form) and a random piece of file. > > My only problem with the Serialize instance, is that dependencies (cereal in > this case) trickle through to the user of the API, which would be solved by > Thomas' suggestion. > > -- > Vincent

1 0

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 07 Jan '12

07 Jan '12

2012/1/8 Vincent Hanquez <tab(a)snarc.org>: > What would you prefer ? > > At the moment, i'm inclined to someday move cryptohash apis to be similar to > crypto-api. i.e. from a result type being a bytestring to an opaque type > with serialize/show instance. > Why? I don't actually need the hash object for anything, usually. All I need is the ByteString, and then I need to learn how to use the cereal package to get it... So talking purely about convenience, I would prefer hash :: HashType -> InputData -> ByteString. That would probably not be extensible enough, so I'm not sure how to optimally do it. Aristid

1 0

limiting POST
by Kazu Yamamoto 07 Jan '12

07 Jan '12

Hello guys, As you may know, "Denial of Service through hash table multi-collisions" was disclosed: http://permalink.gmane.org/gmane.comp.security.full-disclosure/83694 The hashable package is affected but not affected to Yesod suite. However, I guess we should provide size limitation of HTTP body on POST to Warp. # Of course, we should provide rate limiting, too. --Kazu

4 5

Re: [web-devel] [Haskell-cafe] [ANNOUNCE] First release of crypto-conduit
by Aristid Breitkreuz 07 Jan '12

07 Jan '12

Yeah and that's annoying IMHO. :) It's not really important though. Aristid Am 07.01.2012 15:39 schrieb "Felipe Almeida Lessa" <felipe.lessa(a)gmail.com>:

1 0

I just published a Wai+Persistent integration testing library (github, not hackage)
by Nubis 03 Jan '12

03 Jan '12

Hi guys, somewhat related to my stupid question yesterday, I finished cleaning up and packing the integration tests library we are using with Max Cantor at Hachicode. https://github.com/nubis/TestWaiPersistent It's based on wai-test. Test cases keep the state of cookies and the last response in order to make assertions on it. It also lets you introspect the last response in order to build your next request, looking up the _nonce and field names of the last received form.It also lets you query the database to pre-populate data and check that your actions get reflected on the database as expected. It's pretty early stage, but already useful, I'd like to hear your opinions about it. As you may notice the source is cabalized but I don't have a username for hackage yet, and even if I had I think I'd wait a bit before publishing it there. PS: While we're at it, I also published a game library a few weeks ago, I'd love feedback on that too: https://github.com/nubis/Monono cheers ----nubis :)

1 0

wai-test, does it accept multipart/form-data too?
by Nubis 03 Jan '12

03 Jan '12

Hi guys, I'm building a yesod testing tool, in part building on top of wai-test for interacting with the yesod application. But I'm noticing that sending multipart/form-data requests using wai-test is not working. url-encoded requests are working as expected, both get and post. The symptom I'm seeing is that both the result of lookupPostParams and lookupFiles for the parameter I'm sending return empty lists. I dug through wai, wai-extra, and yesod handler code and as it seems, yesod's code should be taking care of using wai-extra.parse to get the FileInfo's. I don't want to bother you with the details yet, but I just wanted to know if this is a 'known limitation' of wai-test. More specifically, given this function: srequest :: SRequest -> Session SResponse srequest (SRequest req bod) = do app <- ask res <- liftIO $ run_ $ enumList 4 (L.toChunks bod) $$ app req sres <- liftIO $ runResponse res return sres If 'app' is the wai Application (gotten through toWaiApp), and that app works well with url-encoded. And bod is a lazy char8 bytestring containing a well formed multi-part request body, then my yesod handler should end up having the file data available? right? Also, are there any tests you recommend I do to figure what's going wrong? I can alternatively just publish this testing library/framework now with the broken functionality so you can fork it from github. cheers! ----nubis :)

1 1