On Fri, 2009-08-28 at 10:36 -0400, Steve Marquess wrote:
Steve Marquess wrote:
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used
On Sat, 2009-08-29 at 17:34 -0400, Steve Marquess wrote:
Mark Phalan wrote: ...
Due to the way the FIPS Capable OpenSSL is built it ends up with
older implementations of ciphers (all the ones that fipscanister.o
implements). These cipher implementations are used regardless of
being
On Sun, 2009-08-30 at 09:13 -0700, Kyle Hamilton wrote:
You forgot:
./config fipscanisterbuild asm
Appendix A of the Security Policy (v1.2) lists the allowed command sets.
./config fipscanisterbuild asm isn't one of them.
The asm will be pulled in anyway as for solaris64-x86_64-gcc config
On Thu, 2009-08-27 at 13:39 +0200, Mark Phalan wrote:
...
A consequence of delivering two libcryptos is that one will have the
FIPS_* symbols and the other will not. This makes building applications
which support the FIPS mode problematic if they are to run with both
libcrypto versions
On 09/10/09 11:56 PM, Kurt Roeckx wrote:
On Tue, Sep 01, 2009 at 02:23:38PM +0200, Mark Phalan wrote:
In OpenSolaris we follow an interface stability classification system
which marks interfaces according to how stable they are believed to be.
You can see more information here if interested
On 09/11/09 05:59 PM, Dr. Stephen Henson wrote:
On Fri, Sep 11, 2009, Mark Phalan wrote:
On 09/10/09 11:56 PM, Kurt Roeckx wrote:
I understand this. I'd like to know if 0.9.8l will be ABI/API compat with
0.9.8k - or at least that it is considered a bug if they are not ABI/API
compat. I'm
Hi,
Is there an official policy for contributing code? I looked in the
README but didn't find anything.
Can copyright can be added to modified files or new files be contributed
under a different (but compatible) license?
Thanks,
-Mark
On 7 Oct 2009, at 22:14, David Schwartz wrote:
Can copyright can be added to modified files or new files be
contributed
under a different (but compatible) license?
Thanks,
-Mark
I don't specifically know the policy of the OpenSSL project, but I
strongly
recommend simply adding them
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set the locking callbacks
On 03/26/10 04:44 AM, David Schwartz wrote:
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
That is correct.
This poses a challenge when using OpenSSL
On 03/25/10 02:13 PM, Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe
On 03/26/10 10:47 PM, David Schwartz wrote:
Mark Phalan wrote:
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss - kerberos - pkinit plugin - openssl
It's simply not practical
On 03/29/10 12:54 AM, Thor Lancelot Simon wrote:
On Mon, Mar 29, 2010 at 08:03:29AM +1000, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread
On 03/29/10 07:15 AM, Peter Waltenberg wrote:
The right way to do it is have the app set it up at init time, either
through calling the OpenSSL functions directly or through a module/lib's
'init/setup' API if that's the one 'responsible' for OpenSSL activity in
your application.
Just in case
On 03/29/10 12:03 AM, Peter Waltenberg wrote:
Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread libraries imposed was significant.
I don't think that's an issue
On 29 Mar 2010, at 20:20, David Schwartz dav...@webmaster.com wrote:
Mark Phalan wrote:
I'm just suggesting a compile-time option. The application could
always
set the locking callbacks back to NULL if it knew what it was doing.
-M
I think this fix is actually a bad one.
I'm still
On 03/30/10 09:16 PM, David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races
On 03/31/10 01:14 PM, David Schwartz wrote:
Mark Phalan wrote:
Imagine the above case happening in one thread while another thread
makes a similar seemingly innocuous call with a similar effect (dlopen
a
library which uses OpenSSL). What should pkinit and the second library
which uses OpenSSL
On 03/31/10 01:46 PM, David Schwartz wrote:
Mark Phalan wrote:
Because it fixes the race when libraries are correctly checking to see
if the callbacks are already set before setting their own. It's a one
or
two line change to modify the mis-behaving libraries and new libraries
can take
On Fri, 2010-06-25 at 01:58 +0200, Ger Hobbelt via RT wrote:
The only critical bit here is opinion replacing analysis.
As you said so yourself, and I quote: When both an application and a
library ([...]) both initialize and register their own threading functions,
bad things happen and the
On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote:
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from the application. libraries cannot safely setup the
locking
On Mon, 2010-06-28 at 12:25 +0200, Mark Phalan wrote:
On Fri, 2010-06-25 at 21:43 +0100, Darryl Miles wrote:
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from
On Mon, 2010-06-28 at 07:06 -0700, David Schwartz wrote:
Guess I replied too quickly... I see why you thought I was spreading
misinformation. Of course I agree that every library could be modified
to use atomic instructions available on their CPU to synchronize. Its
just a lot of
I recently hit an issue with 0.9.8p due to OPENSSL_VERSION_NUMBER being
of the form
0xn
instead of what the code expected:
0xnL
This happened to cause a warning and hence a build failure. The code in
question basically did something like this:
#include stdio.h
#include
I recently hit an issue with 0.9.8p due to OPENSSL_VERSION_NUMBER being
of the form
0xn
instead of what the code expected:
0xnL
This happened to cause a warning and hence a build failure. The code in
question basically did something like this:
#include stdio.h
#include
I'm away. I'll be back on Monday the 18th of July. For anything urgent please
contact my manager - Anup Sekhar (anup.sek...@oracle.com).
__
OpenSSL Project http://www.openssl.org
Development
I'm away. I'll be back on Monday the 18th of July. For anything urgent please
contact my manager - Anup Sekhar (anup.sek...@oracle.com).
__
OpenSSL Project http://www.openssl.org
Development
This was found in a code sweep associated with the OpenSolaris bug:
6346809 S_IFxxx is not a bitmask but our programmers don't know
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6346809)
The issue is there are a few places where OpenSSL uses the st_mode field
of struct stat as a
Find attached a couple of fixes for hmac.pod and pem.pod. The patches
simply update the Name sections of the relevant pod file so that man
pages are properly generated for the PEM_* and HMAC_* routines. The
patches were generated against 0.9.8a but also apply to 0.9.8k.
Thanks,
-Mark
diff -ruN
Report is relevant for 0.9.8n, 1.0.0 appears to have similar problems
but hasn't been tested.
In crypto/objects/o_names.c the following globals are used without locking:
names_lh
names_type_num
name_funcs_stack
similarily in crypto/evp/evp_pbe.c
pbe_algs
The result of this is that API calls
OpenSSL_add_all_algorithms() isn't very suitable for library use. As a
library using OpenSSL doesn't know whether OpenSSL_add_all_algorithms()
has been called it must call it itself. As multiple independent
libraries may be using OpenSSL in a similar way
OpenSSL_add_all_algorithms() (and
Re-sending to RT...
I recently hit an issue with 0.9.8p due to OPENSSL_VERSION_NUMBER being
of the form
0xn
instead of what the code expected:
0xnL
This happened to cause a warning and hence a build failure. The code in
question basically did something like this:
#include
32 matches
Mail list logo
