Confirmed. This one compiles without a warning.
Thanks -- Matthias Kraft
-Ursprüngliche Nachricht-
Von: Kurt Roeckx via RT [mailto:r...@openssl.org]
Gesendet: Freitag, 7. November 2014 21:55
An: Kraft, Matthias
Cc: openssl-dev@openssl.org
Betreff: Re: [openssl.org #3593] [BUG] 0.9.8 head
There seems to be great confusion on which method to use set up a
TLS/SSL connection and I guess most of that has to do with
history. I would like to simplify things.
We currently seem to have methods for SSLv2, SSLv3, TLSv1
documented, and TLSv1_1 and TLSv1_2 undocumented, and then a
SSLv23
On Po, 2014-11-10 at 13:38 +0100, Kurt Roeckx wrote:
There seems to be great confusion on which method to use set up a
TLS/SSL connection and I guess most of that has to do with
history. I would like to simplify things.
We currently seem to have methods for SSLv2, SSLv3, TLSv1
documented,
On 10/11/14 12:38, Kurt Roeckx wrote:
I would also like to get rid of SSL_OP_NO_SSLv2 and instead have a
way to specify the minimum and maximum supported version by those
methods, because that's really what people want to do as far as I
know.
The default should assume the maximum supported
On Mon, Nov 10, 2014 at 02:02:35PM +0100, Tomas Mraz wrote:
I'd recommend doing all this but with such correction that the new
result will not break API/ABI backwards compatibility to OpenSSL 1.0.x
so it can be applied in some future 1.0.x branch.
Basically things should not be removed but
Does this look like a good idea?
Yes, very. I think the min/max versions should be two explicit parameters,
where '0' means the highest(lowest) supported by the library.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
Improved version of the patch...
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
From
Attached is promised patch that reworks
interworking logic. As mentioned earlier idea is to use __ARM_ARCH__=5
|| !defined(__thumb__). Rationale is that load to pc does interworking
since ARMv5, but without __thumb__ it does what we need even on ARMv4.
OK, this appears to build and run
On 8 November 2014 17:56, Andy Polyakov ap...@openssl.org wrote:
arm-linux-gnueabi-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp
-I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=8 -DTERMIO -O3 -Wall
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
Attached is promised patch that reworks
interworking logic. As mentioned earlier idea is to use __ARM_ARCH__=5
|| !defined(__thumb__). Rationale is that load to pc does interworking
since ARMv5, but without __thumb__ it does what we need even on ARMv4.
OK, this appears to build and run fine
Hello,
Our UC-KLEE tool found a free of a garbage pointer in the latest OpenSSL (and
LibreSSL) that would cause either a segfault or heap corruption depending on
the pre-existing heap contents.
The bug occurs in ec_wNAF_mul (crypto/ec/ec_mult.c). If the allocation of wNAF
on line 448 succeeds
Well, it probably should be noted that Thumb code with non-Thumb shared
library on ARMv4 takes special compiler. At least stock gcc doesn't
generate those magic epilogues with moveq pc,lr, but simply issues
target CPU does not support interworking warning. And passing
-march=armv4t simply
(for some reason it was never received by rt@, so resending here)
Advance to the next state variant when reusing messages.
Previously, state variant was not advanced, which resulted in state
being stuck in the st1 variant (usually _A).
This broke certificate callback retry logic when accepting
Current git OpenSSL_1_0_2-stable branch (39679d858) has errors related to
hostname-, IP- and email-verification options.
openssl s_client -help lists following options:
-checkhost host - check peer certificate matches host
-checkemail email - check peer certificate matches email
-checkip
Advance to the next state variant when reusing messages.
Previously, state variant was not advanced, which resulted in state
being stuck in the st1 variant (usually _A).
This broke certificate callback retry logic when accepting connections
that were using SSLv2 ClientHello (hence reusing the
On 10 November 2014 17:12, Andy Polyakov ap...@openssl.org wrote:
Attached is promised patch that reworks
interworking logic. As mentioned earlier idea is to use __ARM_ARCH__=5
|| !defined(__thumb__). Rationale is that load to pc does interworking
since ARMv5, but without __thumb__ it does
On Mon, Nov 10, 2014, Piotr Sikora wrote:
(for some reason it was never received by rt@, so resending here)
Slipped through the moderation queue, sorry. It is in RT now.
Best regards,
Lutz
--
Lutz Jaenicke jaeni...@openssl.org
OpenSSL Project
17 matches
Mail list logo
