Sorry for the late reply.
Checking for chip capabilities by calling an invalid instruction causes an
issue especially when people run debugger with an OpenSSL application.
That can be easily avoided by calling getisax(2) for SPARC, as Dan Anderson
noted.
Please consider determining the chip
Hi Rich,
I just wanted to double check to make sure that SUNOS is the pre-5.X Solaris
version and it doesn't include the currently supported Solaris release (Solaris
8-11.2).
Thank you
-- misaki
Oracle Solaris Security
Senior Software Engineer
- rs...@akamai.com wrote:
Starting with
Thank so much for your comment, Ben.
We are planing to upgrade to the 1.1.0 branch as soon as we can which
is not so easy to do at this moment as we need the FIPS capability.
Thus, we are still focusing on the 1.0.2 release, and haven't had a
chance to work on the 1.1.0 branch. Thus, I won't
Sorry, I meant to say it is for the 1.0.2 branch.
Except in exceptional circumstances, code only ends up in the 1.0.2
branch after having first gotten into the master branch and then the
1.1.0 branch. The current release policy only allows bug fixes to be
backported to the stable branches,
On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
(switching the alias to openssl-dev@openssl.org)
I would like to suggest the following fix so that a valid certificate
at .x can be recognized during the cert validation even when
.0 is linking to a bad/expired certificate. This may
0/21/17 03:21 PM, Viktor Dukhovni wrote:
On Oct 21, 2017, at 11:20 AM, Misaki Miyashita <misaki.miyash...@oracle.com>
wrote:
We encountered a problem using OpenLDAP with OpenSSL when there were more than
one certificate with the same subject.
Does OpenSSL stop searching for a
