Re: [openssl-dev] Ubsec and Chil engines

All, I toyed over the weekend with resurrecting CHIL: intermediate result here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT PROUD OF THIS but have no cycles to clean it up for at least a couple of days to come. It builds now but doesn't work: my privkey loading routine

Re: [openssl-dev] Ubsec and Chil engines

> On Feb 19, 2016, at 3:31 AM, Matt Caswell wrote: OK that made our support lines blow up so yes there is interest. Disclaimer: I work for Thales but do not speak for Thales. > So it seems that for chil there may possibly be some rare use (but even > the most recent evidence

Re: [PATCH] Issue with repeatedly loading CHIL engine

On May 26, 2010, at 9:19 AM, Dr. Stephen Henson wrote: I've committed a fix for this now. I took the opportunity to get rid of the ex_data free function at the same time. Let me know if that works OK. Either check the next snapshot or apply this patch:

Re: [PATCH] Issue with repeatedly loading CHIL engine

On May 21, 2010, at 5:58 PM, Dr. Stephen Henson wrote: On Fri, May 21, 2010, Sander Temme wrote: .. What would be best? Unfortunately there is no way to do this with the existing ex_data API and we'd rather avoid extending APIs in the stable branches if possible. My suggestion

Issue with repeatedly loading CHIL engine

Folks, I have been working for several days to track down an issue where Apache segfault on startup, most of the time, but ONLY on Red Hat and ONLY when the CHIL engine is enabled. I'm working with OpenSSL, Apache and APR HEAD on an up-to-date CentOS 5.4 32bits. The segfault occurs when

Re: Stability of Beta 5 of OpenSSL 1.0.0

On Jan 29, 2010, at 9:05 AM, Suryya Kumar Jana wrote: Would any one let me know some feedback on stability of Beta 5 of OpenSSL 1.0.0? Just follow the list, and see what folks post. Also, what is your own experience? S. -- san...@temme.net http://www.temme.net/sander/ PGP

Re: OpenSSL 1.0.0 beta5 release

On Jan 20, 2010, at 7:37 AM, OpenSSL wrote: Please download and test them as soon as possible. This new OpenSSL version incorporates 122 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Darwin legadema.sandla.org 10.2.0

Re: OpenSSL 1.0.0 beta3 release

On Jul 15, 2009, at 11:44 PM, Michael Tüxen wrote: Shouldn't DSO_ext be 6 if OPENSSL_SYS_MACOSX is defined? Totally. I spaced on that, but see in the commit messages that Dr. Henson caught it. S. Best regards Michael On Jul 16, 2009, at 7:42 AM, Sander Temme wrote: On Jul 15, 2009

Re: OpenSSL 1.0.0 beta3 release

On Jul 15, 2009, at 4:57 AM, Dr. Stephen Henson wrote: Please download and test them as soon as possible. This new OpenSSL Mac OS X 10.5.7 on Intel. ./Configure --prefix=/UserData/asf/openssl-1.0.0b3 shared threads zlib- dynamic darwin64-x86_64-cc Builds fine, but tests fail on

Re: OpenSSL 1.0.0 beta3 release

On Jul 15, 2009, at 11:07 AM, Dr. Stephen Henson wrote: Try the next snapshot or this patch: http://cvs.openssl.org/chngview?cn=18416 Thanks for the report, That does the trick with a little further massaging. Revised patch: [scte...@legadema] tmp $ diff -u

Re: [PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

On Nov 11, 2008, at 12:28 AM, Sander Temme wrote: On Nov 2, 2008, at 9:19 AM, Sander Temme wrote: The following compiles and tests cleanly on trunk and on the latest snapshot of 0.9.8-stable (with offset 1 in e_chil.c). Also attached to prevent line wrap: Ping? Any chance to squeeze

Re: [PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

On Nov 2, 2008, at 9:19 AM, Sander Temme wrote: The following compiles and tests cleanly on trunk and on the latest snapshot of 0.9.8-stable (with offset 1 in e_chil.c). Also attached to prevent line wrap: Ping? Thanks, S. Index: engines/e_chil.c

Re: [PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

On Oct 29, 2008, at 8:33 AM, Geoff Thorpe wrote: Same patch, applies clean to trunk and to 0.9.8-stable. I actually took it against trunk. Doesn't seem to be touched by make update, unless I'm missing something. It didn't remove the error string? Can you please try removing it manually and

Re: [PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

On Oct 27, 2008, at 8:20 AM, Geoff Thorpe wrote: Well, FWIW, I will ACK the patch. And if nobody gets round to putting it in (and doing any other admin that goes with it, like regenerating the error definitions which probably change as a consequence of this, etc), then I'll try to do this

Re: [PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

On Oct 20, 2008, at 11:21 AM, Sander Temme via RT wrote: Dear OpenSSL developers, I would like to propose the following patch to engines/e_chil.c: -- Polite nag -- I have been trying to raise this topic, on the list and through RT, since August. I have had no reaction from any

Re: openssl-devel build package

On Oct 24, 2008, at 7:15 PM, Kovalenko, Michael wrote: Could you point me to the right URL? yum install openssl-devel? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic

[PATCH] keep CHIL engine from breaking in non-threaded situations [openssl.org #1736]

Dear OpenSSL developers, I would like to propose the following patch to engines/e_chil.c: Index: engines/e_chil.c === RCS file: /home/openssl/cvs/openssl/engines/e_chil.c,v retrieving revision 1.5 diff -u -r1.5 e_chil.c ---

[PATCH] Ignore build products on Mac and fix ./config warning

Dear OpenSSL developers, The following patch fixes the warning emitted by ./config on the Apple platform to include the correct invocation for a 64bits build. It also ignores the built libraries, which on this platform have a '.dylib' suffix: Index: .cvsignore

Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

On Sep 11, 2008, at 7:04 AM, [EMAIL PROTECTED] via RT wrote: On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote: 2) Have the engine provide its own callbacks that get set in case the application does not provide (presumably more suitable) alternatives: I think it would

Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

On Sep 11, 2008, at 7:04 AM, [EMAIL PROTECTED] via RT wrote: On Fri, Aug 29, 2008 at 08:45:12AM +0200, Sander Temme via RT wrote: 2) Have the engine provide its own callbacks that get set in case the application does not provide (presumably more suitable) alternatives: I think it would

Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

Hi Peter, On Sep 11, 2008, at 2:48 PM, Peter Waltenberg wrote: You need to be really careful here. Simply being dependent on pthreads and linking to non-threaded code is pure poison on some OS's. (HP/UX variants come to mind). I agree. These are systems I personally have no exposure

Re: [openssl.org #1736] Enhancement Request: do away with error in chil engine in absence of dynamic locks

On Aug 29, 2008, at 2:15 AM, Kyle Hamilton wrote: Option 2 works iff pthreads exists. Yes, and The Book has some code for Windows that I didn't copy. If some form of threading is not available, neither the error nor the fallbacks need to be there. We can wrap both in #ifdef

Suggestion: do away with error in chil engine in absence of dynamic locks

Dear OpenSSL development community, In engines/e_chil.c around line 594, the engine checks if it has mutex callbacks to work with and, if not, errors out with the message: You HAVE to add dynamic locking callbacks via CRYPTO_set_dynlock_{create,lock,destroy}_callback() There used to be a

Re: Any Apache/mod_ssl developers out there?

appropriate place for mod_ssl development discussion or any reference to the work of adding EC cryptography to mod_ssl. Development of mod_ssl is discussed on the [EMAIL PROTECTED] mailinglist. S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF