I sent email about this about a week ago. The attached patch allows
applications to explicitly seed the RNG before first use on Unix, so
that it does not automatically seed itself via RAND_poll().
This is beneficial for three reasons:
1) On some platforms, the Unix RAND_poll()
About year ago, the apps/x509.c has been patched not to ignore -keyform
during -x509toreq operation.
IMHO it's proper time to patch not to ignore other options as well.
All following text is related to openssl req -x509toreq call.
Current behavior:
1. -outform is ignored, PEM format used all
On Sun, 2012-03-04 at 14:16 -0500, Thor Lancelot Simon wrote:
I sent a patch to RT a few hours ago. I didn't get an ack of any kind
and don't see it in the tracker -- any way to tell where it went?
The message-ID was 20120304175840.ga12...@panix.com .
The RT queue is moderated. So you just
On Thu, Mar 1, 2012 at 11:28 PM, Erik Tkal et...@me.com wrote:
So then the question is will this be addressed in 1.0.1 or later?
Probably a bit later.
Bodo
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block to be parsed, it will give header
The DTLS implementation does not lower the assumed MTU after unsuccessful
retransmissions, which results in a failing handshake in case fragmentation is
necessary.
With this patch the MTU is reduced to a safe value of 576 - 20 - 8 for IPv4
and 1280 - 40 - 8 for IPv6, respectively, after 2
Le 05/03/2012 15:14, Stephen Henson via RT a écrit :
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block
Le 05/03/2012 15:14, Stephen Henson via RT a écrit :
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a
Am 5. März 2012 15:14 schrieb Stephen Henson via RT r...@openssl.org:
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00
84 00 00 00 (three zero octets) would be a valid encoding
(context-specific tag 0,
zero length followed by and END OF CONTENTS),
Sorry, this has to read context-specific tag 4 of course.
Best regards,
Martin Bosslet
__
[nick.le...@usa.g4s.com - Mon Sep 12 10:31:50 2011]:
Thank you for looking at the patch and reporting the problem
with it. I apologise that I did not test it properly. The path loop
test in the patch should of course be first whether the issuer is
in the chain and only if it is
Am 5. März 2012 16:45 schrieb Martin Boßlet martin.boss...@googlemail.com:
I'm sorry, but I disagree - this is not a legal encoding, even not at the end
of a constructed indefinite length encoding.
The first 0x00 cannot belong to a multiple length encoding because section
8.1.3.5 of X.690
12 matches
Mail list logo
