Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
On Fri, Oct 8, 2010 at 10:26 AM, Vincent Hanquez t...@snarc.org wrote: 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 ;) Well, it's not a native (= pure Haskell) implementation, but I just released zlib-bindings[1] the provides a more Haskell-ish interface than the raw C API of zlib, yet a more low-level and stream-oriented API than the zlib package. I've put up a little blog post explaining the package a bit[2]. Michael [1] http://hackage.haskell.org/package/zlib-bindings [2] http://docs.yesodweb.com/blog/announcing-zlib-bindings/ ___ 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
* Donn Cave: Quoth Florian Weimer f...@deneb.enyo.de, wikipedia: Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the management of a Common Language Runtime virtual machine (resulting in Bytecode). I like this term, I apply it by extension to any system which enforces memory safety (as long as you stick to non-internals, such as array indexing, even Java has got (in practical terms) fairly portable PEEK/POKE operations). ... enforces memory safety? Can't that be done in code compiled straight to CPU instructions without even calling a run-time, let alone being managed by one? It is quite possible to have memory-unsafe interpreted languages. I wouldn't necessary call them managed. For example, a simple interpreted Forth might have explicit words for heap allocation and deallocation. This isn't a interpreted/compiled distinction (and the line between the two is increasingly blurred because there are high-performance compilers these days for languages which are traditionally considered interpreted). You need restrictions on memory deallocation (which must follow a stack or region descipline), and thus indirectly on allocation. I don't think region inference has caught on, which suggests that there are inherent limitations when trying to apply it to application code. I'm not sure what you mean, but in this case, the term has surely been extended too far - it doesn't seem to be managed code in the sense quoted above, nor does it seem to fit with common non-technical usage of managed. Not really---many C programmers associate memory safety with micromanagement by the language environment. In other words, a new way to say `interpreted', This term doesn't really apply that well to the CLR because its bytecode really can't be interpreted efficiently. (The bytecodes lack type information.) To me, the CLR takes bytecode, maps it in some way to CPU machine code and executes the latter. I would call that interpreted, but you wouldn't? Or am I wrong about what's happening? I know Wikipedia isn't necessarily the ultimate authority of computer science, but Many interpreted languages are first compiled to some form of virtual machine code, which is then either interpreted or compiled at runtime to native code. (... going on to cite Java and .NET Framework among others), so I'm not the only one who finds it expedient to use that word interpreted in this context. I think the word is increasingply meaningless. Current x86 CPUs (excluding the low-power variants) turn transform the instruction stream before execution, too. Your VM hypervisor might emulate the effect of certain instruction sequences which cannot be virtualized solely in hardware. C language environments contain run-time code generation to tune for the specific CPU on which they are running. And historically, even C was compiled to bytecode, so that large programs could fit into available RAM. And so on. At this point, I still don't know for sure if you think a GHC-compiled Haskell program is managed, or unmanaged, but I think managed? Yupp, it's managed (at least according to my own use of the word). Haskell tries quite hard to protect its own abstractions (which is essentially another view on memory safety). And in my confused present state I would say it's unmanaged. Johan Tibell speaks of the GHC I/O manager, so I think I'm in good company. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/9/10 09:17 , Malcolm Wallace wrote: On 8 Oct 2010, at 16:56, Donn Cave wrote: wikipedia: Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the management of a Common Language Runtime virtual machine (resulting in Bytecode). In other words, a new way to say `interpreted', I believe the wikipedia description is misleading. The difference between managed and unmanaged code is that the former is garbage-collected (i.e. free of memory freeing errors), whilst the latter is responsible for its own memory behaviour. More to the point, the runtime makes it impossible to acquire a pointer to memory that is not checked. This is in specific distinction to C and C++, where the former is entirely unmanaged and the latter usually only checks pointers when compiling for debugging (and even then it's mostly just like C, only it has some assert()s in some STL constructors). - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkywxzEACgkQIn7hlCsL25WxBgCgvvfrsSEuOk2Qaa7CUGE53K7L hxIAnjDk/N8/aJaotZN+NnGUjnCuPGqX =FwAF -END PGP SIGNATURE- ___ 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 8 October 2010 07:44, C K Kashyap ckkash...@gmail.com wrote: Does native mean Haskell only - without FFI? I think not Haskell would be piping to a separate non-Haskell process or calling by FFI to another language to do the interesting work. Thus native is not using these for the interesting work. E.g. I can call out to zlib with the FFI and call it a Haskell zlib library. It's not really a native Haskell implementation, though. ___ 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 8, 2010 at 8:08 AM, Christopher Done chrisd...@googlemail.com wrote: On 8 October 2010 07:44, C K Kashyap ckkash...@gmail.com wrote: Does native mean Haskell only - without FFI? I think not Haskell would be piping to a separate non-Haskell process or calling by FFI to another language to do the interesting work. Thus native is not using these for the interesting work. E.g. I can call out to zlib with the FFI and call it a Haskell zlib library. It's not really a native Haskell implementation, though. By the way, a native zlib implementation would definitely go on my wishlist. Any takers? ;) Michael ___ 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
* Vincent Hanquez: 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. I can see how this terminology makes sense, but it's the opposite of the usage in Java (where native == unmanaged code called via JNI). ___ 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 8, 2010 at 3:36 PM, Florian Weimer f...@deneb.enyo.de wrote: * Vincent Hanquez: 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. I can see how this terminology makes sense, but it's the opposite of the usage in Java (where native == unmanaged code called via JNI). I guess it depends on the context. If the context is a C program then 'native' means the C code in the program and 'foreign' means other code like Haskell. If the context is a Haskell program then 'native' means the Haskell code and 'foreign' means other code like C. Most of the time we're programming in Haskell so I think our context is Haskell. Also note that the _Foreign_ Function Interface hasn't been named the Haskell _Native_ Interface. Bas ___ 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
Quoth Bas van Dijk v.dijk@gmail.com, On Fri, Oct 8, 2010 at 3:36 PM, Florian Weimer f...@deneb.enyo.de wrote: ... I can see how this terminology makes sense, but it's the opposite of the usage in Java (where native == unmanaged code called via JNI). I guess it depends on the context. If the context is a C program then 'native' means the C code in the program and 'foreign' means other code like Haskell. If the context is a Haskell program then 'native' means the Haskell code and 'foreign' means other code like C. wikipedia: Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the management of a Common Language Runtime virtual machine (resulting in Bytecode). In other words, a new way to say `interpreted', and `native' vs. `interpreted' is a familiar distinction for more computing environments than just Java. But it isn't relevant here, right? Since neither the Haskell nor OpenSSL implementations are both compiled to CPU instructions. Donn Cave, d...@avvanta.com ___ 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
* Donn Cave: wikipedia: Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the management of a Common Language Runtime virtual machine (resulting in Bytecode). I like this term, I apply it by extension to any system which enforces memory safety (as long as you stick to non-internals, such as array indexing, even Java has got (in practical terms) fairly portable PEEK/POKE operations). In other words, a new way to say `interpreted', This term doesn't really apply that well to the CLR because its bytecode really can't be interpreted efficiently. (The bytecodes lack type information.) and `native' vs. `interpreted' is a familiar distinction for more computing environments than just Java. But it isn't relevant here, right? Since neither the Haskell nor OpenSSL implementations are both compiled to CPU instructions. Obviously, this depends on the implementation. For Haskell and Java, implementations which are based on precompiled machine code exist. There are also implementations which rely on some form of interpretation exclusively. That's why the managed/unmanaged distinction is more useful than the interpreted/compiled distinction. ___ 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
Quoth Florian Weimer f...@deneb.enyo.de, wikipedia: Managed code is a differentiation coined by Microsoft to identify computer program code that requires and will only execute under the management of a Common Language Runtime virtual machine (resulting in Bytecode). I like this term, I apply it by extension to any system which enforces memory safety (as long as you stick to non-internals, such as array indexing, even Java has got (in practical terms) fairly portable PEEK/POKE operations). ... enforces memory safety? Can't that be done in code compiled straight to CPU instructions without even calling a run-time, let alone being managed by one? I'm not sure what you mean, but in this case, the term has surely been extended too far - it doesn't seem to be managed code in the sense quoted above, nor does it seem to fit with common non-technical usage of managed. In other words, a new way to say `interpreted', This term doesn't really apply that well to the CLR because its bytecode really can't be interpreted efficiently. (The bytecodes lack type information.) To me, the CLR takes bytecode, maps it in some way to CPU machine code and executes the latter. I would call that interpreted, but you wouldn't? Or am I wrong about what's happening? I know Wikipedia isn't necessarily the ultimate authority of computer science, but Many interpreted languages are first compiled to some form of virtual machine code, which is then either interpreted or compiled at runtime to native code. (... going on to cite Java and .NET Framework among others), so I'm not the only one who finds it expedient to use that word interpreted in this context. and `native' vs. `interpreted' is a familiar distinction for more computing environments than just Java. But it isn't relevant here, right? Since neither the Haskell nor OpenSSL implementations are both compiled to CPU instructions. Obviously, this depends on the implementation. For Haskell and Java, implementations which are based on precompiled machine code exist. There are also implementations which rely on some form of interpretation exclusively. That's why the managed/unmanaged distinction is more useful than the interpreted/compiled distinction. I don't know, of course this is partly due just to my own ignorance, but it seems to me that the awkward semantics around this distinction make it somewhat prone to confusion. Maybe the kind of thing that's useful to your understanding of computational environments, but less useful when discussing them with others? At this point, I still don't know for sure if you think a GHC-compiled Haskell program is managed, or unmanaged, but I think managed? And in my confused present state I would say it's unmanaged. Donn Cave, d...@avvanta.com ___ 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
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
Does native mean Haskell only - without FFI? -- Regards, Kashyap ___ 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
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocol implementation
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. Will you eventually add benchmarks? Reading this source code will be educational. Thanks. ___ 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 7, 2010 at 12:29 AM, Christopher Done chrisd...@googlemail.com 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. Will you eventually add benchmarks? Reading this source code will be educational. Thanks. The http-enumerator package[1] actually uses either the tls package or OpenSSL as its backend. [1] http://hackage.haskell.org/package/http-enumerator ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
