Re: [racket-dev] Native graphics libraries upgraded for Windows and Mac OS X (was Re: Windows GTK version conflicts with GObjectIntrospection)
No need to apologize! Anyway, the previously missing polygon is there in Northwestern's snapshot's docs now. Neil ⊥ On 04/10/2014 11:09 AM, Robby Findler wrote: The Northwestern snapshot broke, sorry about that. (The script's call to git submodule update doesn't work for some reason; I've run it manually and we should get a build tomorrow). Robby On Thu, Apr 10, 2014 at 9:57 AM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com wrote: This may have fixed the missing polygons in plots that I reported here for the v6.0 release: http://lists.racket-lang.org/__dev/archive/2013-December/__013797.html http://lists.racket-lang.org/dev/archive/2013-December/013797.html The sphere plot here is fine, whereas I *think* it wasn't before: http://www.cs.utah.edu/plt/__snapshots/current/doc/plot/__intro.html?q=plot#%28part._.__Renderer_and_.Plot_.Bounds%29 http://www.cs.utah.edu/plt/snapshots/current/doc/plot/intro.html?q=plot#%28part._.Renderer_and_.Plot_.Bounds%29 But I really need to see the Northwestern snapshot. Yesterday's is still missing the polygon for that plot. Today's build isn't finished, though. According to previous build logs, it should be by now. Neil ⊥ On 04/10/2014 05:01 AM, Matthew Flatt wrote: I've *finally* upgraded the native Windows and Mac OS X libraries for the drawing stack, including GLib, Cairo, and Pango. I've upgraded the libraries for the development version, but not for the upcoming v6.0.1 release, because I'd like to test the new versions for a cycle before putting them in a release. The Utah snapshot page has builds using the new libraries: http://www.cs.utah.edu/plt/__snapshots/ http://www.cs.utah.edu/plt/snapshots/ I built all the libraries from source this time, instead of taking Windows binaries from www.gtk.org http://www.gtk.org, and so the builds use the same version and configurations for all platforms. For example, the Mac OS X builds now include FreeType. See racket/src/native-libs/__README.txt for more information. In case there are still any Mac OS X PPC users, the minimum supported version of Mac OS X is now 10.5 instead of 10.4. (Version 10.5 was already the minimum version for Intel, for reasons that I can't remember.) At Mon, 14 Oct 2013 21:34:19 -0600, Matthew Flatt wrote: I haven't had a chance to look into this, but it's still on my list. At Sun, 06 Oct 2013 11:48:57 +0400, Roman Klochkov wrote: Can we upgrade GTK version in the next windows bundle? Or at least GLib and GObject. _ Racket Developers list: http://lists.racket-lang.org/__dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/__dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional #:wrap (allocator BIO_free) argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee e45...@uwaterloo.ca wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol-nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: I checked out the patch and have a few questions. (I'm a non-expert.) How come some curves are omitted from the curve/c contract (eg sect163k1 and sect193r2)? Is there also a curve missing from symbol-nid (eg sect571r1)? On Wed, Apr 9, 2014 at 7:52 PM, Neil Van Dyke n...@neilvandyke.org wrote: Edward, your patch sounds OK to me, FWIW. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev diff --git a/racket/collects/openssl/dh4096.pem b/racket/collects/openssl/dh4096.pem new file mode 100644 index 000..1b35ad8 --- /dev/null +++ b/racket/collects/openssl/dh4096.pem @@ -0,0 +1,18 @@ +-BEGIN DH PARAMETERS- +MIICCAKCAgEA+hRyUsFN4VpJ1O8JLcCo/VWr19k3BCgJ4uk+d+KhehjdRqNDNyOQ +l/MOyQNQfWXPeGKmOmIig6Ev/nm6Nf9Z2B1h3R4hExf+zTiHnvVPeRBhjdQi81rt +Xeoh6TNrSBIKIHfUJWBh3va0TxxjQIs6IZOLeVNRLMqzeylWqMf49HsIXqbcokUS +Vt1BkvLdW48j8PPv5DsKRN3tloTxqDJGo9tKvj1Fuk74A+Xda1kNhB7KFlqMyN98 +VETEJ6c7KpfOo30mnK30wqw3S8OtaIR/maYX72tGOno2ehFDkq3pnPtEbD2CScxc +alJC+EL7RPk5c/tgeTvCngvc1KZn92Y//EI7G9tPZtylj2b56sHtMftIoYJ9+ODM +sccD5Piz/rejE3Ome8EOOceUSCYAhXn8b3qvxVI1ddd1pED6FHRhFvLrZxFvBEM9 +ERRMp5QqOaHJkM+Dxv8Cj6MqrCbfC4u+ZErxodzuusgDgvZiLF22uxMZbobFWyte +OvOzKGtwcTqO/1wV5gKkzu1ZVswVUQd5Gg8lJicwqRWyyNRczDDoG9jVDxmogKTH +AaqLulO7R8Ifa1SwF2DteSGVtgWEN8gDpN3RBmmPTDngyF2DHb5qmpnznwtFKdTL +KWbuHn491xNO25CQWMtem80uKw+pTnisBRF/454n1Jnhub144YRBoN8CAQI= +-END DH PARAMETERS- + +These are the 4096 bit DH parameters from Assigned Number for SKIP Protocols +(http://www.skip-vpn.org/spec/numbers.html). +See there for how they were generated. +Note that g is not a generator, but this is not a problem since p is a safe prime. diff --git a/racket/collects/openssl/mzssl.rkt b/racket/collects/openssl/mzssl.rkt index 2f16517..f9d3faf 100644 --- a/racket/collects/openssl/mzssl.rkt +++ b/racket/collects/openssl/mzssl.rkt @@ -34,6 +34,7 @@ TO DO: racket/tcp racket/string racket/lazy-require + racket/runtime-path libcrypto.rkt libssl.rkt) (lazy-require @@ -41,7 +42,15 @@ TO DO: [private/macosx.rkt (load-macosx-keychain)]) (define protocol-symbol/c - (or/c 'sslv2-or-v3 'sslv2 'sslv3 'tls)) + (or/c 'sslv2-or-v3 'sslv2 'sslv3 'tls 'tls11 'tls12)) +(define curves/c + (or/c 'sect163k1 +'sect163r1 'sect163r2 'sect193r1 'sect193r2 +'sect233k1 'sect233r1 'sect239k1 'sect283r1 +'sect283k1 'sect409k1 'sect409r1 'sect571k1 'sect571r1 +'secp160k1 'secp160r1 'secp160r2 'secp192k1 'secp224k1 'secp224r1 +'secp256k1 'secp384r1 'secp521r1 +'prime192v1 'prime256v1)) (define verify-source/c (or/c path-string? @@ -50,6 +59,7 @@ TO DO: (list/c 'macosx-keychain path-string?))) (provide + ssl-dh-param-path (contract-out [ssl-available? boolean?] [ssl-load-fail-reason (or/c #f string?)] @@ -59,6 +69,10 @@ TO DO: (c- ssl-client-context?)] [ssl-make-server-context (-* () (protocol-symbol/c) ssl-server-context?)] + [ssl-server-context-enable-dhe! + (-* (ssl-server-context?) (path-string?) void?)] + [ssl-server-context-enable-ecdhe! + (-* (ssl-server-context?) (curves/c) void?)] [ssl-client-context? (c- any/c boolean?)] [ssl-server-context? @@ -185,6 +199,8 @@ TO DO: (define-cpointer-type _X509*) (define-cpointer-type _ASN1_STRING*) (define-cpointer-type _STACK*) +(define-cpointer-type _DH*) +(define-cpointer-type _EC_KEY*) (define-cstruct _GENERAL_NAME ([type _int] [d _ASN1_STRING*])) (define-ssl SSLv2_client_method (_fun - _SSL_METHOD*)) @@ -195,9 +211,19 @@ TO DO: (define-ssl SSLv23_server_method (_fun - _SSL_METHOD*)) (define-ssl TLSv1_client_method (_fun - _SSL_METHOD*)) (define-ssl TLSv1_server_method (_fun - _SSL_METHOD*)) +(define-ssl TLSv1_1_client_method (_fun - _SSL_METHOD*)) +(define-ssl TLSv1_1_server_method (_fun - _SSL_METHOD*)) +(define-ssl TLSv1_2_client_method (_fun - _SSL_METHOD*)) +(define-ssl TLSv1_2_server_method (_fun - _SSL_METHOD*)) + +(define-crypto DH_free (_fun _DH* - _void) #:wrap (deallocator)) +(define-crypto EC_KEY_free (_fun _EC_KEY* - _void) #:wrap (deallocator)) + +(define-crypto EC_KEY_new_by_curve_name (_fun
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
IIRC, most of the code in openssl/mzssl.rkt predates ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, and that would simplify some of the code that currently uses the local with-failure macro to do deallocation. But no need to fix that in this patch. Some comments on the patch: - Regarding curves/c, the curve NID_* definitions, and symbol-nid: There's some redundancy here that could be eliminated with the following pattern: (define curve-nid-alist '((sect163k1 . 721) )) (define curve/c (apply or/c (map car curve-nid-alist))) (define (curve-nid sym) (cond [(assq sym curve-nid-alist) = cdr] [else (error )])) That eliminates the problem of keeping the enumeration of curves in sync in three places. - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. - There's a missing ! in some of the symbols passed to error in ssl-server-context-enable-dhe!. If you send a new version of the patch I'll commit that; otherwise I can make the changes above myself when I get a chance. Ryan On 04/11/2014 01:46 PM, Edward Lee wrote: Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional #:wrap (allocator BIO_free) argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee e45...@uwaterloo.ca wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol-nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: I checked out the patch and have a few questions. (I'm a non-expert.) How come some curves are omitted from the curve/c contract (eg sect163k1 and sect193r2)? Is there also a curve missing from symbol-nid (eg sect571r1)? On Wed, Apr 9, 2014 at 7:52 PM, Neil Van Dyke n...@neilvandyke.org wrote: Edward, your patch sounds OK to me, FWIW. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Thanks. I will not have time until Monday; if you can wait until then, I will have an updated patch then. --Edward On Fri, Apr 11, 2014 at 06:44:17PM -0400, Ryan Culpepper wrote: IIRC, most of the code in openssl/mzssl.rkt predates ffi/unsafe/alloc. So yes, BIO_new etc should use (allocator _) etc, and that would simplify some of the code that currently uses the local with-failure macro to do deallocation. But no need to fix that in this patch. Some comments on the patch: - Regarding curves/c, the curve NID_* definitions, and symbol-nid: There's some redundancy here that could be eliminated with the following pattern: (define curve-nid-alist '((sect163k1 . 721) )) (define curve/c (apply or/c (map car curve-nid-alist))) (define (curve-nid sym) (cond [(assq sym curve-nid-alist) = cdr] [else (error )])) That eliminates the problem of keeping the enumeration of curves in sync in three places. - SSL_CTRL_SET_ECDH_AUTO is unused; it should be removed. - There's a missing ! in some of the symbols passed to error in ssl-server-context-enable-dhe!. If you send a new version of the patch I'll commit that; otherwise I can make the changes above myself when I get a chance. Ryan On 04/11/2014 01:46 PM, Edward Lee wrote: Thanks for catching the typo. I don't have a good answer to your second question; I really don't know if they should. --Edward On Thu, Apr 10, 2014 at 02:54:36PM -0400, Stephen Chang wrote: Ok thanks. Sorry, I think one more is missing from curve/c (sect283r1)? Another question: Should BIO_new_mem_buf have an additional #:wrap (allocator BIO_free) argument, similar to other allocating functions? More generally, should BIO_new and BIO_free have #:wrap arguments like the other allocating/deallocating functions? On Thu, Apr 10, 2014 at 2:11 PM, Edward Lee e45...@uwaterloo.ca wrote: Those are accidental omissions; I've attached a patch that should fix the contract and symbol-nid. --Edward On Thu, Apr 10, 2014 at 01:39:13AM -0400, Stephen Chang wrote: I checked out the patch and have a few questions. (I'm a non-expert.) How come some curves are omitted from the curve/c contract (eg sect163k1 and sect193r2)? Is there also a curve missing from symbol-nid (eg sect571r1)? On Wed, Apr 9, 2014 at 7:52 PM, Neil Van Dyke n...@neilvandyke.org wrote: Edward, your patch sounds OK to me, FWIW. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
