Re: [Haskell-cafe] using network+conduit+tls for a client application?
On 07/29/2013 09:08 AM, Petr Pudlák wrote: Dear Haskellers, I wanted to write a small TLS application (connecting to IMAP over TLS) and it seemed natural to use conduit for that. I found the network-conduit-tls package, but then I realized it's meant only for server applications. Is there something similar for client applications? Hi Petr, There's 2 packages that provide easy client TLS side API. I don't think it would be difficult to provide a conduit wrapper for both: http://hackage.haskell.org/package/network-simple-tls http://hackage.haskell.org/package/connection connection is a bit more low level for easily integration into something higher level. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using network+conduit+tls for a client application?
On 07/29/2013 10:43 AM, Michael Snoyman wrote: I've actually been intending to add the client side code to that package, but I simply haven't gotten around to it yet. It's actually not that complicated, but it does require some thought on the right interface for things like approving/rejecting server side certificates. If you open up an issue on Github for this, I'd be happy to continue the conversation there and we can try to get out a new version of the library. (I just don't want to spam the Cafe with an exploratory design discussion.) Michael, I've been meaning to add TOFU (Trust on first use) and certificate exceptions support (e.g. self signed) inside the TLS stack directly, maybe we should talk about this. Few design stuff that blocked me so far, one of them is how to store those things. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
On Mon, Feb 25, 2013 at 01:30:40PM +0100, Nicolas Trangez wrote:
All,
In order to implement some network protocol clients recently, I needed
binary serialization of commands and deserialization of responses
('Command - ByteString' and 'ByteString - Response' functions,
preferably for both strict as well as lazy ByteStrings).
My go-to packages have always been 'binary' and 'cereal', but I was
wondering about the current (and future) state/goals:
- cereal supports chunk-based 'partial' parsing (runGetPartial). It
looks like support for this is introduced in recent versions of 'binary'
as well (runGetIncremental)
- cereal can output a strict bytestring (runPut) or a lazy one
(runPutLazy), whilst binary only outputs lazy ones (runPut)
- Next to binary and cereal, there's bytestring's Builder interface for
serialization, and Simon Meier's blaze-binary prototype
There are some blog posts and comments out there about merging cereal
and binary, is this what's the goal/going on (cfr runGetIncremental)?
In my use-case I think using Builder instead of binary/cereal's PutM
monad shouldn't be a major problem. Is this advisable performance-wise?
Overall: what's the advised future-proof strategy of handling binary
(de)serialization?
I've been looking at the same thing lately, and i've been quite surprised, to
say the least, by the usual go-to packages (cereal, binary). Performance wise
this is hard to summarize, but if you serialize something small and have a easy
to compute size (e.g. fixed size structure), i would advise against using any
kind of builder structure (builder,cereal,binary), and go directly at the
Storable level, if performance need to be on-par other languages.
My initial interpretation is that the builder initial cost is quite high, and
only get amortized if the number of operations is quite high (and have less
bytestrings). So if you have many structures encoded in one encoding operation
it's probably ok-ish.
I've made the following benchmark when i was doing my experiments,
that shows basic serialization of bytestring-y data structures:
* bclass is a simple function that use bytestring concat or append
* bclass+io is a simple function that use mutable bytestring + poke to create
the bytestring
* cereal is cereal's encode function
* binary is binary's encode function
* builder is bytestring's builder.
* simple bytestring of constant size: sz
* n bytestrings of same size: n*sz
* n bytestrings of different size: sz+sz2+..
* n bytestrings plus a w32 prefixed size: len+n*sz
Obviously, caveat emptor:
http://tab.snarc.org/others/benchmark-bytestring-serialization.html
Let me know if anyone want the source file.
--
Vincent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
On Mon, Feb 25, 2013 at 11:59:42AM -0800, Johan Tibell wrote: - cereal can output a strict bytestring (runPut) or a lazy one (runPutLazy), whilst binary only outputs lazy ones (runPut) The lazy one is more general and you can use toStrict (from bytestring) to get a strict ByteString from a lazy one, without loss of performance. Two major problems of lazy bytestrings is that: * you can't pass it to a C bindings easily. * doing IO with it without rewriting the chunks, can sometimes (depending how the lazy bytestring has been produced) result in a serious degradation of performance calling syscalls on arbitrary and small chunks (e.g. socket's 'send'). Personally, i also like the (obvious) stricter behavior of strict bytestring. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need urgent help with Network.tls
On 02/23/2013 06:58 PM, C K Kashyap wrote: The reason I want to use TLS is that I'd want to pack the whole thing in a DLL and give it off to a friend for use. What I am really looking for is a small sample code that demonstrates how TLS package can be used to connect to a webserver or imapserver. Regards, Kashyap Kashyap, I suggest you look at the connection package [1] which is made for this specific purpose, and comes with examples on how to use it [2]. If you want to only use tls, i suggest to look at connection's code [3], or the tls-debug [4] package, which got many small utils that use tls. [1] http://hackage.haskell.org/package/connection [2] https://github.com/vincenthz/hs-connectionhttps://github.com/vincenthz/hs-connection/tree/master/examples [3] https://github.com/vincenthz/hs-connection/blob/master/Network/Connection.hs [4] https://github.com/vincenthz/hs-tls/tree/master/debug/src -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need urgent help with Network.tls
On 02/23/2013 09:05 PM, Brandon Allbery wrote: On Sat, Feb 23, 2013 at 1:58 PM, C K Kashyap ckkash...@gmail.com wrote: What I am really looking for is a small sample code that demonstrates how TLS package can be used to connect to a webserver or imapserver. TLS isn't actually SSL, despite SSL getting blessed as TLS 0.9. Various attempts at TLS-enabled web protocols have foundered, so you won't find much code to speak TLS to web servers. (SSL is negotiated at socket connect time and involves no protocol commands.) In short, sample code that can do https would be completely useless for comparing to TLS-enabled code. SSL and TLS can be negociated at socket connect. TLS is just the standard name of SSL. at the wire level, TLS1.x is SSL 3.(1+x). What you're refering to is the STARTTLS style protocol command which work independently of the version of TLS (include SSL2, SSL3). Many programs have abused SSL and TLS different name to differentiate how TLS is negociated (straight away, or with a protocol command). Fortunately more and more programs do the right thing and differentiate the two types with the following two options: SSL/TLS or STARTTLS. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need urgent help with Network.tls
On 02/23/2013 03:28 PM, C K Kashyap wrote: Hi, I am trying to use Haskell to download email/attachments from gmail. For which I am exploring Network.TLS. I got this sample from the net that connects to gmail smtp and works just fine - http://hpaste.org/82890 Your example look odd, Typically you would either: * connect directly using tls (usually using the standard secure service port) * or connect to the normal service port, do a basic handshake with the server, tell that you're going to switch the connection with STARTTLS, and use tls. but you will not use both methods in the same connection. Hope that helps, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tls talking to certificate stores (was Re: ...)
On 02/16/2013 12:51 AM, Andrew Cowie wrote:
Windows certificate and macos X certificate are stored in a reliably
discoverable place. That openssl provide no way to get to it is a
different story and one reason to have tls.
Is talking to the Windows and Mac OS certificate stores something that
you wrote for the tls library [in Haskell]? If so, is it something that
could be ported for other people to use?
It's not much but it's available in the certificate package.
https://github.com/vincenthz/hs-certificate/tree/master/System/Certificate/X509
The mac os certificates are trivially available throught the security
executable, but there's also documentation on the keychain format
readily available.
The windows certificate implementation is not finished. The certificate
are easy to find, however the format is slightly complicated (basically
a dump of C like structure with ASN1 marshalled data in the dump). The
windows certificate is sadly not finished, as no windows user of tls (if
any) is {interested-in/know-how-to} implementing it, and as I boot
windows once every moon ... if someone want to sponsor the feature, come
talk to me ;)
That remind me that i've got pending patches to win32 to send ..
--
Vincent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ifdef based on which OS you're on
On 02/15/2013 02:05 PM, Andrew Cowie wrote: all very nice (this being necessary because apparently the non-free operating systems don't store their certs in a reliably discoverable place; bummer). Sorry the answer is out of topic, but this is not true. Windows certificate and macos X certificate are stored in a reliably discoverable place. That openssl provide no way to get to it is a different story and one reason to have tls. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Fri, Feb 01, 2013 at 01:07:33PM +0100, Christopher Done wrote: Hey dude, it looks like we made the same project yesterday: http://www.reddit.com/r/haskell/comments/17njda/proposal_a_trivial_cabal_package_signing_utility/ Yours is nice as it doesn't depend on GPG. Although that could be a nice thing because GPG manages keys. Dunno. Another diff is that mine puts the .sig inside the .tar.gz, yours puts it separate. Nice to see a productive discussion on this. /me really need to read reddit more :) Couple of details, no the signature is going inside the tarball too. the signature process happens during the sdisting after building the manifest. My reason for doing is, which i suspect similar to yours, is that I don't need to modify hackage this way and the uploading stays the same. Also in my case, cabal-signature is called by cabal, not by the user. I can't see this effort working without forcing everyone to use it (transparently in the background) For gpg, i don't know what's the right answer. One on hand it's solving all the problems related to this already, but on the other portability issue. I was thinking maybe one way to verify the key that i use for signing, would be to tie it to a personal gpg key (by signing the key with a gpg key) to benefit from all the facilities that gpg provides. It would provide a cheap way to switch model later, without being tied to a gpg signing process. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/30/2013 07:27 PM, Edward Z. Yang wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. I agree this is terrible, I've started working on this, but this is quite a bit of work and other priorities always pop up. https://github.com/vincenthz/cabal https://github.com/vincenthz/cabal-signature My current implementation generate a manifest during sdist'ing in cabal, and have cabal-signature called by cabal on the manifest to create a manifest.sign. The main issue i'm facing is how to create a Web of Trust for doing all the public verification bits. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/30/2013 10:48 PM, Niklas Hambüchen wrote: You are right, I skipped over that this was actually a server-side exploit - sure, end-to-end signing will help here. it helps also in the HTTP case; a MiTM wouldn't be able to change the package without knowing the private key. more to the point it also help the case with hackage mirrors (or a corrupt hackage admin). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/package/openpgp http://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 08:16 AM, Ketil Malde wrote: *MY* proposal is that: 0. Hackage sends an email to the previous uploader whenever a new version of a package is uploaded by somebody else. At least that way, I would be notified if it happened to my packages, and I would be able to check up on the situation, and rectify it. you wouldn't in real cases, it just fix the most obvious and simple attack vector. but consider: * someone intercepting your upload http stream, and replacing dynamically your package. * someone gaining malicious access to hackage and planting stuff inside packages. * a rogue hackage admin. * a rogue hackage mirror admin. it's obviously less easy than just creating an account and uploading things on top of other packages, but i don't think we should feel safe if the previous maintainer received an email about the change. For example, previous maintainer might be away from email for a long time potentially leaving a trojan version for days/weeks, or changed email address.. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote: Joachim Breitner m...@joachim-breitner.de wrote: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Let's do it properly. but don’t overengineer it either. Simply adding to hackage the possibility to store a .asc file next to the tar.gz file that contains the cryptographic signature would be a great start, and allow us to develop a WoT model later on. (I try to resist from wondering whether this could go into hackage1 or only hackage2, and in the latter case, whether that means that we actually have the time to overengineer the system.) In fact, a lot would already be gained by a simple „warn if foo-2.0 is signed with a different key than the version of foo already installed“ on cabal-install and people having a closer look at uploads from different people. Not much infrastructure needed there. That was exactly my suggestion actually. It requires the ability to make and check signatures. The making can be done with external tools like GnuPG, but the checking has to be done by cabal-install. To detect changed keys there also needs to be a trust database, which can be a simple directory in ~/.cabal/ where files are named after the fingerprint of the key it contains. The most important part is a sensible user interface. The whole process should be invisible to the user, until there is a signature error. The first installation of a package will actually generate a handful of signature errors, because the keys are not known yet. This shouldn't be too hard to implement and requires only a small change to Hackage and cabal-install's upload command to begin. That's not a proper solution, and definitively in the warm fuzzy feeling department. What if you install a package for the first time and this package has just been re-uploaded maliciously with a different key and a payload ? What if you're relying on hackage mirrors, what stop this mirror to regenerate all signatures with a new key ? It also make maintainers change difficult, and doing genuine non-maintainer upload. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote: On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/**package/openpgphttp://hackage.haskell.org/package/openpgp http://hackage.haskell.org/**package/hOpenPGPhttp://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) In this case I think this is the wrong approach. There must be at least one way to work within a trust model that is not fragile. Whether this is fully supported on all platforms is actually not very important. I have pointed out why simply signing packages is fragile and how git is better suited for this task. We are not going to reimplement all the good infrastructure that already exists (gpg, git), so making that a requirement is not a good idea IMO. Basic verification of signatures should work on Windows, I agree. But the underlying WoT should be a little bit more sophisticated. This means it has to be based on standard tools, or it will never happen. I think you misunderstood me. Having a fully working pgp package, means you have full control of the pgp stack, you don't rely on hard-to-get out tools, and it can be integrated with cabal directly for a full WoT experience. Also git doesn't solve the hackage problem, there's not necessarily a one-to-one mapping between packages and their repositories. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestiong for inter-thread communication
On Sat, Jan 26, 2013 at 07:46:04AM -0200, Thiago Negri wrote: Do you need advice on what? I didn't understand your last phrase. IIUC, it has to do which how to interrupt a blocking call to ncurses event handling, from another thread (the calculation thread) to let the UI thread refresh the UI with something to display (the calculation). I've been confronted with the same problem in the past, and i haven't found a satisfactory solution with ncurses. Erik, I think the only way to do that with ncurses, is to wrap the ncurses getevent with a select loop on the terminal fd and an arbitrary fd to be able to ping the select loop for arbitrary processing. You can also replace the arbitrary fd with a SIGALARM to yourself which i believe would interrupt select too. I don't think there's any solution that integrate nicely with the haskell way, but i'ld be happy to be wrong on this. In my case, i switched to Vty which solved this problem, by allowing to send arbitrary strongly-typed event to widgets. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.
On Sun, Jan 20, 2013 at 08:27:07PM +0100, Alexander Kjeldaas wrote: Regarding testing, it looks like the Tests directory hasn't been updated to cover this bug. What would really give confidence is a set of tests encoding fixed security vulnerabilities in OpenSSL (and similar libraries). That should also give you a lot of confidence in your library. But anyways, this is fantastic work you're doing. Keep it up! Thanks, Regarding tests, a good test suite is a hard and long job. Some security properties are just insanely hard to codify, and some others need a lots of tests. My time being very limited, it's hard to pull off, but i have plan to add some tests for the certificate validation functions. Specially since i want to harden some functions a bit more, and it will come handy to verify i'm not breaking anything :-) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.
On Sun, Jan 20, 2013 at 11:01:22AM +0100, Joachim Breitner wrote: Debian ships tls-extras 0.4.6 in what will become wheezy, and due to the freeze upgrading to a new major upstream release is not acceptable. Would it be possible for you to create a 0.4.6.1 with this bugfix included? (wow, the tls packages stack are quite obsolete) Apart from the fact that it took me a while to rebase to this version, I just uploaded 0.4.6.1. it compiles but got minimal testing. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANN] tls-extra 0.6.1 - security update, please upgrade.
Hi cafe, this is a security advisory for tls-extra 0.6.1 which are all vulnerable to bad certificate validation. Some part of the certificate validation procedure were missing (relying on the work-in-progress x509 v3 extensions), and because of this anyone with a correct end-entity certificate can issue certificate for any arbitrary domain, i.e. acting as a CA. This problem has been fixed in tls-extra 0.6.1, and I advise everyone to upgrade as soon as possible. Despite a very serious flaw in the certificate validation, I'm happy that the code is seeing some audits, and would want to thanks Ertugrul Söylemez for the findings [1]. [1] https://github.com/vincenthz/hs-tls/issues/29 -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
On Tue, Jan 15, 2013 at 03:27:29PM +0100, Ertugrul Söylemez wrote: Vincent Hanquez t...@snarc.org wrote: Yes, the performance are terrible in term of integers. As the library is specific to public key algorithm, i just can't reasonable work on 64 bits integer :-), and multiprecision integers is the only way to go. I'm on-and-off working on some mutable mpi library to be able to define pure function that do the necessary stuff (i.e. expmod, mulmod, etc..) I'm hoping this could be reasonably competitive with a C mpi library, but time will tell. It's a waste of time. In my benchmarks Haskell Integer outperformed equivalent (sane) C implementations using GMP's mpz_* interface. You would be reinventing GMP's mpn_* interface and a custom memory manager to be able to match the speed of Integer. I don't plan to match (or outperform) the speed of integer for simple operations. My experiment is about overtaking haskell's Integer in composite operations (mainly for non naive expmod) by operating with mutable integers and direct access to the representation (the second point is somewhat what Daniel is doing using integer-gmp). One valid way to solve this problem, would be to export more GMP function to haskell without wrapping them for referencial transparency. However the GMP dependencies is not always welcome and the integration of GMP is slightly special (primops), which is why i'm not taking this course of action. The things that were slower than equivalent C code were not related to Integer, but mostly to data structures like Set in my case, which was the motivation for me to write the 'quickset' library. AFAIK, Haskell's Integer expmod algorithms have no way to rival with real world implementation of expmod, which make all pubkey operations quite slow compare to their C friends. There's also the question of timing security with a pure GCed interface. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
On Mon, Jan 14, 2013 at 01:49:44PM +0100, Daniel Fischer wrote: On Monday 14 January 2013, 12:36:22, Vincent Hanquez wrote: On Sat, Jan 12, 2013 at 02:12:44PM +0100, Ertugrul Söylemez wrote: I've spend some good chunk of time adding KATs and tests, documentation, and making sure the performance was ahead of other haskell implementations. I suggest looking at Daniel Fischer's arithmoi [1] library, which implements very fast Integer operations and should provide most functionality needed. However, beware of timing attacks. Very cool library and very similar to what crypto-numbers provides albeit less sophisticated. I see you're doing a lot of x `shiftR` 1 with Integers. That's pretty bad for performance (at least for integer-gmp, might be not for integer-simple or implementations other than GHC [last I looked, JHC didn't have arbitrary precision Integers and used 64-bit ones, so it'd be fast there]). Yes, the performance are terrible in term of integers. As the library is specific to public key algorithm, i just can't reasonable work on 64 bits integer :-), and multiprecision integers is the only way to go. I'm on-and-off working on some mutable mpi library to be able to define pure function that do the necessary stuff (i.e. expmod, mulmod, etc..) I'm hoping this could be reasonably competitive with a C mpi library, but time will tell. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
On Sat, Jan 12, 2013 at 02:12:44PM +0100, Ertugrul Söylemez wrote: I've spend some good chunk of time adding KATs and tests, documentation, and making sure the performance was ahead of other haskell implementations. I suggest looking at Daniel Fischer's arithmoi [1] library, which implements very fast Integer operations and should provide most functionality needed. However, beware of timing attacks. Very cool library and very similar to what crypto-numbers provides albeit less sophisticated. I wished I knew about it before implementing the same(ish) functions. One caveat of the library is the dependence on integer-gmp. Also for the particular purpose of generating safe primes I have written a blazingly fast implementation that uses intelligent sieving and finds even large primes (= 4096 bits) within seconds or minutes. It's on hpaste [2]. I might turn this into a library at some point. Seconds or minutes ? that's very different :-) But in any case, it would be a nice addition i think. My safe prime generation function is probably the most naive possible. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
Hi Cafe, I've recently released crypto-pubkey [1][2], which provide a comprehensive solution for public key cryptography. Most known RSA modes (PKCS15, OAEP, PSS) are supported, and there's also DSA and ElGamal signature support. Most of the code originally lived in cryptocipher, but have now been made better and safer, and support more modes. I've spend some good chunk of time adding KATs and tests, documentation, and making sure the performance was ahead of other haskell implementations. Enjoy, [1] http://hackage.haskell.org/package/crypto-pubkey-0.1.1 [2] https://github.com/vincenthz/hs-crypto-pubkey -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: crypto-pubkey: all your public key crypto algorithms belong to us.
On 01/11/2013 11:34 PM, Joachim Breitner wrote: nice. But in the interest of possible users: Is there a reason why this code could not live in cryptocipher? Do we need multiple implementations of the cyphers, and expect our users to find out for themselves why to use one or the other? The duplicate implementations in cryptocipher have been marked as deprecated and will be removed in a near future. The only reason is has been spun off is that i think it was a mistake to put it along block and stream cipher in the first place, and i prefer smaller package with dedicated dependencies. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
On 12/13/2012 12:51 PM, Michael Snoyman wrote: I think that's a great idea. I just implemented this on PackDeps: http://packdeps.haskellers.com/licenses As with all features on that site, I'll be happy to deprecate it as soon as Hackage incorporates the feature in the future. awesome Michael ! However i think ithis shouldn't take dependencies from tests and benchmarks. This doesn't make differences for the overall license that the library exposes. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can I avoid buffered reads?
On 11/28/2012 09:31 PM, Leon Smith wrote: Quite possibly, entropy does seem to be a pretty lightweight dependency... Though doesn't recent kernels use rdrand to seed /dev/urandom if it's available? So /dev/urandom is the most portable source of random numbers on unix systems, though rdrand does have the advantage of avoiding system calls, so it certainly would be preferable, especially if you need large numbers of random numbers. There's no much information on this i think, but if you need large number of random numbers you should build a PRNG yourself on top of the best random seed you can get, and make sure you reseed your prng casually with more entropy bytes. Also if you don't have enough initial entropy, you should block. /dev/urandom is not the same thing on every unix system. leading to various assumptions broken when varying the unixes. It also varies with the hardware context: for example on an embedded or some virtualized platform, giving you really terrible entropy. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: language-java 0.2.0
Hi Cafe, with the approval of Niklas, the original author and maintainer, i'll be maintaining language-java for now. I've uploaded a new version on hackage [1] with some minor improvements and the repository is now hosted on github [2]. Thanks Niklas for language-java ! [1] http://hackage.haskell.org/package/language-java [2] http://github.com/vincenthz/language-java/ -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: language-java 0.2.0
On 11/27/2012 06:46 PM, Alfredo Di Napoli wrote: Thanks for the effort! Now, what about some documentation? :P Sure ! Fork away, and send pull requests :-) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class Bytestringable or ToBytestring
On 11/23/2012 08:19 AM, Silvio Frischknecht wrote: i recently found the convertible package Thanks. quite a cool package, I'll probably use it in the future for some of my programs. Not sure that's appropriate for my cases unfortunately. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] class Bytestringable or ToBytestring
Hi cafe, I've been adding lots of types recently that looks more or less like: newtype A = A ByteString data B = B ByteString This is great for extra type safety and letting the compiler do its job, however getting the bytestring back requires boiler plate. At the moment either you give access to the constructor, which is not always wanted, or you use the record syntax to create a function to extract just the bytestring. The latter is fine for 1 or 2 types, but the scheme fall apart when having many of those types and do pollute namespace. I'm basically after something that looks like this: class ToByteString a where toByteString :: a - ByteString Before anyone suggest the Serialize interface from cereal or the Binary interface from binary which both looks quite similar (from far away): - serialize work in the put monad, and you have to define a get instance: which is something that is not required or possible sometime. - binary works with lazy bytestrings and got the same problem as cereal. - a serialize instance that just do a single putByteString is really slow: 12 ns to 329 ns (26x time slower) on the same exact data on one isolated bench) - neither of those packages are in the platform. If that doesn't exists, could it be a worthy addition to bytestring ? is this a good idea in general ? is there any other way ? Thanks, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class Bytestringable or ToBytestring
On 11/22/2012 03:42 PM, kudah wrote: Why not use http://hackage.haskell.org/packages/archive/newtype/0.2/doc/html/Control-Newtype.html instead? interesting i didn't know about it, however it's seems relatively unknown (can't find any library on hackage that use it) and just like Serialize and Binary the interface goes both way, where i'm looking only at the unpack method. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to determine correct dependency versions for a library?
On 11/14/2012 09:53 AM, Ivan Lazar Miljenovic wrote: % cabal install virthualenv Resolving dependencies... cabal: Could not resolve dependencies: trying: virthualenv-0.2.1 rejecting: base-3.0.3.2, 3.0.3.1 (global constraint requires installed instance) rejecting: base-4.6.0.0/installed-eac... (conflict: virthualenv = base=4.2.0.0 4.6) rejecting: base-4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (global constraint requires installed instance) Doesn't this prevent the error of this package won't build (even if the error message doesn't precisely say that)? In most cases, it replaces the uncertainty of a build error with an unconditional pre-build error. instead of having either a package built or a meaningful build error, i now have no package with the information that it might or might not cause an error to continue. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serializing with alignment
On 11/06/2012 09:33 PM, Ben Franksen wrote: Hi Everyone I want to implement a binary protocol that, unfortunately, has some alignment restrictions. [snip] Cheers Hi Ben, I don't think such thing currently exists. Not sure that's any help to you (and definitely not answering your binary question), but I rolled my own 'put' for a dbus implementation: https://github.com/vincenthz/hs-udbus/blob/master/Network/DBus/Wire.hs (it's quite simple, and could do with a builder and some tweaks) -- Vincent @vincenthz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANNOUNCE: connection
Hi Haskellers,
I'm pleased to announce the release of connection. Connection is the pinnacle of
most of my network related packages, and wrap together all the libraries needed
to provide a easy and smooth experience to open client connection.
It provides very simple access to SOCKS and TLS along with normal raw client
socket.
The goal is to hide most complicated settings either completely or re-expose
them more simply, and provide safe defaults.
repository: https://github.com/vincenthz/hs-connection
hackage: http://hackage.haskell.org/package/connection
Two simple examples (more can be find in the README on github):
- opening a raw connection to www.example.com port 80:
ctx - initConnectionContext
connectTo ctx $ ConnectionParams
{ connectionHostname = www.example.com
, connectionPort = fromIntegral 80
, connectionUseSecure = Nothing
, connectionUseSocks = Nothing
}
- opening a TLS connection to www.example.com port 443:
ctx - initConnectionContext
connectTo ctx $ ConnectionParams
{ connectionHostname = www.example.com
, connectionPort = fromIntegral 443
, connectionUseSecure = Just def
, connectionUseSocks = Nothing
}
Enjoy, do reports bug and suggestions the usual way (on github issue tracker or
by email)
--
Vincent @vincenthz
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] haskell cryptogaphic libraries
On 08/24/2012 04:20 PM, marcmo wrote: You have done quite some work on the crypto front...cool! since you are the owner of cryptocipher and your new package cipher-aes: is cryptocipher now deprecated? cryptocipher itself is not deprecated as it contains much more than just AES. The haskell AES will probably going to be replaced by a stub layer to call into cipher-aes, and i'm also mulling splitting the package into many per-feature packages with cryptocipher binding them together, but it should affect any users. the certificate library fits my needs perfectly! snip so let's just hope you stick around for some time Vince, my code now fully depends on you ;) Well i have no plan to go anywhere and want to bring the tls stack to completion; although it's only on my free time for now.. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell cryptogaphic libraries
On 08/24/2012 01:47 PM, marcmo wrote: In my day job I currently need to deal with a lot of cryptographic processing. For the tests I need to perform various cryptographic functions in haskell. these include: * AES Encryption/Decryption (CBC-Mode) * RSA Public Key Encryption/Decryption * Certificate Handling I'm having some difficulties finding the libraries to use and using them correctly. Performance is /not/ my primary concern...rather *correctness* and*ease of use*. Haskell has some great cryptographic libs but for me it seems hard to judge what to use. The ones that seem appropriate are: * The AES package (for symmetric encryption) * The RSA package (for public key cryptography) certificate handling is s.th. I haven't found out about * how to deal with Certificates (e.g. extract the public key from X.509 certificates) is there a recommended package (packages) that suite my purpose? Hi, [this is going to a be shameless self advertising reply :) ...] for AES, i'ld recommend you to read a recent post of mine building a better haskell aes [1]. for RSA, to have something compatible my next suggestion for x509, you got either RSA or cryptocipher [2]. for X509, everything you need is available in the certificate package [3] While you mentioned performance is not your primary concern, I found that even with medium use of crypto it becomes a significant bottleneck when using some well established implementations. [1] http://tab.snarc.org/posts/haskell/2012-07-07-building-a-better-haskell-aes.html [2] http://hackage.haskell.org/package/cryptocipher [3] http://hackage.haskell.org/package/certificate -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS 0.9.6, question about session resumption.
On 07/21/2012 05:12 PM, C Gosch wrote: Hi Cafe, and then the server says (AlertLevel_Fatal,UnexpectedMessage) I'm not sure whether the ServerHelloDone should happen when resuming. Does anyone have a hint what may be going wrong? I am using TLS10 and the tls package with version 0.9.6. Hi Christian, Domique is right, a sucessful session resumption should have a Finished message after ServerHello. It's not really clear what's your setup (are you trying to use TLS on server/client/both ?), and without some code, it's hard to debug your problem. The only thing that come to my mind is, did you setup your session callbacks correctly ? -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS 0.9.6, question about session resumption.
On 07/23/2012 06:54 PM, . wrote: I just modified TLS locally on my system to export SessionID and SessionData, and set the session callbacks to storing/retrieving the session data from a Map. After that, the resumption appears to work :-D Thanks a lot for that hint! Is that the way it's meant to be? If yes, how do I get the data types the official way? Cool. this is indeed an omission, it should have been exported. I realized and fixed it couple of weeks ago in the next branch (upcoming tls 1.0) when doing cleanup around session management, but forgot to check master (tls-0.9.x). I've fixed it now, and pushed tls-0.9.8. Thanks, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 01:35 AM, Thomas DuBuisson wrote: Vincent has done great work for Haskell+Crypto so I think he knows I mean nothing personal when I say cprng-aes has the right idea done the wrong way. Why a new effort vs Vincent's package? 1. cprng-aes is painfully slow. when using the haskell AES implementation yes. with AESNI it fly, and even more when i'll have time to chunk the generation to bigger blocks (says 128 AES block at a time) 2. It doesn't use NI instructions (or any C implementation, currently). The NI instructions support are coming. and there's ton of already existing C implementation that could just be added. 3. It isn't backtracking resistent. I plan to follow the SP and test against the KATs. I'm not sure i understand this. what's backtracking resistent ? -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 04:56 AM, Thomas DuBuisson wrote: On May 3, 2012 5:49 PM, Ertugrul Söylemez e...@ertes.de mailto:e...@ertes.de wrote: Thomas DuBuisson thomas.dubuis...@gmail.com mailto:thomas.dubuis...@gmail.com wrote: I can't really tell whether the first two points are true. Feel free to investigate it yourself, I've convinced myself. Vincent has added NI work to cryptocipher recently, but it still needs some corners smoothed. I've contacted him about some of those already. In the end I might use his C/ASM code for this task, but it is still lacking the ability to check for the NI instruction. My end goal is to have the user use transparently the fastest implementation available to their architecture/cpu providing they use the high level module. I've uploaded the cpu package which allows me to detect at runtime the aes instruction (and the architecture), but i've been distracted in implementing fast galois field arithmetics for GCM and XTS mode (with AES). So any contributions going in this direction is more than welcome. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 02:37 PM, Ryan Newton wrote: My end goal is to have the user use transparently the fastest implementation available to their architecture/cpu providing they use the high level module. I've uploaded the cpu package which allows me to detect at runtime the aes instruction (and the architecture), but i've been distracted in implementing fast galois field arithmetics for GCM and XTS mode (with AES). Yes! A worthy goal! I think the proposal here is that we do the build/integration work to get something good which is portable enough and install-reliable enough to replace 'random'. Then people who don't care will be using a good implementation by default. That was my goal when I had my own small shot at this, but what I came up with was *very* build-fragile. (Depended on assembler being available, or on prebuilt binaries being included for that package.) You can see the Setup.hs customization I attempted to do in intel-aes to compensate, but it's not enough. Can we write a cabal-compatible, really robust installer that will test the users system and always fall back rather than failing? That was my original plan, until i find out that it's not really possible. For the language, i think assembly is a no-no with cabal, as such it need to be embedded in gcc inline assembly if you want to have something that works (unless there's a secret way to run assembler in a portable fashion in cabal). Which is the reason behind why i settled on intrinsics, as i didn't have to do the assembly directly. It appears more portable as well as every major compiler seems to support it (with difference of course, it would too simple otherwise (!)) P.S. How are you doing the CPUID test for NI instructions? I used the *intel provided* test for this (in intel-aes) but I still had reports of incorrect identification on certain AMD CPUs... I haven't done it yet, but it should be just a matter of this piece of code for Intel and AMD: import System.Cpuid import Data.Bits supportAESNI :: IO Bool supportAESNI = cpuid 1 = \(_,_,ecx,_) - ecx `testBit` 25 -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 02:33 PM, Ryan Newton wrote: 1. cprng-aes is painfully slow. when using the haskell AES implementation yes. with AESNI it fly, and even more when i'll have time to chunk the generation to bigger blocks (says 128 AES block at a time) One data-point -- in intel-aes I needed to do bigger blocks to get decent performance. Yes, it's a slightly random value here, although it's a tradeoff with memory usage and performance, 128 blocks would do quite well compared to any haskell implementation that goes 1 block at a time [1] [1] because you'll have to drop in/out of C, and reload the SSE registers each time. 2. It doesn't use NI instructions (or any C implementation, currently). The NI instructions support are coming. and there's ton of already existing C implementation that could just be added. Oh, neat. Could you share a pointer to some C code (with GCC aes intrinsics?) that can replace what the ASM does in the intel-aes package? Just have a look in cryptocipher with cbits/aes/x86ni.c -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 03:05 PM, Thomas DuBuisson wrote: Vincent uses gcc header files to get the AES instructions: Header files of: #includewmmintrin.h #includetmmintrin.h And later calls of: x = _mm_aesenc_si128(m, K1); But currently you must know you have AESNI and use a flag: cabal install cryptocipher -faesni But if you are wrong: Illegal instruction (core dumped) Of course that's expected as of now, since it's not finished and i had to push a new release (related to some significant performance improvement for RSA/DH/DSA), the code is there as a technology preview. But the goal is to turn unconditionally the AESNI flag when arch is x86 or x86_64, which in this case the implementation would rely on the runtime cpuid check to use the aesni fastpath or not. This is a great place to be - now we just take the CPU checking from intel-aes, make a switch between Vincent's C and Gladman (in haskell or out, I doesn't matter to me), graft on Ctr mode as specified then it's all about matching the current 'random' API. Please don't take the intel-aes test implementation. it's skewed to just support Intel, since it basically testing for the cpu string GenuineIntel. The only necessary test is the cpuid 1 with ecx having the 25th bit set. It should just work providing cpus other than intel have matching cpuid 1 layout (which as far i'm concerned seems to be the case in most cases) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annoyed at System.Random
On 05/04/2012 03:18 PM, Brandon Allbery wrote: On Fri, May 4, 2012 at 10:11 AM, Vincent Hanquez t...@snarc.org mailto:t...@snarc.org wrote: For the language, i think assembly is a no-no with cabal, as such it need to be embedded in gcc inline assembly if you want to have something that works (unless there's a secret way to run assembler in a portable fashion in cabal). I don't know if cabal knows this, but assembler files with .s (and maybe .asm on Windows?) extension are recognized by most C compilers and handed off to the assembler; as such, simply augmenting cabal's C rules with those extensions should be sufficient. That might works, although you might end up with some corner case portability issues. Wrapping them in C should be more practical and you could write something like this for maximum portability (compiler,systems,..): #if system_that_works_with_inline_asm asm inline(instr1; instr2;, ); #else /* fallback to C */ #endif -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] JSON library suggestions?
On 04/24/2012 09:46 PM, Jeff Shaw wrote: Hello, Up until now I've been using Aeson, but I've found that its number type isn't going to work for me. I need to use decimal numbers while avoiding conversions from and to Double, which Aeson doesn't allow. There are quite a few more JSON libraries for Haskell, which all appear to use Rational for numbers, so I'm wondering if anyone can recommend one. Hi, Not sure that's helpful to you since it's a C binding solution, but i haven't found anything that i could use related to JSON in Haskell since i wanted: - event based parsing. - DoS protection. - integer and float represented as array of bytes. - and last but not least break neck speed. so i ended up binding my own C embedded library [1]. I could clean up my ugly bindings and publish it somewhere if it's useful. I do have a plan, someday, to experiment with a rewrite in haskell using the exact same technique but the will and time to do so have lacked so far. [1] https://github.com/vincenthz/libjson -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS support for haskell-xmpp
On 04/17/2012 04:05 AM, John Goerzen wrote: Dmitry others, Attached is a diff implementing TLS support for haskell-xmpp, and correcting a build failure. The support is rough but it seems to work so far. It's a bid sad but gnutls is GPL-3 and haskell-xmpp BSD3, rendering the combination BSDless. May i suggest in a shameless self advertising, the haskell tls library :-) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can cabal detect property of the platform ?
Hi Cafe, Is there a way to have (some) cabal flags to autoconfigure themselves ? For example, a SSE flag, i want the configure to default to on when the building machine has SSE instruction available, and default to off otherwise. (of course, it wouldn't affect the user ability to override the default with -f) It doesn't appears possible just using the cabal file. Is there a way with the Setup.hs maybe ? or some other cunning plan ? -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prettier pretty-printing of data types?
On 03/13/2012 10:33 PM, Johan Tibell wrote: value = Bin 1 (Bin 2 Leaf Leaf) (Bin 3 Leaf Leaf) I'm usually using the following snippet which is a tweak of the gshow function from syb. However everything need to be a member of Data/Typeable, and also list are not particularly well handled with this. gshowHier :: Data a = Int - a - String gshowHier il a = intercalate \n (constr : gmapQ (gshowHier (il+2)) a) where constr = replicate il ' ' ++ (showConstr $ toConstr a) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vim plugin for ghc-mod
On 02/16/2012 08:21 PM, Magnus Therning wrote: On Thu, Feb 16, 2012 at 09:51, Kazu Yamamotok...@iij.ad.jp wrote: Hello, eagletmt implemented a Vim plugin for ghc-mod: https://github.com/eagletmt/ghcmod-vim Happy Haskell programming on Vim! Thank you for pointing this out on the list. My Vim setup has now improved by a few 100%, thanks to ghcmod-vim, neco-ghc and syntastic. wow. indeed, thanks for the pointer ! -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient temporary file storage??
On 01/24/2012 07:33 AM, Gregory Crosswhite wrote: On 1/24/12 9:43 AM, Felipe Almeida Lessa wrote: Use cereal [1], usually it's fast and easy enough. Out of curiosity, is binary no longer the recommended standard for such things? binary got only an interface for processing lazy bytestring. cereal is able to do strict and lazy bytestring and got a partial interface like attoparsec (which is required to do proper network/io processing). Fortunately it's very simple to convert between the two, since the actual serialization API is really close. Features-wise, in my view, cereal is a superset of binary. the only thing missing that i've noticed is that you can't tell how many bytes you have processed with cereal. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On 01/19/2012 08:14 AM, Gregory Collins wrote:
Speaking of the migration issue; it should be possible to have an
enumerator - conduit wrapper library to help people continue to use
their enumerator-based code for awhile (and vice-versa).
A bit out of topic and definitely not answering the question, but for asn1-data,
i want to move away from the data feeding business, and just relying on the
attoparsec API.
That let the user choose the feeding style by plugin either an existing
attoparsec
plugin package (attoparsec-{conduit,enumerator,iteratee}) or dealing with the
Result
type directly.
This is also possible when using cereal (Data.Serialize).
I think more libraries in the enumerator camp or iteratee camp should look if
they need
to control input or not. unless there's something i missed :-)
--
Vincent @vincenthz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit versions of wai and warp?
On 01/19/2012 03:22 AM, Erik de Castro Lopo wrote: Michael Snoyman wrote: However, WAI and Warp are mostly ready now, just needing a bit more testing. If people want to give me some feedback on the readiness of them, and would like them released earlier, I'm definitely flexible. Meanwhile: yes, the Github version is conduit-based. Michael, I'm having some trouble getting the right set of dependencies for Conduit versions of wai and warp. At the moment I'm stuck on asn1-data; every version I can find of that seems to depend on enumerator. Humm, yeah, a bit sad, I'ld like to move away from them as well, and probably just moving to a raw-attoparsec-based API would be fine. But asn1-data is not part of wai/warp, and just a sub dependency of tls. so you can just have enumerator installed for it for the time being. -- Vincent @vincenthz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and Network.TLS
On 01/16/2012 08:28 PM, Myles C. Maxfield wrote: Hello! [snip] Hi Myles, I'm going to echo Felipe and Erik's comments, and think you'ld have a better time porting Network.Browser on top of http-enumerator (now called http-conduit). Looking at it quickly, it doesn't seems too difficult to do, and could be a worthwhile things to have. http-conduit is more useful in general for real world applications than HTTP. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
On 01/08/2012 02:35 PM, Aristid Breitkreuz wrote: 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. Using the hash and carrying it around are two different things. You don't get any usefulness once you have converted it indeed, but before hand this is quite handy sometimes. It's very similar to phantom types or newtype-ing. It also have a useful self-documentation factor, for example the later tell the user of myFunction more information than the former: myFunction :: ByteString - ByteString - SomeType myFunction :: ByteString - Hash SHA1 - SomeType -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] [ANNOUNCE] First release of crypto-conduit
On 01/07/2012 04:21 PM, Aristid Breitkreuz wrote: Yeah and that's annoying IMHO. :) It's not really important though. 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. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: clientsession-0.7.3.4 (performance enhancement)
On 11/27/2011 04:27 AM, Michael Snoyman wrote: Hi all, tl;dr: randomIV is now much faster, API is the same, upgrade ASAP to avoid painful slowdowns. Version 0.7 of clientsession brought with it a much enhanced encryption and hashing algorithm, courtesy of Felipe Lessa. Beginning with this version, you now need to provide an Initialization Vector (IV) for encrypting cookies, and these IVs need to be randomly generated. To start off with, we simply used the getIVIO[1] function to generate these values. Hi Michael, It's looking good. BTW, it looks quite similar to what cprng-aes do, which is expected since they are both implementing a AES CTR RNG, but i wonder if it would make sense to merge things together. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 11/22/2011 05:22 AM, Jeremy Shaw wrote: I think the artwork is nice, but I am not sure that a lamb is an appropriate mascot for Haskell. snip I disagree as well. I think you're looking too much into what a mascot should means; looking at others mascot, linux's tux, freebsd's demon, go lang's thingie, perl (and ocaml)'s camel, java's duke (huh?), ..., do you think that any of them subscribe to your description of what a mascot should be ? I think cute is good enough, and heathmatlock's lamb da, a good and simple name with a funny pun, definitely made me smile, and hope that's something i see on haskell tshirts soon ;-) (And as a side note, i think the honey badger looks like a brute animal, not an elegant and beautiful animal.) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
On 11/16/2011 01:01 AM, heathmatlock wrote: I liked Go's mascot, and I figure it couldn't hurt to have our own. I spent the past hour making this: http://i.imgur.com/Mib6Q.png awesome. It's really nice, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?
On 11/02/2011 09:51 AM, Eugene Kirpichov wrote: Hi Claude, I suspected that the issue could be about unsafe foreign imports - all imports in the cairo bindings are safe. I compiled myself a version of cairo bindings with the rectangle and fill functions marked as unsafe. Unfortunately that didn't help the case at all, even though the core changed FFI calls from __pkg_ccall_GC to __pkg_ccall. The performance stayed the same; the overhead is elsewhere. doing a ltrace, i think the reason is pretty obvious, there's a lot of GMP calls: __gmpz_init(0x7f5043171730, 1, 0x7f5043171750, 0x7f5043171740, 0x7f50431d2508) = 0x7f50431d2530 __gmpz_mul(0x7f5043171730, 0x7f5043171750, 0x7f5043171740, 0x7f50431d2538, 0x7f50431d2508) = 1 __gmpz_init(0x7f5043171728, 1, 0x7f5043171748, 0x7f5043171738, 0x7f50431d2538) = 0x7f50431d2568 __gmpz_mul(0x7f5043171728, 0x7f5043171748, 0x7f5043171738, 0x7f50431d2570, 0x7f50431d2538) = 1 __gmpn_gcd_1(0x7f50431d2580, 1, 1, 1, 1) = 1 repeated thousand of time before each call cairo calls. just to make sure, the C version doesn't exhibit this behavior. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ridiculously slow FFI, or cairo binding?
On 11/02/2011 10:10 AM, Eugene Kirpichov wrote: Oh. This is pretty crazy, I wonder what they're doing with GMP so much... I modified the Haskell program to use cairo directly, even with safe calls, and it now takes the same time as the C program. yep, i ended up doing the exact same thing for testing, foreign import ccall cairo_rectangle my_rectangle :: CI.Cairo - CDouble - CDouble - CDouble - CDouble - IO () and just replacing the rectangle call make almost all the difference for me (almost as fast as C) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New rss maintainer
On 10/20/2011 08:27 PM, Bas van Dijk wrote: Hello, I've a small patch[1] that updates the rss package to the latest versions of its dependencies. (I'm trying to get the new hackage-server to build on ghc-7.2.1) However Bjorn Bringert told me he's no longer maintaining the package. He asked me to ask you if there's already a new maintainer. If not, does any one want to take over the package? Jeremy, maybe you? Otherwise I could take it over. I probably won't make lots of changes since I'm a bit swamped at the moment. Just updating it to the latest versions. Perhaps, unless someone step up, it would be nice to move packages that have no maintainer anymore into a github organisation (haskell-janitors ?), where each package could have many owners and it's easy and simple to add/remove push rights there. That could also be an obvious place to look, for newcomers, to get involved. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
On 10/18/2011 01:30 AM, Conrad Parker wrote: And I often work with mixed text/binary data (eg. text annotations in video streams). I'd want the Show/Read instances to be in the form of a hexdump with char representation alongside (like xxd or od -xc output). It roundtrips well, so why not? :-) (slightly out of topic ...) I often do mixed text/binary too, and i now use the following package: http://hackage.haskell.org/package/bytedump The problem with a Show instance is that there's no way to configure some aspects of it :-) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hit a reimplementation of git storage in haskell.
On 10/04/2011 11:07 PM, Jason Dagit wrote: On Tue, Oct 4, 2011 at 2:15 PM, Vincent Hanquezt...@snarc.org wrote: Any comments welcome, Nice! Have you looked at Petr Rockai's hashed-storage? http://hackage.haskell.org/package/hashed-storage-0.5.8 i heard about it before, but i don't know much more than that. I had a quick look at the hackage documentation: it's interesting and fairly similar in some aspects. thanks, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hit a reimplementation of git storage in haskell.
On 10/05/2011 01:58 AM, Conrad Parker wrote: Hi Vincent, great stuff! I've also got an in-progress toy git clone called ght: http://github.com/kfish/ght. It only reads, no write support and no revspec parsing. I tried to keep close to the git design, using mmap and Ptr-based binary search to read pack indices etc. Doing so seems fairly un-Haskelly but turned out surprisingly neat, what with Haskell being the world's finest imperative programming language and all. Conrad. Hi Conrad, Look like i'm not the first one to kind-of reimplement git ;-) In my use case, creating objects was the most important bit to get this project running. Design wise, i made sure i can switch to mmap later too, which is the reason of the filereader abstraction. I'm actually getting a hold of mmap in haskell in a work project right now, and will probably add a mmap mode along with the handle mode to hit's filereader too. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hit a reimplementation of git storage in haskell.
Hi Haskellers, I just want to announce the hit project [1], which is a reimplementation of low level git operations to read *AND* write to a git repository. It support reading from anything i threw at it (loose objects, packed objects, deltas), a subset of revisions specifier (man gitrevisions), and writing new objects (blob, tree, commit, tag). I don't necessarily want to re-implement git itself (although patches welcome if someone want to go in this direction), and as such the project is a bit of a toy to investigate git storage (for another project of mine) and superseeding my own libgit project (for yet another project). Yet it should be completely functional and have good performance. A few word of the implementation: it's very IO based at the moment; The way things are done by git, doesn't necessarily cope with pure and nice stuff if performance need to follow. That said it should still be easier to understand than reading the git source :-) Any comments welcome, [1] http://hackage.haskell.org/package/hit/ -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANN] crypto-api-tests
On 09/27/2011 11:54 PM, Thomas DuBuisson wrote: The crypto-api test modules have been split out into their own package, crypto-api-tests. Additionally, the tests now use the test-framework package. This should make it much easier for hash/cipher maintainers to integrate into their existing testing infrastructure. For example: Thanks Thomas ! That is really useful. I'll make sure i get cryptocipher and cryptohash on board .. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On 09/22/2011 02:00 AM, Felipe Almeida Lessa wrote: On Wed, Sep 21, 2011 at 5:19 PM, Vincent Hanquezt...@snarc.org wrote: Also, it seems that cryptohash's Skein is currently broken. The skein package comes with the golden KATs sent by the Skein team to the NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512. I've attached a test suite that quickchecks if both implementations give the same answer. My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails: oops darn, thanks for reporting. i'll have a look at that ASAP; It used to work in the past, and i've copied some expected values from the original implementation in my small unit tests (which still pass :-/ ), so i'm a bit puzzle here. Perhaps you have implemented some old version of Skein? I know they have changed the constants some times in the past. yeah that was it. looks like 2 minor revisions were made when i wasn't looking (only the parity constant has change from 0x55.. to 0x19..). Seems that everything is back in order now, but i'll make sure i put cryptohash's skein under the full KAT test suite in a near future. Thanks, -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On 09/21/2011 05:01 PM, Felipe Almeida Lessa wrote: I'm aware of cryptohash. I just went through the lazy route of binding to the C library instead of implementing those UBI details =). hehe, fair enough. :-) It would be nice to merge and have everything on cryptohash though. And I guess that cryptohash may become faster than skein because the C library has some implementation details that are unneeded (e.g. it has a buffer, but hash/hash' are kind enough to only give full buffers to the libraries). speed wise, i would really like to see the parallel tree hashing going :) Also, it seems that cryptohash's Skein is currently broken. The skein package comes with the golden KATs sent by the Skein team to the NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512. I've attached a test suite that quickchecks if both implementations give the same answer. My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails: oops darn, thanks for reporting. i'll have a look at that ASAP; It used to work in the past, and i've copied some expected values from the original implementation in my small unit tests (which still pass :-/ ), so i'm a bit puzzle here. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On 09/21/2011 03:53 AM, Felipe Almeida Lessa wrote: Hello! I'm pleased to announce the first version of the skein package [1]! Skein is a family of fast secure cryptographic hash functions [2]. The skein package provides high-level bindings (using crypto-api [3]) to the optimized Skein C library. Currently we support Skein as a hash function and also Skein as a message authentication code (MAC). The code is well-documented with examples and has many known answer tests (KATs). It currently lives on patch-tag [4]. Hackage will be build the docs soon enough. Meanwhile, here's a short example: Hi Felipe, it's good to see more Skein stuff. it's a great crypto hash and one of the few remaining candidate for SHA-3. Have you seen the cryptohash package http://hackage.haskell.org/package/cryptohash ? I always wanted to expose more skein operations specially the hmac function, but never came around to, and maybe it would be good to merge to avoid duplicating efforts ? -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: taffybar: an alternative status bar for xmonad
On Sat, Aug 13, 2011 at 10:56:49AM -0500, Tristan Ravitch wrote: I've wanted a slightly fancier status bar than xmobar for a while, so I finally made one. It uses gtk2hs and dbus extensively, so if you hate either of those things it probably isn't for you. Being written in gtk, though, it can have more graphical widgets. http://hackage.haskell.org/package/taffybar Hi Tristan, Thanks for this new status bar, this is exactly what i've been looking for xmonad ! A word of warning though, it seems to wakeup a bit too much (and do too much work at wakeup) with the example configuration and make a laptop great for winter as a hand warmer :-) I ended up with just the clock widget (setup to update every minute instead of every second), the system tray, and the logwidget, and the wakeup rate is completely acceptable, and the cpu time stays low. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Text.CSV questions
On 06/17/2011 10:00 AM, Dmitri O.Kondratiev wrote: Hi, I try to parse csv file with Text.CSV, like this: import Text.CSV import System main = do [inpFileName] - getArgs putStrLn (Parsing ++inpFileName++...) let result = parseCSVFromFile inpFileName print result === As a result I get: No instance for (Show (IO (Either Text.Parsec.Error.ParseError CSV))) arising from a use of `print' Possible fix: add an instance declaration for (Show (IO (Either Text.Parsec.Error.ParseError CSV))) === Question: How to add a Show instance for (IO (Either Text.Parsec.Error.ParseError CSV))) ? Hi Dmitri, you don't add a show instance for IO, but you unwrap the IO Monad first and then show the result. let result = parseCSVFromFile inpFileName should be: result - parseCSVFromFile inpFileName -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Crypto-api performance
On Thu, May 05, 2011 at 11:56:42AM +0200, Peter Simons wrote: Hi Matthew, While I haven't investigated myself, from seeing haskell build processes in the past this is almost certainly not crypto-api's fault and is in fact your linker's fault. If you are not using it already, try switching to gold over ld, it may help. well, memory consumption sky-rockets while compiling Crypto.CPoly. That behavior is probably not related to the linker. That's more than likely linked to the huge dispatch table related to cpoly. It would probably helps to build a vector with the data instead of this. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't install haskellnet with ghc7
On 04/26/2011 10:17 PM, Charles-Pierre Astolfi wrote: Hi -cafe, Did anybody managed to install haskellnet from hackage with ghc7? I tried on windows and mac and I get the following type error: [ 4 of 11] Compiling Network.HaskellNet.SMTP ( Network/HaskellNet/SMTP.hs, dist/build/Network/HaskellNet/SMTP.o ) Network/HaskellNet/SMTP.hs:269:25: Couldn't match expected type `Data.Text.Internal.Text' with actual type `[Char]' Expected type: Data.Text.Internal.Text Actual type: String In the first argument of `simpleMail', namely `to' In a stmt of a 'do' expression: myMail- simpleMail to from subject plainBody htmlBody attachments Am I missing something? your mime-mail library is too recent. the upper version in the cabal file of haskellnet is not limited, so it's picking up the 0.3.0 version which is incompatible with the 0.2.x. Otherwise it was working for me with the previous version for both ghc6 and ghc7. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to daemonize a threaded Haskell program?
On Sat, Mar 05, 2011 at 08:51:59PM +0100, Bas van Dijk wrote: Hello, I like to turn my Haskell program into a unix daemon. One of the steps in daemonizing a process is to fork it then exit the parent and continue with the child. All this is nicely abstracted in hdaemonize[1] which internally calls forkProcess[2]. I would also like to use multiple simultaneous threads in my program. Unfortunately forkProcess is not supported when running with +RTS -N so I can't use hdaemonize. I understand why it's problematic to fork a process which is in the middle of running multiple simultaneous threads. However, in the case of a daemon the fork happens in the beginning of the program. So if I can manage to create a program that first daemonizes my process then starts the Haskell program, all is good. My current plan is to have a custom Haskell main function which is exported using the FFI: Hi, Did you alternatively though about daemonizing in your haskell program normally without using +RTS -N, and exec'ing yourself (using executeFile) with the extra cmdline +RTS -N options, and also --no-daemon option to avoid re-daemon/exec'ing ? I think that would be simpler than your current approch. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status update on {code, trac, projects, planet, community}.haskell.org
On Thu, Feb 17, 2011 at 07:30:23PM +0100, Henning Thielemann wrote: Do you think it is paranoid? Unfortunately it has become quite common to ignore SSH warnings because admins often do not care about restoring keys when updating the operating system or moving the machine, even not telling users that the host key has changed. But if I had ignored the SSH warning on code.haskell.org recently I might have logged in and from there maybe to other servers, thus giving my passwords to the attackers. I think generally that just deleting a host from known_hosts in response to an SSH warning and blindly accepting a new host key is not a fix. Am I too afraid? If sshd has been compromised, so is the original host private key. It would be kind of pointless (security wise) to restore it on the new server. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On Tue, Feb 15, 2011 at 11:49:16PM -0200, Diego Souza wrote: Hi, thanks for the feedbacks. They sound very reasonable. Going back in time, the first version was in fact a pure library. However, at some point I changed this as I thought it would make it easier to use, which might have been a mistake of mine. Back then http-enumerator wasn't available and after it did I haven't considered using it until now. I'm just concerned about changing the interface once more, but it might be justified. Perhaps splitting it into the pure oauth functions as used to be in the beginning and another one that puts the http layer, in case one finds it convenient. That might mitigate this problem, and perhaps, avoid changing the interface. What you guys think? I think such separation would be great ! however ultimately, i don't think there's any reason why would you not target http-enumerator directly and drop all the abstraction ? As long as thing changes, you might consider using crypto-api CPRNG classes instead of random. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use http-enumerator with hoauth?
On Tue, Feb 15, 2011 at 10:42:57AM -0800, Jeremy Fitzhardinge wrote: And since I'm still trying to get my head around enumerators, I may have that aspect of things completely wrong. I haven't even tried running any of this yet, so I don't know if I've made any non-type errors. Am I even barking up the right tree at all? Should I try to be using hoauth this way at all, or should I just hack it up to work within http-enumerator? That seems counter-productive. A general comment: There are many partially functional http packages in hackage. It seems to me that rather than requiring one package be a complete http library, we would get further by allowing different packages to implement different aspects of http, so long as they can all be composed in a reasonable way. At the very least, is it really necessary for hoauth to define its own Request/Response types? Would it be worthwhile trying to define general types which all http packages could use? Is that the goal of Network.Wai? What about the HTTP package? Should I just use that instead? What about Network.Curl? Clearly, http-enumerator is the best package for doing http/https. however since it's pretty new, lots of package still uses their own abstraction for doing things. While it may be possible to retrofit hoauth to use http-enumerator, using the httpclient typeclass, that's going to be hard to fit the full enumerator interface on it, so you won't benefit of streaming; You may as well just use network.curl for now, which is what i've seen used with hoauth. you should check the twidge twitter utility and/or yesod-auth-oauth, that both uses curl/hoauth. It would be really useful to see an hoauth fully using enumerator and http-enumerator (and not redefining a boat load of stuff), but IMO you'll need to understand enumerators before tackling such a challenge. Also Wai is for abstracting server side transport (cgi/fastcgi/others), and the HTTP package doesn't do TLS. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AES on 32-bit system
On Fri, Feb 04, 2011 at 08:00:24AM +0200, Michael Snoyman 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? Hi Michael, well, Thomas DuBuisson and I talked about it couple of days ago, and i'm probably going to incorporate AES into cryptocipher directly, so dropping the dependancy problem. I'm not a big fan of the C implementation, so i'll be looking into replacing it by an implementation i made couple of years back (providing it's at least providing the same level of performance), and adding support to AES-NI (although I've heard that someone else might be working into that as well). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AES on 32-bit system
On Fri, Feb 04, 2011 at 06:11:38AM +, Daniel Peebles 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? While it does indeed solve the problem, technically the whole code redefine stdint, so uint_64t is actually not a typo, but the way it's been defined. That's one of the reason I don't really like this implementation; looks like a #ifdef nightmare to support (too) old environment. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
On Tue, Dec 14, 2010 at 11:41:29AM +0100, Mads Lindstrøm wrote: Hi Vincent, I got it to work :) But there seems to be some bugs in the Haskell server certificate handling. It seems that TLS do not transfer the ST (state, as in California) parameter in the X509 subject field. It also seems that the Haskell server do not send the email-address. The reason for my suspicion is that when I connect my Java client to the Haskell server, the client sees this certificate: Hi Mads, That's great you got it to work. The certificate fields missing is indeed a bug in the certificate package, which I just fixed in certificate-0.4 (mainly I forgot to write all the others fields in the Distinguish Name structure). I reuploaded a new tls 0.3.2 as well for convenience, and couple of others minor fixes. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
On Tue, Dec 14, 2010 at 10:24:29PM +0100, Florian Weimer wrote: * Mads Lindstrøm: I got it to work :) But there seems to be some bugs in the Haskell server certificate handling. It seems that TLS do not transfer the ST (state, as in California) parameter in the X509 subject field. It also seems that the Haskell server do not send the email-address. And in reality, DER encoding isn't reversible, so you better serve the exact certificate blob which was passed to the server. Decoding and reencoding does not work reliably because sometimes, a non-DER version of the certificate has been signed. DER encoding IS fully reversible. However you're right about some certificate, that have been improperly signed when they were not valid DER. Hopefully this is a thing of the past, and I do intent to keep re-encoding the certificate instead of passing a binary blob (as i used to do at first, with some vestigial code still present). It gives a good workout to the certificate and asn1 DER modules as well, which isn't all that bad. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS package server interface do not seem to allow for asyncrhonious communication
On Tue, Dec 14, 2010 at 09:21:48PM +0100, Mads Lindstrøm wrote: Hi Haskeleers, [snip] It seems to me that a general SSL implementation should not preclude asynchronous servers. I know, the TLS package is not more than a few months old and one can already use it for SSL servers and clients, which is quite impressive. So do not read this as a negative comment, more as suggestions for a better interface. Hi Mads, You're right about the interface; but as Antoine pointed out, for now you can just use a thread for each connection. I do hope to at some point have a more rich interface for IO; I'm definitely looking to adopt Michael's TLS enumerator client interface (see the excellent http-enumerator package), but for the server I haven't really though about it yet. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
On Sun, Dec 12, 2010 at 08:13:59PM +0100, Mads Lindstrøm wrote: Hi Haskellers, I am trying to connect a Java client to a Haskell server using the Haskell tls package, and things are not working out for me. There is a lot of steps involved and I do not know what I am doing wrong, so this is a long message. But first I create a private/public key-pair: On Mon, Dec 13, 2010 at 01:22:17AM +0100, Mads Lindstrøm wrote: Hi again, I found a simpler way to test the server connection, but it is still not working. Namely, openssl s_client -connect 192.168.1.6:8000 Hi Mads, This one has to do with the fact that openssl try to send a SSLv2 hello message, which is not yet supported by TLS (and not in the supported Version list in the params if it was). unfortunately lots of clients still do that for compatibility; even though that doesn't buy much since nobody should connect to a pure SSLv2 server. For the openssl cmdline, you can add a simple -ssl3 flag or -tls1 flag to start negociating at the right version straight away. [snip] main, WRITE: SSLv2 client hello message, length = 101 [snip] This lines appears suspicious; I think that's exactly the same problem. I suppose there's a way to instanciate your java SSL connection to SSL3 or TLS1 It would be nice to add support to the SSLv2 hello message directly though, but I don't have any timeline for that to happens. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 08/12/10 20:25, Luke Palmer wrote: I could upload a new version of mtl if I wanted. Plenty of people would install it. Correct me if i'm wrong; You would appear in the UploadedBy, and then you might be challenged by the traditional uploaders or attentive users (most users wouldn't know of course) to give a reason of doing the upload. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 08/12/10 10:41, Ketil Malde wrote: Yes. And you should start with assessing how much cost and inconvenience you are willing to suffer for the improvement in security you gain. In this case, my assertion is that the marginal worsening of security by having a mirror of hackage even without signing of packages etc., is less than the marginal improvement in usability. I'm a bit surprised to find that there seems to be a lot of opposition to this view, but perhaps the existing structure is more secure than I thought? Or the benefit of a mirror is exaggerated - I can see how it would be annoying to have hackage down, but it hasn't happened to my, so perhaps those complaining about it just were very unlucky. You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, where it can be verified by cabal that the package hasn't been signed properly. This is not about all the way signing of every uploaders, with chain of trust and such (which has been proposed by wren). The implication on the users should be minimal. I mean they shouldn't even know about it. It would only complain if the signature isn't valid. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dot-ghci files
On 09/12/10 07:01, Tony Morris wrote: I teach haskell quite a lot. I recommend using .ghci files in projects. Today I received complaints about the fact that ghci will reject .ghci if it is group-writeable. I didn't offer an opinion on the matter. I am wondering if these complaints have legitimate grounds i.e. maybe you want to have group write on that file for some reason. I'd appreciate some comments on this issue. Thanks. You can insert *any* commands in the ghci file. including some system commands, to delete everything. That's probably the reason to deny a file to be group writable (anyone in a group could write bad thing in there) you can try putting the following in the .ghci to check for example: readFile somefileyouwanttoread = writeFile /tmp/apublicplace -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On Thu, Dec 09, 2010 at 10:45:39PM +1100, Ivan Lazar Miljenovic wrote: On 9 December 2010 20:55, Vincent Hanquez t...@snarc.org wrote: You might have misunderstood what I was talking about. I'm proposing signing on the hackage server on reception of the package, where it can be verified by cabal that the package hasn't been signed properly. By cabal, are you referring to Cabal or cabal-install? If the former, then I'm not sure how exactly it would do such verification since it doesn't have any notion of the internet as far as I'm aware; if the latter then it means absolutely nothing for those of us that do not use cabal-install for most packages. I don't really know the difference between Cabal and cabal-install, but Something is downloading the .tar.gz, and that thing can always download an extra .tar.gz.sign file which contains a way to verify that's the .tar.gz is genuinely the one that has been received by hackage. For those not using the thing-that-download-archive to get their package from hackage, they can build the same mechanism that download an extra file, and check the signature. Or they can even choose not to bother, and just download the package as they just did before. Note that, I'm not actually inventing anything new here, this is a common way to distribute software (linux distributions, many opensource softwares, etc). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 08/12/10 08:13, Ketil Malde wrote: My apologies for not expressing myself more clearly. What I mean is that currently, Hackage has a ton of users, each of whom may at whim upload a new version of any library. It's not clear to me that security is significantly worsened by adding a mirror. Assume I am out with ill intent: I can now either a) set up a mirror, replace some central library with my evil trojan, launch a DOS attack against hackage.haskell.org to get users to switch, and gloat in my secret castle as I await the fruits of my cunning schemes -- or I can b) just upload my trojan library to hackage directly. You have to start somewhere with security. I think that an uploaded trojan library would be at least detectable as such, since the uploading user would have change (i'm not sure that what you had in mind ?). Whereas on a mirror, it would be completely transparent to the users. As a first step, having the hackage server and its users trusted, is hopefully reasonable. And then you can build up from there. This would be nice to be proactive before we actually detect such a thing, and we have to build a security infrastructure anyway ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
I would really like mirrors too. But before that happens it would be nice to have signed packages on Hackage, preventing a mirror to distribute compromised stuff (intentionally or unintentionally). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: tls, native TLS/SSL protocol implementation
On Sat, Oct 09, 2010 at 12:53:17PM +0100, Maciej Piechotka wrote: I don't think I quite follow. Could you explain? sorry for beeing confusing. I meant something like a pure iteratee interface, so that you get the marshalled data to send in a bytestring format, and then you can decide yourself what to do with this bytestring (send it to a handle, discard it, process it as the other side) Maybe serverStartTLS? ok, I'll think about it; I'm not thrilled by that though ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Mon, Oct 11, 2010 at 09:06:45AM +0100, Sittampalam, Ganesh wrote: While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Hi Ganesh, You're absolutely right in the fact there's risk involved. Cryptography related things are hard to get right, I won't be denying it. However I'm really not a big fan of the alternative. Having to rely forever on blessed black boxes coded in low level languages, doesn't sound appealing to me. There's the risk that cryptography becomes even more voodoo magic by doing that. This is certainly true for TLS/SSL. a lots of people have no idea how it works, what it does and doesn't do. So hopefully having a clean haskell library will make more people interested, in changing this black-box state; an even bigger hope, is to vulgarize cryptography, instead of making it more opaque ;) Anyway, it's just a feeling. Please do prove me wrong :-) I'll certainly try ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote: What's the motivation for this? Well, I wanted to have a tls/ssl module that integrate nicely with haskell. until then the 2 solutions were: - shelling out to curl: that's not great, usually works until you have an error, and then you're greeted with a curl command line error. the control is pretty poor, what if you want a fancy certificate control ? Also you have absolutely no server support in this case, this is client only. - using either gnutls or openssl bindings: there's multiples reasons this is not great. depending on huge C libraries (security wise, platform wise), massive usage of IO even in place where it shouldn't, low hacking potential (adding ciphers/hash, etc). Apart from that, we all know here why programming in haskell is better than doing the same thing in says, C or python. I think it apply even more when the focus of this is a secure library. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Fri, Oct 08, 2010 at 02:08:29PM +0200, Christopher Done wrote: Indeed. Easier to install, easier to hack on (for Haskellers). Haskell program coverage, debugging, extending your quickcheck tests, etc. absolutely. I'm certainly hoping to quickcheck all that is quickcheckable. The next thing i want to add to the tests is the TLS startup configuration, to that quickcheck test every possible handshake scenario (certificate, no certificate, block cipher, stream cipher, RSA, DH, DSA, TLS1.2, TLS1.1, TLS1.0, SSL3, etc). There's also the type-system experience, which raise the safety experience massively. I feel much better seeing pure functions and clearly bounded types instead of a pointer to the whole world as it is quite common in gnutls and openssl. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: tls, native TLS/SSL protocol implementation
On Fri, Oct 08, 2010 at 12:59:56PM +0100, Maciej Piechotka wrote: 1. Could also callback in addition to handles be added? Like: connect' :: (ByteString - IO ()) - IO ByteString - TLSClient IO () Would an interface that generate the packet to send and just return them as bytes be even better ? connect' :: TLSClient () ByteString I'm hoping to have something like that so i can use quickcheck to verify that all possible configurations result in a workable connection. 2. Does listen corresponds to listen(2)? If yes how to handle STARTTLS server-side? If no - please rename it. it's not doing the same thing as the socket listen(2). it waits for the handle passed as argument to establish a new TLS session as in: listen to the new tls connection. after reading STARTTLS, you would call listen that would listen for the TLS context to be established. Please suggest something, if you want me to rename it though, as I can't really think of a better name. -- Vincent Hanquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Fri, Oct 08, 2010 at 11:14:01AM +0530, C K Kashyap wrote: Does native mean Haskell only - without FFI? Native means the implementation is in haskell, and the library is not using another implementation (in another language) to do the work: either through FFI as a binding, or as a wrapper to an external program. -- Vincent Hanquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Fri, Oct 08, 2010 at 08:47:39AM +0200, Michael Snoyman wrote: By the way, a native zlib implementation would definitely go on my wishlist. Any takers? ;) Me too ! that's the only thing that prevented me from adding the compression layer to TLS. as such it's on my todo list, but really really low priority ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Thu, Oct 07, 2010 at 12:29:51AM +0200, Christopher Done wrote: On 6 October 2010 23:26, Vincent Hanquez t...@snarc.org wrote: I'ld like to announce the tls package [1][2], which is a native implementation of the TLS protocol, client and server. It's currently mostly supporting SSL3, TLS1.0 and TLS1.1. It's got *lots* of rough edges, and a bunch of unsupported features, but it's humming along, and at each iteration it's becoming more tighly secure and featureful. Wow, great! So might we be able to combine this with Network.HTTP some day? I am interested in moving away from C libraries (curl) to pure Haskell libraries, for a safer, richer Haskell ecosystem and for solving the interesting problems. That's one of the goal of this library. Ultimately I want something more flexible than usual APIs in traditional libraries; TLS can do lots of things, that are not typically exposed by others libraries. Otherwise more pratically, there's michael's http-enumerator. I hope i'll see more package depending on tls in the future instead of gnutls/openssl bindings. Will you eventually add benchmarks? This is on my TODO list but the priority is quite low; I'm trying to focus on correctness and security for now. However I suspect what does make the biggest difference is the crypto implementation that is used, and the current dependencies should be all reasonable (cryptohash is close to C performance level with hashes, the AES package has a pretty fast implementation, ghc seems quite good with big number benefiting RSA, ..). -- Vincent Hnquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
Hi haskellers, I'ld like to announce the tls package [1][2], which is a native implementation of the TLS protocol, client and server. It's currently mostly supporting SSL3, TLS1.0 and TLS1.1. It's got *lots* of rough edges, and a bunch of unsupported features, but it's humming along, and at each iteration it's becoming more tighly secure and featureful. I would recommend against using this implementation in a production system just yet, or in an aggressive environment either (specially for the server side); I don't think it should necessary fail, but it's still an early implementation with probable API changes on the way. [1] http://github.com/vincenthz/hs-tls [2] http://hackage.haskell.org/package/tls -- Vincent Hanquez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
