--On Thursday, August 25, 2016 12:36 AM + Viktor Dukhovni
wrote:
On Wed, Aug 24, 2016 at 11:17:21PM +, Quanah Gibson-Mount via RT
wrote:
When a process (nginx in this case) has this as the server cert, it core
dumps with an abort() when clients request the cert:
You say the server
On Wed, Aug 24, 2016 at 11:17:21PM +, Quanah Gibson-Mount via RT wrote:
> When a process (nginx in this case) has this as the server cert, it core
> dumps with an abort() when clients request the cert:
You say the server dumps core, and yet:
> #1 0x7f22ba125ce8 in __GI_abort () at abor
A customer of ours has a server cert where the CSR was generated with
1.0.2h but was signed with 1.0.0j.
When a process (nginx in this case) has this as the server cert, it core
dumps with an abort() when clients request the cert:
[root@zre-ldap005 q]# gdb /opt/zimbra/common/sbin/nginx
core-ng
> I use PEM_read_bio_RSAPrivateKey to read a key into a RSA and all return-
> values are ok.
That's the first and most important test. One other thing you can do is use
the "rsa" tool to print out the contents.
> But I get a crashes when I use it afterwards.
The code you posted isn't what you
Well, ok.
What is the best way to check a RSA-object is well initialized?
I use PEM_read_bio_RSAPrivateKey to read a key into a RSA and all
return-values are ok.
But I get a crashes when I use it afterwards.
Thanks,
Chris
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/ma
You didn't fully initialize your RSA key, such as by adding the private or
public parts.
It shouldn't crash, but then again this is like doing an fprintf() without
first checking if the fopen() succeeded.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
--
op
Hi!
I am looking for a problem with some PEM_key.
But on the way I found some behavior I think is strange.
Here is a small piece of code.
--
#include
#include
#include
// OpenSSL 1.0.1t 3 May 2016
// gcc version 4.9.2 (Debian 4.9.2-10)
// g++ x.c
This has now been merged into the master branch, and will be part of version
1.1.0.
Cheers,
Richard ( closing ticket )
On Wed Aug 24 11:32:54 2016, levitte wrote:
> After much internal deliberation, we ended up checking __GNUC__ rather
> than
> dissing __SUBPRO_C. Our hope is that a compiler that
After much internal deliberation, we ended up checking __GNUC__ rather than
dissing __SUBPRO_C. Our hope is that a compiler that implements GNU extensions
will also define __GNUC__. Our checks of the Intel compiler (which someone
referred to) does so, for example (if I understood correctly).
https
Fixed in master by e3057a57c and c74aea8d6. Still needs cherry-picking to
1.0.2.
Matt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4636
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
Fixed in master by b62b2454f and dfde4219f. Still needs cherry-picking to
1.0.2.
Matt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4621
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
On Thu Aug 11 17:12:10 2016, appro wrote:
> Hi,
>
> > I have no time to check with debugger now,
>
> Then no progress will be made. Problem needs to be identified first, and
> since similar problem was identified earlier, I'd have to insist on
> confirmation whether or not it's the same.
>
> > but
Resolved by overlapping buffer checks. Closing.
Matt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Mon Aug 22 15:05:17 2016, david...@google.com wrote:
> I may not have time to fully digest the change before the release date, but
> I'm not sure this snippet quite works:
>
> if (ctx->read_start == ctx->read_end) { /* time to read more data */
> ctx->read_end = ctx->read_start = &(ctx->buf[BUF_
14 matches
Mail list logo
