[openssl-dev] Fwd: [TLS] Update on TLS 1.3 Middlebox Issues

An update on the TLS1.3 middlebox issue posted to the TLS WG list which may be of interest to the openssl-dev group. Matt Forwarded Message Subject:[TLS] Update on TLS 1.3 Middlebox Issues Date: Fri, 6 Oct 2017 13:16:37 -0700 From: Eric Rescorla To:

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

All my builds include "make distclean" at the start of the process. However when I repeated that cleanup and re-run the build, 1_1_0-stable error disappeared. A fluke?! Regards, Uri Sent from my iPhone > On Sep 1, 2017, at 21:10, Blumenthal, Uri - 0553 - MITLL > wrote: > >

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

On Sep 1, 2017, at 18:48, Matt Caswell wrote: >>> *Subject:* *openssl 1-1-0-stable fails* >>> >>> OpenSSL_1_1_0-stable current Github >>> >>> Test Summary Report >>> --- >>> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1) >>> Failed

Re: [openssl-dev] Fwd: openssl 1-1-0-stable fails

On 01/09/17 23:42, Blumenthal, Uri - 0553 - MITLL wrote: > > > Begin forwarded > >> *Subject:* *openssl 1-1-0-stable fails* >> >> OpenSSL_1_1_0-stable current Github >> >> Test Summary Report >> --- >> ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1)

[openssl-dev] Fwd: openssl 1-1-0-stable fails

