Re: [Haskell-cafe] MonadPeelIO instance for monad transformers on top of forall
On 5 February 2011 02:35, Sebastian Fischer fisc...@nii.ac.jp wrote: I have not used monad-peel before so please ignore my comment if I am missing something obvious. The documentation mentions that Instances of MonadPeelIO should be constructed via MonadTransPeel, using peelIO = liftPeel peelIO. I think this would work at least in your simplified example as ReaderT is an instance of MonadTransPeel. Maybe you can take the same route with your actual transformer? I did indeed try this, but the error message was even more incomprehensible than my attempt to lift the MonadPeelIO (ReaderT () IO) instance directly! My reading of the error was that it suffers from the same problem (too little polymorphism). Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadPeelIO instance for monad transformers on top of forall
On 5 February 2011 04:19, Anders Kaseorg ande...@mit.edu wrote: Just to demonstrate that I didn’t use the triviality of ReaderT (), here’s a less trivial example with ReaderT and StateT: This is superb, thank you! I would never have come up with that :-) It still seems to fail somehow on my real example, but I'm confident I can get it working now. Many thanks! Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
Lately I've been trying to go the other direction: make a large section of formerly strict code lazy. There used to be a couple of tools trying to make suggestions when a function could be made less strict (Olaf Chitil's StrictCheck and another that escapes memory at the moment). Often, it comes down to some form of eta-expansion - making information available earlier [(\x-f x) tells us we have a function without having to evaluate f, (\p-(fst p,snd p)) marks a pair without needing to evaluate p, and so on]. I fully agree that once code size gets big these problems get a lot harder. You have to be very careful passing around state that you don't do anything that causes too much to be evaluated at the wrong time. Generally, the trick is to develop an intuitition early, before growing the program in size;-) However, as long as you can run your big code with small data sets, you might want to try GHood, maintained on hackage thanks to Hugo Pacheco: http://hackage.haskell.org/package/GHood http://community.haskell.org/~claus/GHood/ (currently unavailable:-( The latter url has a few examples and a paper describing how GHood can be useful for observing relative strictness, ie, when data at one probe is forced relative to when it is forced at another. (it seems that citeseerx has a copy of the paper, at least: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.1397 ) For instance, if you put one probe on the output and one on the input, you can see which parts of the input are forced to produce which parts of the output. As I said, small data sets help, but since you put in probes manually and selectively, large code size should not interfere with observations (though it might hinder intuition:-). But there's definitely a knack to be learned, and I think I might eventually get better at it. For example, I realized that the criteria to make something non-strict wrt data dependency are the same as trying to parallelize. Sometimes it's easier to think what do I have to do to make these two processes run in parallel and that's the same thing I have to do to make them interleave with each other lazily. Sometimes, I think of non-strict evaluation as spark a thread for everything, then process the threads with a single processor.. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 2/5/11 4:26 AM, Claus Reinke wrote: Lately I've been trying to go the other direction: make a large section of formerly strict code lazy. There used to be a couple of tools trying to make suggestions when a function could be made less strict (Olaf Chitil's StrictCheck and another that escapes memory at the moment). Perhaps you're thinking of the chasing bottoms[1] library? [1] http://hackage.haskell.org/package/ChasingBottoms -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Concurrency best practices?
So I'm working on a project that uses STM to run a lot of things in parallel without the headaches of locks. So far it's working beautifully, STM rocks. But there's one snag... Sometimes I need those threads to do some IO like printing logging info. I'd like to make these IO chunks atomic with respect to one another so that the logging output isn't garbage. Since I'm using STM everywhere else, I'd love to use it for this too (instead of mixing STM and non-STM concurrency) except you can't embed IO in STM. I could just use STM vars as locks to force the atomicity, but locks are ugly and bug-prone. So what's the current best practice for doing this kind of thing? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 2/5/11 4:26 AM, Claus Reinke wrote: Lately I've been trying to go the other direction: make a large section of formerly strict code lazy. There used to be a couple of tools trying to make suggestions when a function could be made less strict (Olaf Chitil's StrictCheck and another that escapes memory at the moment). Probably Sloth: http://korsika.informatik.uni-kiel.de/~jac/wordpress/ http://korsika.informatik.uni-kiel.de/~jac/wordpress/wp-content/uploads/PADL2011.pdf Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
Hi Wren, maybe Twilight STM is for you: http://hackage.haskell.org/package/twilight-stm Sebastian On Sat, Feb 5, 2011 at 6:46 PM, wren ng thornton w...@freegeek.org wrote: So I'm working on a project that uses STM to run a lot of things in parallel without the headaches of locks. So far it's working beautifully, STM rocks. But there's one snag... Sometimes I need those threads to do some IO like printing logging info. I'd like to make these IO chunks atomic with respect to one another so that the logging output isn't garbage. Since I'm using STM everywhere else, I'd love to use it for this too (instead of mixing STM and non-STM concurrency) except you can't embed IO in STM. I could just use STM vars as locks to force the atomicity, but locks are ugly and bug-prone. So what's the current best practice for doing this kind of thing? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
Hi Wren, I am maintaining Twilight STM, and it seems that it might indeed solve your problem. We also use it for logging, locks, and other advanced STM stuff like inconsistency repair. If you are interested, let me know. There is a new version coming up soon, with new features and improved implementation. - Annette Am 05.02.2011 um 11:42 schrieb Sebastian Fischer: Hi Wren, maybe Twilight STM is for you: http://hackage.haskell.org/package/twilight-stm Sebastian On Sat, Feb 5, 2011 at 6:46 PM, wren ng thornton w...@freegeek.org wrote: So I'm working on a project that uses STM to run a lot of things in parallel without the headaches of locks. So far it's working beautifully, STM rocks. But there's one snag... Sometimes I need those threads to do some IO like printing logging info. I'd like to make these IO chunks atomic with respect to one another so that the logging output isn't garbage. Since I'm using STM everywhere else, I'd love to use it for this too (instead of mixing STM and non-STM concurrency) except you can't embed IO in STM. I could just use STM vars as locks to force the atomicity, but locks are ugly and bug-prone. So what's the current best practice for doing this kind of thing? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
On Sat, Feb 5, 2011 at 10:46, wren ng thornton w...@freegeek.org wrote: Sometimes I need those threads to do some IO like printing logging info. Logging is easy, especially if you don't mind a performance hit. Create an STM.TChan and throw each log message on it. Have a separate forkIO'ed process that reads off log messages and prints them. The model one step up is to generalize the logger so it forwards log messages to handlers. This way you can do logging to stdout, binary serialized logging to disk, logging to memory ring buffers, logging to databases and so on. This generalized model is used a lot in Erlang. The price however, is that you may be running into a bottleneck upon entering messages on the TChan because sadly I can't remember if it is asynchronous or synchronous when you add messages to it. It won't work for general IO either (Though perhaps it is a Writer monad). -- J. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] community server hasktags learned recursing into directories
* Marc Weber marco-owe...@gmx.de [2011-02-04 22:35:53+] hasktags learned about how to recurse into subdirectories itself. This is especially useful for windows because writing scripts can be done but is less well known (http://stackoverflow.com/questions/4865391/answer/submit) Thanks for that! I planned to do this some time ago, but hadn't found a way to detect symlink loops portably (or in any way on Windows). Do you handle this problem in any way? -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with xhtml 1.5.1.1: html tags are split
On Thu, May 13, 2010 at 11:38 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, May 11, 2010 at 3:00 AM, Bjorn Bringert bj...@bringert.net wrote: I support finding a new maintainer. Alright; as the old maintainer, I guess it falls on you to advertise on -cafe and libraries. Has a request gone out yet? I didn't notice anything (maybe it got lost in all the recent haskell.org downtime), and the current Hackage page of xhtml is still listing Bjorn. Anyway, John MacFarlane has found a workaround which he's implemented in HEAD Pandoc (http://code.google.com/p/pandoc/issues/detail?id=134); from http://groups.google.com/group/pandoc-discuss/browse_frm/thread/915586b5c5e264b6# : Many people have wanted pandoc to produce more normal HTML output, without nesting, but with line breaks between block elements (where they aren't semantically significant). Something like this: ul lia a href=/foolink/a/li lianother list item/li /ul I've found that I can get this kind of output, even using Text.XHtml's renderer, by modifying the writer to insert raw newlines after block elements, and using 'showHtmlFragment' rather than 'prettyHtmlFragment'. This may be useful for other people to know. (There are quite a few users of xhtml: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/xhtml-3000.2.0.1#direct ) -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 03/02/2011 09:37 PM, Daniel Fischer wrote: To illustrate your prediction about the side-issues: On Thursday 03 February 2011 22:10:51, Andrew Coppin wrote: Consider for a moment the original implementation with Data.Map. Adding a seq or two here will do no good at all; seq reduces to WHNF. What we are wanting is NF, and I can see no way at all of doing that. Check out Data.Map.insertWith' Random fact: Data.Map.insertWith' exists. Data.IntMap.insertWith' does *not* exist. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
That got me thinking... What would happen if, instead of Integer, we had two types, evaluated Integer and possibly unevaluated Integer? What if the strictness or otherwise of a data structure were exposed at the type level? Oh, you mean like !Int and Int in Clean? I used to find bang *types* rather easier to deal with than I now do bang *patterns*. I have no idea what the syntax for that would look like, Clean? I didn't think Clean supported laziness at all? I thought it was a strict language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 03/02/2011 10:15 PM, Johan Tibell wrote: First, we need to stop pretending that you can use Haskell effectively without first learning to reason about program evaluation order. Writing a program in *any* language without understanding the performance implications of different language constructs is unlikely to produce performant code. OTOH, Haskell is unusual in just how easily seemingly trivial alternations of a few characters can cause utterly *giagintic* performance differences in both time and space. Learning how is not terrible difficult, but there's very little material on how to do it [1]. Some of us have learnt it the hard way by experimentation or by talking to people who do understand lazy evaluation [2] (the Simons, Don, and Bryan to name a few). I think perhaps the problem is that Haskell's execution model is so utterly *implicit*. In some imperative languag, if you call an expensive function, it will be expensive. In Haskell, if you call an expensive function and then never touch the result, it's cheap. Touch the result once, and you might get fusion. Touch it twice and suddenly the space complexity of the program changes. So simply adding a debug statement can utterly transform your program's runtime. What it comes down to is: Tiny changes sometimes have profound effects. Best of all, there is little tool support for detecting these effects. If you change your program and it suddenly slows down, you need to go look at what you just changed. But if you write a brand new program and it's drop-dead slow, where do you start looking? (Assuming you're not writing a micro-benchmark.) At the very least we need to teach people how to tell which arguments a pure function is strict in by looking at its definition. That's not necessarily tractible. It depends on what other functions you call. Many functions have obvious strictness properties, but very few have *documented* strictness properties. That keeping a simple map of counters is tricky should tell us that something is wrong. Agreed. Many strictness related problems people have are due to common data types like Maybe, tuples, and arrays being lazy. This is rarely what you want. I'm not sure that's 100% true. You might have a function that returns a tuple, and on occasion you're only actually interested in one of the two results. But that looks like the exception rather than the rule. Lazy lists are rather useful, but it looks like strict lists would be useful too. The number of times I've written !String and then thought hey, wait, that's not helping me... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
For what it's worth I saw the problems in your counting examples right away, without reading the explanatory text below. Yes, they were pretty obvious with enough experience. For beginners I expect it to be a rather insidious trap. Beginners or anybody coding Haskell while not completely awake. ;-) Hopefully that means that it's possibly to learn how to spot such things without resorting to e.g. running the program or reading Core *gasp*. Within limits. Detrimental laziness or strictness can be arbitrarily well hidden. I agree. Unfortunately... :-/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Byte Histogram
On 04/02/2011 07:30 AM, Johan Tibell wrote: Right. It can still be tricky. I think we can get rid of a large number of strictness issues by using strict data structures more often, this should help beginners in particular. For the rest better tooling would help. For example, a lint tool that marked up code with the strictness information inferred by the compiler would be useful. I had time to write one I would make the output look like HPC html reports, with one color for strict function arguments and one color for lazy function arguments. There's the RTS watch that makes it spit out heap profiling information. However, determining what the hell this data actually means is well beyond my powers of comprehension. I keep hoping that eventually the mechanism used by ThreadScope will eventually allow you to compile a program with profiling, run it, and observe absolutely everything about its execution - how many cores it's using, how much RAM is allocated to each generation, etc. Then again, if you could actually single-step through a Haskell program's execution, most strictness issues would become quite shallow. Indeed, when I first learned Haskell, the very concept of lazyness ever being detrimental was incomprehensible to me. I couldn't imagine why you would ever want to turn it off. But then I built a simple program that single-steps through Haskell(ish) expressions, and suddenly discovered that foldl' needs to exist... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
There's the stm-io-hooks [1] package but it looks like it hasn't been updated in a while. -deech [1]http://hackage.haskell.org/package/stm-io-hooks On Sat, Feb 5, 2011 at 3:46 AM, wren ng thornton w...@freegeek.org wrote: So I'm working on a project that uses STM to run a lot of things in parallel without the headaches of locks. So far it's working beautifully, STM rocks. But there's one snag... Sometimes I need those threads to do some IO like printing logging info. I'd like to make these IO chunks atomic with respect to one another so that the logging output isn't garbage. Since I'm using STM everywhere else, I'd love to use it for this too (instead of mixing STM and non-STM concurrency) except you can't embed IO in STM. I could just use STM vars as locks to force the atomicity, but locks are ugly and bug-prone. So what's the current best practice for doing this kind of thing? -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
On 05/02/2011 12:56 PM, Jesper Louis Andersen wrote: On Sat, Feb 5, 2011 at 10:46, wren ng thorntonw...@freegeek.org wrote: Sometimes I need those threads to do some IO like printing logging info. Logging is easy, especially if you don't mind a performance hit. Create an STM.TChan and throw each log message on it. Have a separate forkIO'ed process that reads off log messages and prints them. This is the solution I immediately thought of too. Much cleaner abstraction than grubbing around in low-level I/O implementations and such. The price however, is that you may be running into a bottleneck upon entering messages on the TChan because sadly I can't remember if it is asynchronous or synchronous when you add messages to it. Presumably messages added to the channel appear immediately after the transaction commits. The problem is, I think GHC's STM implementation might mean that if two transactions both try to log a message, they both get rolled back... It won't work for general IO either (Though perhaps it is a Writer monad). There is of course a *reason* why you can't do general I/O inside a transaction: The transaction may have seen inconsistent state, and it may be re-executed arbitrary times. Think about that before you try to shove real I/O into a transaction abstraction... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] combined parsing pretty-printing
Tillmann, I've been looking into you packages, very neat ideas and a nice implementation really. I've already implemented a toy example and it worked great. Now I am trying to use your library in a more serious piece of code, and I've realised that defineIsomorphisms doesn't support record constructors. To be precise, you handle the case for NormalC in the code, however you do not handle RecC. I don't think this will be a difficult thing to add. Is there any reason for you not to support RecC? Best, 2011/1/26 Tillmann Rendel ren...@informatik.uni-marburg.de Hi Ozgur, Ozgur Akgun wrote: I can write (separately) a parser and a pretty-printer [...] Is there any work to combine the two? Brent Yorgey wrote: Maybe take a look at Invertible Syntax Descriptions: Unifying Parsing and Pretty Printing by Tillmann Rendel and Klaus Ostermann from last year's Haskell Symposium: http://www.informatik.uni-marburg.de/~rendel/unparse/ It's a beautiful paper, and perhaps the code will work for you (although it's too bad it's not on Hackage). Indeed, I started this project for exactly the reason Ozgur describes: I needed to duplicate a lot of information between parsers and pretty printers and was annoyed about it. With invertible syntax descriptions, I now write a single program, which looks like a combinator parser (think Parsec), but can work as a pretty printer, too. I just uploaded the code from the paper (and some additional combinators) to Hackage: http://hackage.haskell.org/package/partial-isomorphisms http://hackage.haskell.org/package/invertible-syntax I use this code for the implementation of some very small languages (think lambda calculus). This works fine. I haven't really tried it for larger languages, but we have two students here in Marburg implementing a parser for Java using the library, so we are going to have experience with larger languages in a few weeks (months?). If you give it a try, I would be happy to receive success stories, bug reports, patches, feature requests etc. I want to keep working on this, and I am open for suggestions. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
On Sat, Feb 5, 2011 at 17:13, Andrew Coppin andrewcop...@btinternet.com wrote: On 05/02/2011 12:56 PM, Jesper Louis Andersen wrote: Presumably messages added to the channel appear immediately after the transaction commits. The problem is, I think GHC's STM implementation might mean that if two transactions both try to log a message, they both get rolled back... Yes, this is the performance caveat I was hinting at. When logging becomes heavy and transactions are *not* completing, you will have transaction retries due to the logging. If the transaction completes however, it is not that much of a problem. -- J. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
On Sat, Feb 5, 2011 at 8:19 AM, Jesper Louis Andersen jesper.louis.ander...@gmail.com wrote: On Sat, Feb 5, 2011 at 17:13, Andrew Coppin andrewcop...@btinternet.com wrote: On 05/02/2011 12:56 PM, Jesper Louis Andersen wrote: Presumably messages added to the channel appear immediately after the transaction commits. The problem is, I think GHC's STM implementation might mean that if two transactions both try to log a message, they both get rolled back... Yes, this is the performance caveat I was hinting at. When logging becomes heavy and transactions are *not* completing, you will have transaction retries due to the logging. If the transaction completes however, it is not that much of a problem. I recall reading that clojure has a concept of associative combination. If you can declare that certain operations are associative then the runtime doesn't have to care if they get out of order. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] combined parsing pretty-printing
Great! That was pretty fast :) Are you going to update invertible-syntax to use partial-isomorphisms-0.2? 2011/2/5 Tillmann Rendel tillm...@rendel.net Hi Ozgur, Ozgur Akgun wrote: I've already implemented a toy example and it worked great. Now I am trying to use your library in a more serious piece of code, and I've realised that defineIsomorphisms doesn't support record constructors. To be precise, you handle the case for NormalC in the code, however you do not handle RecC. I don't think this will be a difficult thing to add. Is there any reason for you not to support RecC? No reason at all. I just generalized the Template Haskell macros. They now support: * newtypes * infix constructors * record constructors Infix constructors are only support by constructorIso, though, not by defineIsomorphisms, because I can't think of a good automatic naming scheme. Suggestions welcome. The code is on hackage. There are still some constructors which are not supported: constructors of GADTs as well as data or newtype instances, and constructors with existentials. I would need to think about typing issues before supporting these. Tillmann -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Storing passwords securely
The usual advice on how to store passwords securely is use bcrypt, but since there seem to be no Haskell bindings for bcrypt, the other good option is to iterate a salted hash function at least 1000 times. In order for people to get this right, there should be a library with a really simple API that makes it Just Work. I think I have such an API, but I'd like to hear if anybody else has suggestions before I go releasing it onto Hackage. The code is here: https://github.com/PeterScott/pwstore The part of the API that people have to care about is two functions. makePassword creates a hashed, salted password that you can store in a database. verifyPassword takes this hashed, salted password and a user's password input, and tells you if it matches. Like this: makePassword (B.pack hunter2) 12 sha256|12|lMzlNz0XK9eiPIYPY96QCQ==|1ZJ/R3qLEF0oCBVNtvNKLwZLpXPM7bLEy/Nc6QBxWro= verifyPassword (B.pack wrong guess) passwordHash False verifyPassword (B.pack hunter2) passwordHash True There's also a function for increasing the number of hash iterations on stored password hashes, to compensate for Moore's law. Does this sound reasonable? Also, I have a pure-Haskell version and a version which depends on some C code, for speed (about 25x difference). Does anybody care about the pure Haskell version, or should I just drop it and require the faster C/Haskell mixed version? Thanks, -Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Storing passwords securely
Have you seen the PBKDF2 library? http://hackage.haskell.org/package/PBKDF2 Does that look like a reasonable way to store passwords securely? - jeremy On Feb 5, 2011, at 8:12 PM, Peter Scott wrote: The usual advice on how to store passwords securely is use bcrypt, but since there seem to be no Haskell bindings for bcrypt, the other good option is to iterate a salted hash function at least 1000 times. In order for people to get this right, there should be a library with a really simple API that makes it Just Work. I think I have such an API, but I'd like to hear if anybody else has suggestions before I go releasing it onto Hackage. The code is here: https://github.com/PeterScott/pwstore The part of the API that people have to care about is two functions. makePassword creates a hashed, salted password that you can store in a database. verifyPassword takes this hashed, salted password and a user's password input, and tells you if it matches. Like this: makePassword (B.pack hunter2) 12 sha256|12|lMzlNz0XK9eiPIYPY96QCQ==|1ZJ/ R3qLEF0oCBVNtvNKLwZLpXPM7bLEy/Nc6QBxWro= verifyPassword (B.pack wrong guess) passwordHash False verifyPassword (B.pack hunter2) passwordHash True There's also a function for increasing the number of hash iterations on stored password hashes, to compensate for Moore's law. Does this sound reasonable? Also, I have a pure-Haskell version and a version which depends on some C code, for speed (about 25x difference). Does anybody care about the pure Haskell version, or should I just drop it and require the faster C/Haskell mixed version? Thanks, -Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Storing passwords securely
On Sat, Feb 5, 2011 at 10:54 PM, Jeremy Shaw jer...@n-heptane.com wrote: Have you seen the PBKDF2 library? http://hackage.haskell.org/package/PBKDF2 http://hackage.haskell.org/package/PBKDF2 Does that look like a reasonable way to store passwords securely? Yes, I looked at it before I started on pwstore. The code does indeed calculate the PBKDF2 key derivation function, and the documentation is terse but descriptive. It's usable, but it's not *trivial* to use. With the PBKDF2 library, a user has to: 1. Understand what PBKDF2 is, at least well enough to know what the documentation is talking about when it mentions things like length of prf output. 2. Convert passwords to and from [Word8], which is not a very common type to have immediately on hand. 3. Generate unique salts for each user. Easy, but it would be nice if the library handled this for you. 4. Manage the salt and the hashed password separately. Again easy, but a small hassle. 5. Store the salt and hashed password as byte vectors. Some storage methods may have trouble with data that may contain (for example) the '\NUL' character. This is why my library uses base64 encoding. Some more problems are that the library is slow (thanks to the unoptimized hash functions in Crypto) and the documentation is not as clear as it could be about what a newbie needs to do. Also, if you want to extend a bunch of existing hashed passwords with more iterations as hardware gets faster, there's no obvious easy way to do that with PBKDF2. In other words, while the PBKDF2 library is technically correct, it's not as slick and easy-to-use as a password storage library should be, and *must* be, if we want everyone to store passwords properly. One of the aphorisms of cryptography is don't roll your own, but as long as the existing code feels like it's not quite what the users are looking for, there will still be the temptation to ignore this advice and roll your own anyway. I want to make something that people can use in ten minutes and say there, I'm done. -Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AES on 32-bit system
OK, now I'm sure I tried it before: I tried switching Haskellers over to AES with that code change you mention, and it results in runtime crashes (I assume segfaults, I didn't really look into it too much). So Svein, please disregard my requested code change, it's a bad idea. Michael On Fri, Feb 4, 2011 at 8:16 AM, Michael Snoyman mich...@snoyman.com wrote: Wow, I thought I'd tried that before, I guess not. Yes, that compiles, and an initial test seems that it does not break at runtime either. I'll email the author and see if he can make that change. Michael On Fri, Feb 4, 2011 at 8:11 AM, Daniel Peebles pumpkin...@gmail.com wrote: Knowing nothing about the package or its code, it looks like a typo to me. The stdint.h naming of types would have it be uint64_t, not uint_64t. Could that be it? On Fri, Feb 4, 2011 at 6:00 AM, Michael Snoyman mich...@snoyman.com wrote: Hi everyone, Does anyone else have trouble installing the AES package on a 32-bit system? My system at home installs it just fine, but my VPS chokes with the following error messages (plus a bunch of warnings): cbits/ctr_inc.c:11:0: error: 'uint_64t' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: (Each undeclared identifier is reported only once cbits/ctr_inc.c:11:0: error: for each function it appears in.) cbits/ctr_inc.c:11:0: error: 'ctr' undeclared (first use in this function) cbits/ctr_inc.c:11:0: error: expected expression before ')' token It's actually for this very reason that I'm still maintaining the OpenSSL backend for http-enumerator: I think the tls package is stable enough now to be used in production environments (kudos to Vincent by the way). However, I can't use it in production if I can't build one of its dependencies. This bug is also preventing me from adding some nice features to http-enumerator, such as checking validity of SSL certificates. Anyone have any thoughts? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
