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
10 matches
Mail list logo
