- Haskell-Cafe - Haskell.org

ANNOUNCE: eccrypto 0.1.0, timing attack safe cryptography in Haskell
by Marcel Fourné 19 Feb '19

19 Feb '19

Dear Haskell Community! I'd like to introduce some new cryptographic code, containing a verified[*] timing-attack safe pure Haskell[**] implementation of Ed25519 and as of yet unverified implementations of textbook ECDH and ECDSA on the NIST prime curves. Install it by $ cabal install eccrypto or download it from Hackage[0]. Also contained are test vectors, usable by the trusty $ cabal test as well as benchmarking code which you can invoke by $ cabal bench if you want to try my code before using it. Please note that this is a one person project, so there is still much room for optimization. The intended focus groups are implementors of cryptographic protocols as well as other cryptographers and interested third parties. My code uses no[**] embedded C code or assembly to achieve timing attack resistance, only careful Haskell constructions in the internal modules, the obligatory hackers footgun included only in those. ;-) Security sketch: The timing attack safety is built on the constant time criterion, namely, that no branches or memory access indices may be based on the content of the secret key bits. The name of this criterion is from the strict evaluation world of cryptography, but does not prohibit non-strict evaluation semantics per se. The API is only slightly different from contemporary libraries like "ed25519"[1], but the content of the signatures is just the same. The number of dependencies are also in the same ballpark, if you'd like to use the code for infrastructure - but in that case, please talk to me to not use unverified/insecure operations! Best of wishes to a thriving community, Marcel Fourné [*]: paper upcoming but as of now it only exists in my notes; analysis was done "by hand" on assembly generated by GHC 8.4.4, mechanization based on established proofs is planned [**]: using integer-gmp, might change in the future to low-level Haskell [0]: https://hackage.haskell.org/package/eccrypto-0.1.0 [1]: https://hackage.haskell.org/package/ed25519

1 0

Looking for JavaScript(V8)-compilant parser
by Javran Cheng 19 Feb '19

19 Feb '19