Begin forwarded > Subject: openssl 1-1-0-stable fails > > OpenSSL_1_1_0-stable current Github > > Test Summary Report > --- > ../test/recipes/80-test_cms.t(Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=95, Tests=561, 165

Re: [openssl-dev] Fwd: openssl-fips build on cygwin 64bit

On Thu, Jul 20, 2017, Cristi Fati wrote: > Apologies for spam, if this isn't the right place: > > > *Details*: > >- *cygwin* *64bit* running on *Win10* (*CYGWIN_NT-10.0 cfati-e5550-0 >2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin*) >- *openssl-1.0.2l* - irrelevant >-

[openssl-dev] Fwd: openssl-fips build on cygwin 64bit

Apologies for spam, if this isn't the right place: *Details*: - *cygwin* *64bit* running on *Win10* (*CYGWIN_NT-10.0 cfati-e5550-0 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin*) - *openssl-1.0.2l* - irrelevant - *openssl-fips-2.0.16* - can be reproduced with previous versions

[openssl-dev] Fwd: Code Health Tuesday - old issues

Just a reminder about our code health Tuesday event this week. Please see the details below. Matt Forwarded Message Subject: Code Health Tuesday - old issues Date: Thu, 27 Apr 2017 08:43:18 +0100 From: Matt Caswell To: openssl-dev@openssl.org

[openssl-dev] Fwd: [openssl-announce] Forthcoming OpenSSL releases

In case anyone on these lists missed this on the openssl-announce list: Forwarded Message Subject: [openssl-announce] Forthcoming OpenSSL releases Date: Mon, 23 Jan 2017 21:08:50 + (GMT) From: OpenSSL Reply-To: openssl-us...@openssl.org To:

Re: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

No, thanks, that looks good! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

Hi Rich, >> Just go ahead a file a pull request anyway...that's the best way of getting >> comments. If changes are needed you can update the PR as required. > > Like, for example, documenting this new function. :) Sure, I did mention it alongside its get0 counterpart in

Re: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

> Just go ahead a file a pull request anyway...that's the best way of getting > comments. If changes are needed you can update the PR as required. Like, for example, documenting this new function. :) -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

Hi Matt, thanks for your quick reply. >> Please also see my commit >> https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba >> implementing this. Looking forward to some comments -- if you are OK >> with it I would be happy to file a pull request. My CLA has been

Re: [openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

On 08/11/16 12:41, Sascha Steinbiss wrote: > Dear OpenSSL developer team, > > following up on the discussion quoted below on the openssl-users ML I > would like to ask your opinions on adding a OCSP_resp_get1_id() function: > > int OCSP_resp_get1_id(const OCSP_BASICRESP *bs, >

[openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

Dear OpenSSL developer team, following up on the discussion quoted below on the openssl-users ML I would like to ask your opinions on adding a OCSP_resp_get1_id() function: int OCSP_resp_get1_id(const OCSP_BASICRESP *bs, ASN1_OCTET_STRING **pid,

[openssl-dev] [openssl.org #4689] Fwd: Bug in OpenSSL 1.0.2j ssl_accept

In addition to my message I send you my gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x71413700 (LWP 13663)] 0x76ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 (gdb) backtrace #0 0x76ba4e87 in sk_value () from

[openssl-dev] [openssl.org #4637] Fwd: Missing accessor - DSA key length

Added now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4637 Please log in as guest with password guest if prompted --

[openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

Fix for this was merged as 4a9a0d9bcb. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4638 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4638] Fwd: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src);

-- Forwarded message -- From: Richard Moore Date: 24 July 2016 at 17:38 Subject: Missing const EC_KEY *EC_KEY_dup(EC_KEY *src); To: openssl-dev@openssl.org Shouldn't this be EC_KEY *EC_KEY_dup(const EC_KEY *src); Cheers Rich. -- Ticket here:

[openssl-dev] [openssl.org #4637] Fwd: Missing accessor - DSA key length

-- Forwarded message -- From: Richard Moore Date: 24 July 2016 at 17:31 Subject: Missing accessor - DSA key length To: openssl-dev@openssl.org For RSA we have RSA_bits(), for DH we have DH_bits() for DSA we seem to only have DSA_size(). Cheers Rich. --

Re: [openssl-dev] [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors

On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote: > Hi Richard, Mattias, others, > > I agree with you that it would be nice if OpenSSL could figure out > itself whether a cert needs to be treated as a proxy, but currently that > doesn't work reliably as far as I know. > The flag is

[openssl-dev] Fwd: [openssl.org #4615] Cache utility behaving strange with X509_LOOKUP_add_dir

It will be very helpful if you could provide your inputs on this as soon as possible so that I can move ahead quickly. Regards, Anirudh -- Forwarded message -- From: The default queue via RT Date: Thu, Jul 14, 2016 at 4:55 PM Subject: [openssl.org #4615]

[openssl-dev] Bug#829272: Info received (Fwd: [openssl.org #4602] Missing accessors)

Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will

[openssl-dev] [openssl.org #2146] [Fwd: Re: unexpected message during renegotiate attempt]

This issue has been discussed a number of times, but will not be fixed at this time. Closing Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2146 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur

Fixed differently in d20bb611d. Closing. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4262 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1875] Fwd: [PATCH] Small bug fixes and coding style corrections

These patches no longer apply and are no longer relevant. Closing Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1875 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Fwd: Building Openssl for Universal Windows Platform

Hi, I'm trying to build Openssl as a static library and use it in my projects. Have you guys put any thought to port the Openssl library to UWP(Universal Windows 10 Platform)? Can you provide me any guidelines or useful information that i can use to port the libraries unless ported already? Any

Re: [openssl-dev] Fwd: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04

>>> /bin/as: Execution >>> of /bin/compat-as/as failed with error code 0 > > You're trying to cross compile? What is th target? > > How did you call Configure? On related note, similar problem was reported earlier, see for example

Re: [openssl-dev] Fwd: Assembly code errors while building openssl-1.0.2f on Ubuntu 14.04

On Wed, Feb 24, 2016 at 09:09:49AM -0800, Datta Prabhu Maddikunta wrote: > > /bin/as: Execution > > of /bin/compat-as/as failed with error code 0 You're trying to cross compile? What is th target? How did you call Configure? Kurt -- openssl-dev mailing list To unsubscribe:

[openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability

Hello, I am using OpenSSL 1.0.1i 6 Aug 2014 version... Following is my understanding of the issue: This is an implementation specific issue and there is no general patch available. The vulnerability depends on how the padding bytes in TLS data are handled in CBC mode and is more specific to TLS

Re: [openssl-dev] Fwd: CVE-2014-8730 TLS CBC Incorrect Padding Abuse Vulnerability

On Wed, Feb 03, 2016 at 05:11:34PM +0530, Shyamal Bhowmik wrote: > > /* enc_err is: > * 0: (in non-constant time) if the record is publically invalid. > * 1: if the padding is valid > * -1: if the padding is invalid */ > if (enc_err == 0) > { >

[openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

Hi guys, Any place where this API change is documented ? It would be nice if each release came with a list of API changes. -- Forwarded message -- From: Gilles Chehade Date: Mon, Feb 1, 2016 at 8:10 PM Subject: latest OpenSSL causes OpenSMTPD to segv To:

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

> This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd > to crash as soon as the RSA engine is used (ie: whenever there's crypto) It would be interesting to see what they think was wrong. Our intent is to NOT change API's across letter releases.

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

In message <20160201231650.gf4...@mournblade.imrryr.org> on Mon, 1 Feb 2016 23:16:50 +, Viktor Dukhovni said: openssl-users> On Mon, Feb 01, 2016 at 10:52:56PM +, Viktor Dukhovni wrote: openssl-users> openssl-users> > The only thing I see that's plausibly

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

On Mon, Feb 01, 2016 at 08:56:16PM +, Salz, Rich wrote: > > This impact all users who upgrade to OpenSSL 1.0.2f and will cause smtpd > > to crash as soon as the RSA engine is used (ie: whenever there's crypto) > > It would be interesting to see what they think was wrong. > > Our intent is to

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

On Mon, Feb 01, 2016 at 10:52:56PM +, Viktor Dukhovni wrote: > The only thing I see that's plausibly pertinent is: > > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 > Author: Dr. Stephen Henson > Date: Sun Dec 20 18:18:43 2015 + > > Don't check

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

On Mon, Feb 01, 2016 at 11:16:50PM +, Viktor Dukhovni wrote: > On Mon, Feb 01, 2016 at 10:52:56PM +, Viktor Dukhovni wrote: > > > The only thing I see that's plausibly pertinent is: > > > > commit 6656ba7152dfe4bba865e327dd362ea08544aa80 > > Author: Dr. Stephen Henson

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

In message <20160202.003940.2270696010208807774.levi...@openssl.org> on Tue, 02 Feb 2016 00:39:40 +0100 (CET), Richard Levitte said: levitte> In message <20160201231650.gf4...@mournblade.imrryr.org> on Mon, 1 Feb 2016 23:16:50 +, Viktor Dukhovni

Re: [openssl-dev] Fwd: latest OpenSSL causes OpenSMTPD to segv

> > It would be interesting to see what they think was wrong. > > > > Our intent is to NOT change API's across letter releases. > > The only thing I see that's plausibly pertinent is: Which hardly counts as an API change, does it? I wonder if we'll see what they found, or an apology?

[openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur

Hello, When ./config is run, the Configure script always complains about 'make depend’ needing to be run because the $default_depflags and $depflags do not match. Recent changes to Configure automatically create $default_depflags, but takes special exceptions for shared, zip, hw and asm, which

Re: [openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur

Added pull request: https://github.com/openssl/openssl/pull/578 -- -Todd Short // tsh...@akamai.com // "One if by land, two if by sea, three if by the Internet." On Jan 21, 2016, at 4:11 PM, Short, Todd via RT > wrote: Hello,

[openssl-dev] [openssl.org #4199] Fwd: OpenSSL build for 64-bit Cygwin using "config" script

I sent the following report/fix to apa...@apache.org (following the comment in the script being patched) and got a response indicating I probably should have sent it to r...@openssl.org. I was attempting to do a build of OpenSSL 1.0.2e under 64-bit Cygwin. The attachment is a context diff for

[openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon !

>> We have no plans to do this. May be will put it into your plans ? > Doubtful. We have lots of other work to do. Writing a full-strength database-backed OCSP responder is outside of our interests. Ok. In such situation, can you add ability of using multiple -CA, -rkey, -rsigner parameters of

Re: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon !

Ø Ok. In such situation, can you add ability of using multiple -CA, -rkey, -rsigner parameters of trinity, at least ? Perhjaps someone will contribute a patch? ___ openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 17/11/15 00:01, Viktor Dukhovni wrote: > On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote: > >> Disabling algorithms isn't the right answer IMO. I do like the idea of a >> "liblegacycrypto". That way people that only have need of current >> up-to-date crypto can stick with the

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Mon, Nov 16, 2015 at 9:06 PM, Peter Waltenberg wrote: > Why not offer another set of get_XYZ_byname() which resticts the caller to > socially acceptable algorithms. Or allows the opposite, it really doesn't > matter but restricted being the newer API breaks less code by

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

stralia From: Jeffrey Walton <noloa...@gmail.com> To: OpenSSL Developer ML <openssl-dev@openssl.org> Date: 17/11/2015 20:23 Subject: Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete cryp

Re: [openssl-dev] [EXTERNAL] Re: Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Tue, 2015-11-17 at 00:01 +, Viktor Dukhovni wrote: On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote: Disabling algorithms isn't the right answer IMO. I do like the idea of a "liblegacycrypto". That way people that only have need of current up-to-date crypto can stick with

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Huge +1. I find Viktor’s arguments more than convincing - irrefutable. As for “weakening the library”, I don’t find this argument correct. It is not about libssl - it’s about libcrypto. Quite a different animal. -- Regards, Uri Blumenthal On 11/16/15, 18:23 , "openssl-dev on behalf of Matt

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote: > Disabling algorithms isn't the right answer IMO. I do like the idea of a > "liblegacycrypto". That way people that only have need of current > up-to-date crypto can stick with the main library. Others who need the > older crypto can

[openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Meant to send this to openssl-dev not openssl-users so resending... On 16/11/15 15:51, Emilia Käsper wrote: > Thanks all for your feedback! > > I asked for mainstream use-cases for algorithms whose removal could > cause widespread pain. Some individual users, undoubtedly, will be hit > by this,

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

. Peter From: Viktor Dukhovni <openssl-us...@dukhovni.org> To: openssl-dev@openssl.org Date: 17/11/2015 10:02 Subject:Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Sent by:"openssl-dev" &

[openssl-dev] Fwd: [openssl-users] How to get list of TLS protocols supported by OpenSSL?

Hi guys, I recently confirmed, from the openssl-users mailing list, that there's no suitable API call to determine what TLS versions a given compiled copy of the OpenSSL library is capable of. This would be a functionality that would be useful to a lot of real-world users. I was thinking of

Re: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

Why are you running on such an old OS? How old are your Windows and Linux systems? Certainly not of the same generation. Solaris 8 & 9 are no longer supported, so you can't get security patches or anything. I highly recommend you try at least S10, or better, yet - S11. the /dev/[u]random on

[openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

-- Forwarded message -- From: Tom Kacvinsky Date: Tue, Nov 10, 2015 at 5:51 PM Subject: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode To: openssl-us...@openssl.org I have an interesting case

Re: [openssl-dev] Fwd: Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode

Hi Valerie, On Fri, Nov 13, 2015 at 4:06 PM, Valerie Fenwick wrote: > Why are you running on such an old OS? How old are your Windows and Linux > systems? Certainly not of the same generation. > > We still support S8 because some of our very important customers

[openssl-dev] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest

Hi OpenSSL Community, I originally posted this message on the security area ML at IETF and I am trying to reach out to a broad audience of experts, implementers, and vendors. I would love to have contributions and implementations (once we have some initial specs) around this initiative. I am

[openssl-dev] Fwd: [openssl.org #4095] X509_STORE_get_by_subject crash

Hi, Can you please help me in below query Thanks & regards, Tosif -- Forwarded message -- From: tosif tamboli Date: Fri, Oct 16, 2015 at 3:26 PM Subject: Re: [openssl.org #4095] X509_STORE_get_by_subject crash To: r...@openssl.org My application is written

[openssl-dev] [openssl.org #4092] Fwd: Memory Leak in X509_STORE_CTX_init

Hi, Valgrind Reported Leak = ==16773== 56 bytes in 1 blocks are definitely lost in loss record 806 of 1,182 ==16773==at 0x4A07F9E: malloc (vg_replace_malloc.c:291) ==16773==by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0) ==16773==by

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Dear Andy, On Mon, May 25, 2015 at 5:26 PM, Andy Polyakov via RT r...@openssl.org wrote: ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0' What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on your system? $ gcc -Wa,-v -c -o

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Dear Andy, On Mon, May 25, 2015 at 5:26 PM, Andy Polyakov via RT r...@openssl.org wrote: ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0' What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on your system? $ gcc -Wa,-v -c -o

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Hi, I got a problem building openssl 1.0.2a on SUSE. Platform: uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler: gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Dear Andy, On Mon, May 25, 2015 at 2:23 PM, Andy Polyakov via RT r...@openssl.org wrote: Hi, I got a problem building openssl 1.0.2a on SUSE. Platform: uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler:

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Dear Andy, On Mon, May 25, 2015 at 2:23 PM, Andy Polyakov via RT r...@openssl.org wrote: Hi, I got a problem building openssl 1.0.2a on SUSE. Platform: uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler:

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0' What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on your system? $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using

[openssl-dev] [openssl.org #448] [Fwd: Bug#176062: openssl: Expired certificates and recertification]

It's been years and years and time to face facts: not going to happen unless someone sends a patch. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl]

After ten years, the answer is no we are not supporting this now. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #844] [Fwd: Bug#235600: openssl: CA.pl and -signcert: some minor issues]

We rewrote CA.pl.in for 1.1; see the master branch. If there are still issues, please open a new ticket. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl]

On Sat, 2015-05-02 at 16:19 +0200, Rich Salz via RT wrote: After ten years, the answer is no we are not supporting this now. We really ought to fix PKCS#11 support though, to make it a first class citizen. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature

Re: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl]

On Sat, 2015-05-02 at 16:19 +0200, Rich Salz via RT wrote: After ten years, the answer is no we are not supporting this now. We really ought to fix PKCS#11 support though, to make it a first class citizen. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature

[openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl]

re-closing. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report)

Hi Matt, Thanks for the reply on this, and for backporting the fix to 1.0.2! Having it available to 1.0.1 would be great too, but appreciate the OpenSSL team isn't huge. Is there any timetable on the 1.0.2b release? It seems pulling the following three commits into the 1.0.2a branch and

Re: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/15 15:43, Dominyk Tiller wrote: Hi Matt, Thanks for the reply on this, and for backporting the fix to 1.0.2! Having it available to 1.0.1 would be great too, but appreciate the OpenSSL team isn't huge. Is there any timetable on the

Re: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/04/15 14:30, Dominyk Tiller wrote: Apologies. Either I'm an idiot or autocorrect is feeling amusing today. I meant https://gist.github.com/DomT4/f86618bdfe2f27c8d66a rather than https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. Sent

[openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Hello openssl-dev, I got a problem building openssl 1.0.2a on SUSE. Platform: uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler: gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure

[openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report)

Apologies. Either I'm an idiot or autocorrect is feeling amusing today. I meant https://gist.github.com/DomT4/f86618bdfe2f27c8d66a rather than https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c.

[openssl-dev] Fwd: [Ach] Twitter Cloudflare TLS config + patches

---BeginMessage--- Hi, Twitter released their TLS server config as well as some patches to OpenSSL. One of them does Key Rotation for Session Tickets, quite nice. https://github.com/twitter/sslconfig A similar repository is maintained by Cloudflare (with patches for optimized ChaCha20):

Re: [openssl-dev] Fwd: DTLS handshake not getting completed

Hi Matt, I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running into the same issue.Any idea what could be the issue. Thanks, Raju. On Mon, Mar 9, 2015 at 5:58 AM, Matt Caswell m...@openssl.org wrote: On 08/03/15 04:04, Kannamraju P wrote: -- Forwarded message

Re: [openssl-dev] Fwd: DTLS handshake not getting completed

On 09/03/15 15:17, Kannamraju P wrote: Hi Matt, I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running into the same issue.Any idea what could be the issue. Hmwhat version of OpenSSL are you using? Do you still get this if you use the git HEAD version? Matt

Re: [openssl-dev] Fwd: DTLS handshake not getting completed

I am using openssl-1.0.1h . On Mon, Mar 9, 2015 at 12:33 PM, Matt Caswell m...@openssl.org wrote: On 09/03/15 15:17, Kannamraju P wrote: Hi Matt, I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running into the same issue.Any idea what could be the issue.

Re: [openssl-dev] Fwd: DTLS handshake not getting completed

On 09/03/15 16:38, Kannamraju P wrote: I am using openssl-1.0.1h . Please can you try the git HEAD (OpenSSL_1_0_1-stable) and let me know if you still have the same issue. There have been quite a few DTLS fixes that have gone in since 1.0.1h. Thanks Matt

Re: [openssl-dev] Fwd: DTLS handshake not getting completed

On 08/03/15 04:04, Kannamraju P wrote: -- Forwarded message -- From: Kannamraju P pkannamr...@gmail.com mailto:pkannamr...@gmail.com Date: Mar 6, 2015 12:44 AM Subject: DTLS handshake not getting completed To: openssl-us...@openssl.org mailto:openssl-us...@openssl.org Cc:

[openssl-dev] Fwd: DTLS handshake not getting completed

-- Forwarded message -- From: Kannamraju P pkannamr...@gmail.com Date: Mar 6, 2015 12:44 AM Subject: DTLS handshake not getting completed To: openssl-us...@openssl.org Cc: Hi All, I am testing out a DTLS-SRTP webrtc call and running into following issue. Even after DTLS client

[openssl-dev] Fwd: Problem with encoding a CRL's signing algorithm

Hi, I think there is somewhat strange behaviour in OpenSSL that causes interesting bugs to happen when trying to encode CRLs based on deltas. More information about the issue (causing a segfault under certain conditions) is in the attached mail by Felix who discovered it. Regards, BenBE.

[openssl-dev] Fwd: Build failed in Jenkins: master_windows #32

It appears the Windows build is broken on master with the recent commit to the DES code. Please see the error message at the bottom of this message... Begin forwarded message: From: openssl.san...@gmail.commailto:openssl.san...@gmail.com Date: February 2, 2015 at 7:12:24 PM EST To:

Fwd: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function

Resend this time including r...@openssl.org...sorry for the noise on openssl-dev... On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote: The purpose of DTLSv1_listen is to listen for incoming datagrams from anyone. If it receives a ClientHello without a cookie it immediately responds with a

[openssl.org #3612] Fwd: [PATCH] Missing documentation for ocsp -timeout option

Patch applied. Many thanks, Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager

[openssl.org #3612] Fwd: [PATCH] Missing documentation for ocsp -timeout option

There's a very useful -timeout option in the ocsp utility which is not mentioned in the manpage or the help output. diff --git a/apps/ocsp.c b/apps/ocsp.c index 902546f..0c6579d 100644 --- a/apps/ocsp.c +++ b/apps/ocsp.c @@ -650,6 +650,7 @@ int MAIN(int argc, char **argv)

Re: [Fwd: Inconsistency in ARM support]

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

Re: [Fwd: Inconsistency in ARM support]

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

Re: [Fwd: Inconsistency in ARM support]

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

Re: [Fwd: Inconsistency in ARM support]

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

Re: [Fwd: Inconsistency in ARM support]

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

Re: [Fwd: Inconsistency in ARM support]

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 -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM

Re: [Fwd: Inconsistency in ARM support]

On 3 November 2014 18:36, Andy Polyakov ap...@openssl.org wrote: Anyway. As nobody seems to be objecting, it sounds like we are going for combination of both alternatives? I.e. those who specify specific -march lower than armv7 would be excused from capability detection and run-time switch,

Re: [Fwd: Inconsistency in ARM support]

On 31 October 2014 18:12, Andy Polyakov ap...@openssl.org wrote: Anyway. As nobody seems to be objecting, it sounds like we are going for combination of both alternatives? I.e. those who specify specific -march lower than armv7 would be excused from capability detection and run-time switch,

Re: [Fwd: Inconsistency in ARM support]

Anyway. As nobody seems to be objecting, it sounds like we are going for combination of both alternatives? I.e. those who specify specific -march lower than armv7 would be excused from capability detection and run-time switch, and those who additionally specify better -Wa and corresponding

Re: [Fwd: Inconsistency in ARM support]

Anyway. As nobody seems to be objecting, it sounds like we are going for combination of both alternatives? I.e. those who specify specific -march lower than armv7 would be excused from capability detection and run-time switch, and those who additionally specify better -Wa and corresponding

Fwd: Query Regarding defining MTU for DTLS Packet

Hi All, I am Trying to limit the packet size for DTLS messages. By using ssl_set_mtu() I am able to define max size for particular record. But in the above Handshake OPENSSL combines multiple records and sends out in a single UDP Packet.Is there a way we can configure OPENSSL such that it

Re: [Fwd: Inconsistency in ARM support]

Personally, I think there are few cases where Thumb2 makes sense, and I would be perfectly happy for all the ARM .asm code to assemble to ARM code only. What I do think is that we could refine the logic around interworking returns based on those #defines instead of on the ARCH, i.e., when lr

  1   2   3   4   5   >