I've committed your patch and the changes I suggested earlier, plus docs
and tests. Thanks for the patch, and for the reminder!
Ryan
On 04/11/2014 09:30 PM, Edward Lee wrote:
Thanks. I will not have time until Monday; if you can wait
until then, I will have an updated patch then.
--Edward
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
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 pat
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 BI
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 alloc
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
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 wrote:
> Edward, your patc
Edward, your patch sounds OK to me, FWIW.
Neil V.
_
Racket Developers list:
http://lists.racket-lang.org/dev
My patch does not include any C code; I have not audited any existing
OpenSSL code, but to the best of my knowledge, OpenSSL + (EC)DHE is
commonly used across webservers today.
To answer your second point, the
perfect forward secrecy extensions are disabled by default, and
must be explicitly enabl
* Is anyone up to auditing the C code? To support my earlier concern
("http://lists.racket-lang.org/dev/archive/2014-February/013935.html";),
you've probably heard in the last few days about a C oops bug in OpenSSL
that has compromised the private keys of 2/3 of the Internet for over a
year no
I previously submitted this patch in late January; I've not received any
progress updates with regards to this patch recently - did this patch
get lost between then and now?
This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings.
This patch has been tested on Ubuntu 12.04 (and appear
11 matches
Mail list logo