Hi Cafe, tl;dr: I'm wondering if there are existing parsers for parsing any dateString that can be accepted by `Date.parse` of JavaScript(V8). The input looks like "Fri, 08 February 2019 12:34:56 +0900". At first I checked [MDN]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Ob…) and turns out it's very close to [IETF-compliant RFC 2822 timestamps]( https://tools.ietf.org/html/rfc2822#page-14) but not quite: as I then found [hsemail]( http://hackage.haskell.org/package/hsemail-2/docs/Text-Parsec-Rfc2822.html) to be promising, but it rejected "Fri, 08 February 2019 12:34:56 +0900" but accepted "Fri, 08 Feb 2019 12:34:56 +0900" (notice that RFC2822 does not accept full month name). Refering to language spec doesn't help ( http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.4.2) as it doesn't mention RFC2822 at all. So it seems `Data.parse` accepts a superset of RFC2822 and a version of ISO8601 (as described in MDN above) but I'm not sure what exactly is the accepting set of inputs. Before I start working on a quick and dirty solution (it should work patching hsemail to accept full month name) I want to know if there are existing parsers for this purpose? Thanks! -- Javran (Fang) Cheng

1 0

Amazonka: is it possible to work around deserialisation bug?
by Magnus Therning 18 Feb '19

18 Feb '19

I just created issue #517 on Amazonka [^1] which got me thinking. Is my only option to wait for the bug to be fixed or can I hack my way around it? I looked around in the documentation for Amazonka a bit but failed to find some obvious way to hack together a "send this request but give me the response in JSON". Which is why I'm trying my luck here. I suspect I'm not the first Amazonka user to find myself in this situation, so hopefully someone's got a solution already. /M [^1]: https://github.com/brendanhay/amazonka/issues/517 -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus(a)therning.org twitter: magthe http://magnus.therning.org/ Computers are useless. They can only give you answers. — Pablo Picasso

3 3

Re: [Haskell-cafe] Need help understanding a GADT related error
by David Banas 18 Feb '19

18 Feb '19

Hilco, Your first error arrises, because you’re offering to the caller of `h` that she may demand any type of `a`, but are “hard-wiring” `a :: T E` in the definition of that function. Reflecting that fact in the function type signature eliminates the error: -- h :: H (T a) h :: H (T E) h [] = (E' (E "E"), []) h (head:rest) = (E' (E ("E")), rest) Your second error is explained (I hope) in the comments I’ve added to your original code: tt' :: [Char] -> [T a] tt' = tt h [a, b] -- tt :: H t -> [P Char t] -> TT t -- :: ([Char] -> (t, [Char])) -> [P Char t] -> [Char] -> [t] -- -- h :: [Char] -> (t, [Char]) ~ H (T E) -- h :: [Char] -> (t, [Char]) ~ [Char] -> (T E, [Char]) -- ==> t ~ T E -- -- [a, b] :: [P Char t] -- a :: P Char (T E) /~ P Char (T A) -- b :: P Char (T E) /~ P Char (T B) -db

1 0

Need help understanding a GADT related error
by Hilco Wijbenga 18 Feb '19

18 Feb '19

Hi all, I created some GADT code (see https://pastebin.com/vkJ3RzNA and below). When compiling this I get these errors: $ stack build parser-0.1.0.0: build (exe) Preprocessing executable 'parser' for parser-0.1.0.0.. Building executable 'parser' for parser-0.1.0.0.. [2 of 2] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/parser/parser-tmp/Main.o ) /home/hilco/workspaces/haskell/parser/src/Main.hs:30:18: error: • Couldn't match type ‘a’ with ‘E’ ‘a’ is a rigid type variable bound by the type signature for: h :: forall a. H (T a) at src/Main.hs:29:1-12 Expected type: T a Actual type: T E • In the expression: E' (E "E") In the expression: (E' (E "E"), []) In an equation for ‘h’: h [] = (E' (E "E"), []) • Relevant bindings include h :: H (T a) (bound at src/Main.hs:30:1) | 30 | h [] = (E' (E "E"), []) | ^^^^^^^^^^ /home/hilco/workspaces/haskell/parser/src/Main.hs:34:16: error: • Couldn't match type ‘B’ with ‘A’ Expected type: P Char (T A) Actual type: P Char (T B) • In the expression: b In the second argument of ‘tt’, namely ‘[a, b]’ In the expression: tt h [a, b] | 34 | tt' = tt h [a, b] | ^ -- While building custom Setup.hs for package parser-0.1.0.0 using: /home/hilco/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1 build exe:parser --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Why is "T a" not a more generic version of "T E"? Why doesn't "T E + T A + TB" yield "T a" as a generic type? Cheers, Hilco 1 {-# LANGUAGE GADTs #-} 2 3 module Main where 4 5 data PR t a = PR (Maybe ([t], a)) 6 data P t a = P ([t] -> PR t a) 7 8 a :: P Char (T A) 9 a = undefined 10 11 b :: P Char (T B) 12 b = undefined 13 14 data A = A 15 data B = B 16 data E = E String 17 18 data T a where 19 A' :: T A 20 B' :: T B 21 E' :: E -> T E 22 23 type H t = [Char] -> (t, [Char]) 24 type TT t = [Char] -> [t] 25 26 tt :: H t -> [P Char t] -> TT t 27 tt = undefined 28 29 h :: H (T a) 30 h [] = (E' (E "E"), []) 31 h (head:rest) = (E' (E ("E")), rest) 32 33 tt' :: [Char] -> [T a] 34 tt' = tt h [a, b] 35 36 main :: IO () 37 main = putStrLn "Hello"

3 2

Re: [Haskell-cafe] Add newtype for Alternative using QuantifiedConstraints in base-4.13
by Ruben Astudillo 18 Feb '19

18 Feb '19

I wonder if it is useful at all. If `f a` already has a Monoid instance, you can use `(<>)` already instead of (<|>) with pretty much the same laws. Plus you don't have to import `(<>)` as it comes from the Prelude where `(<|>)` doesn't. Does this have an use case or is just for aesthetic completeness? -- -- Ruben -- pgp: 4EE9 28F7 932E F4AD

1 0

Updating the dom-lt package
by Andreas Klebinger 17 Feb '19

17 Feb '19

I would like to have a updated version of dom-lt ( http://hackage.haskell.org/package/dom-lt ) on hackage. Matt Morrow uploaded the last version in 2009 and it has since become incompatible with current container versions. I'm posting here to make it known that I plan to take over the package to upload an update if I fail to reach him and he doesn't respond. (Which seems likely since the the domain is expired). Cheers Andreas Klebinger

2 1

Call For Presentations: Compose NYC, June 24-25, 2019
by MightyByte 17 Feb '19

17 Feb '19

Compose is a conference focused specifically on strongly typed functional programming languages. It will be held in New York on Monday and Tuesday, June 24 -25, 2019. Registration will be open shortly. http://www.composeconference.org/201 ( http://www.composeconference.org/2017 ) 9 To get a sense of Compose, you can check out the great talks from past conferences: https://www.youtube.com/channel/UC0pEknZxL7Q1j0Ok8qImWdQ ( https://www.youtube.com/channel/UC0pEknZxL7Q1j0Ok8qImWdQ ) Below is our call for presentations. http://www.composeconference.org/2019/cfp/ ( http://www.composeconference.org/2016/cfp/ ) In past years, we have also hosted an unconference over the weekend adjacent to the conference. The unconference details this year have not been finalized yet, but if you’re interested you may want to keep that in mind when making travel plans. *** Compose Conference NYC 2019 Call for Presentations June 24 -25, 2019 New York City The audience for Compose is people using Haskell, PureScript, OCaml, F#, SML, and other strongly typed functional programming languages who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However presentations on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: *Library/Tool Talks* — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. *Production Systems* — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. *Theory made Practical* — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. Check out the Compose YouTube channel ( https://www.youtube.com/playlist?list=PLNoHgLVTxtaoolkQo4hLy4ZsA1prUJ51m ) to see videos of talks we've had previously and get an idea of the kinds of topics we usually feature. We also welcome presentations for more formal tutorials. Tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is *April 23, 2019*. We will send out notice of acceptance by *April 30th*. We prefer that submissions be via the EasyChair website ( https://easychair.org/conferences/?conf=compose2019 ( https://easychair.org/conferences/?conf=compose2019 ) ). Please suggest a title, and describe the topic you intend to speak on. Talks can be either 30 or 45 minutes, please indicate how much time you would prefer to take. You may submit multiple talks if you have several ideas and are unsure which would be the most likely to be accepted. Accepted talks will be asked to submit slides for review prior to the conference. Feel free to include any additional information on both your expertise and interesting elements of your topic that would be appropriate for inclusion in the public abstract. Furthermore, if your abstract doesn't feel "final"—don't worry! We'll work with you to polish it up. If you want to discuss your presentation(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at nyc(a)composeconference.org ( nyc(a)composeconference.org ). We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. Diversity We would like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome your contributions and encourage you to apply! Best, Doug Sent via Superhuman ( https://sprh.mn/?vip=mightybyte@gmail.com )

1 0

[ANN] stdio-0.1.0.0 - A simple and high performance IO toolkit for Haskell
by 寒东 17 Feb '19

17 Feb '19

Dear Haskellers! We're pleased to announce the first public version of stdio, a simple and high performance IO toolkit for Haskell. This package provides a simple and high performance IO toolkit for Haskell, including packed vectors, unicode texts, socket, file system, timers and more! The Hackage link is http://hackage.haskell.org/package/stdio-0.1.0.0. This project started as an experiment of combining libuv with GHC runtime, the result is recorded in our Haskell 2018 paper A High-Performance Multicore IO Manager Based on libuv (Experience Report) <https://github.com/haskell-stdio/stdio/blob/master/docs/A%20High-Performanc…> , which is pretty good comparing to the old IO manager in base. The IO manager part is stable and fast now. The package also provides new vector and new text type based on ByteArray# primitive, which is not limited to pinned memory. As GHC 8.6 release have added unaligned access primitives to ByteArray#, We think it's a good to release our work. The new vector and text (internal using UTF-8 encoding)'s performance is comparative to bytestring and text ones, and we strive to provide the similiar API. Some unicode processing such as normalization and casefolding is also provide, based on a C unicode library utf8rewind <https://bitbucket.org/knight666/utf8rewind>. To make our package more useful, we rebuild Builder and Parser type from groud, add TCP socket and filesystem support, so that user can start using it to do some simple task, such as parsing a CSV file or starting a TCP server and communicate in protocols. We also provide high performance timer and logger module, which is useful in practical engineering tasks. For installation guide and examples, please see the project's README. As we (I and Tao He) both are not native english speakers, the document quality is not as satisfying as it can be, please help! If you meet issues with installing, bugs, questions, please fill an issue on github: https://github.com/haskell-stdio/stdio. Happy hacking as always! Dong Han, Tao He Feb 16. 2019

4 3

Fwd: [ANN] stdio-0.1.0.0 - A simple and high performance IO toolkit for Haskell
by Dong Han 17 Feb '19

17 Feb '19

> In particular, I'd avoid utf8rewind because the author believes that deviating from a standard improves security. The length function is indeed problematic, so we roll our own, but the rest part of utf8rewind comply with Unicode 8.0 AFAICT, the code quality seems good too, but like you said, we're not going to commit to a specific UTF-8 implementation. As for now un8rewind seems a pretty good choice. > You should split the library, into stuff that does fast byte shoving, and into stuff that does fast byte processing. That way, things can start to improve and evolve independently. I just haven't got that much energy to do that, if we got lots of users some day, and people think spliting is better, then we can do that of course ; ) Cheers Dong On Sat, Feb 16, 2019 at 10:30 PM Joachim Durchholz <jo(a)durchholz.org> wrote: > Am 16.02.19 um 13:23 schrieb 寒东: > > Some unicode processing such as normalization and casefolding is also > provide, based on a C unicode libraryutf8rewind < > https://bitbucket.org/knight666/utf8rewind>. > > FWIW the rest looks fine, but committing to a specific UTF-8 > implementation is risky. Unicode is a large and complicated standard, > and constantly evolving; I am sceptical that a one-man library like > utf8rewind can keep up with that, and I'd wrap a mature Unicode library > (such as ICU) rather than place my bet on a one-man show like utf8rewind. > > In particular, I'd avoid utf8rewind because the author believes that > deviating from a standard improves security. > (See his comment in > > https://bitbucket.org/knight666/utf8rewind/issues/8/length-function-should-… > .) > I do not think that's a well-considered policy, and certainly does not > make me think that his code is well-audited. Including such a thing in > such a basic library as stdio seems unwise to me. > > > To make our package more useful, we rebuild Builder and Parser type from > groud, add TCP socket and filesystem support, so that user can start using > it to do some simple task, such as parsing a CSV file or starting a TCP > server and communicate in protocols. We also provide high performance timer > and logger module, which is useful in practical engineering tasks. > > You should split the library, into stuff that does fast byte shoving, > and into stuff that does fast byte processing. > That way, things can start to improve and evolve independently. > > > For installation guide and examples, please see the project's README. As > we (I and Tao He) both are not native english speakers, the document > quality is not as satisfying as it can be, please help! > > Judging from this message, your English seems pretty good actually :-) > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0