Re: [openssl-dev] GCM for AFALG engine

On 02/02/18 11:18, Atul Gupta wrote: > I want to add GCM support to afalg engine and have the patch tested with > apache and s_server/s_client. Can I submit the patch for review? Any > suggestion? A patch would be most welcome. All patches should be submitted through github. Please make sure

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 19/01/18 16:32, Michael Richardson wrote: > Matt Caswell <m...@openssl.org> wrote: > > Please raise a separate PR for this work. It *must* be portable though > > and work across all our platforms (e.g. including VisualC etc). My > > suggestion is that y

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 17/01/18 16:34, Michael Richardson wrote: > > > It seems like a fairly simple solution could solve this. Currently we > > have BIO_dgram_get_peer() which returns the peer's address for the last > > message read from a BIO. You could imagine a new call being introduced > > to

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 16/01/18 19:44, Michael Richardson wrote: > > Matt Caswell <m...@openssl.org> wrote: > >> a) when the existing FD is connect(2) any future traffic to the bound > >> port will get rejected with no port. So the application really has to &g

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

On 16/01/18 15:32, Michael Richardson wrote: > > a) when the existing FD is connect(2) any future traffic to the bound port >will get rejected with no port. So the application really has to open a >new socket first. >The application can do this two ways: it can open a new socket on

[openssl-dev] OpenSSL wins the Levchin prize

Today I have had great pleasure in attending the Real World Crypto 2018 conference in Zürich in order to receive the Levchin prize on behalf of the OpenSSL team. More details are available in my blog post here: https://www.openssl.org/blog/blog/2018/01/10/levchin/ Matt -- openssl-dev mailing

Re: [openssl-dev] OpenSSL version 1.0.2n published

On 07/12/17 15:16, Randall S. Becker wrote: > For HPE NonStop J-Series: Builds passed. Previous version was 1.0.2m. > > New breakage: > ../util/shlib_wrap.sh ./fatalerrtest ../apps/server.pem ../apps/server.pem > SSL_accept() failed -1, 1 > 1827815872:error:140800FF:SSL

Re: [openssl-dev] a possible bug for certain usage of openSSL1.1.0 with TLSv1

On 02/11/17 13:01, Ma chunhui wrote: > Hi, Openssl team > After we upgrade openSSL from 1.0.2 to 1.1.0f, we met an error which > might be a bug. Does this fix it: https://github.com/openssl/openssl/pull/4685 (master) https://github.com/openssl/openssl/pull/4686 (1.1.0) Matt -- openssl-dev

Re: [openssl-dev] Forthcoming OpenSSL releases

On 30/10/17 13:50, Matt Caswell wrote: > Forthcoming OpenSSL releases > > > The OpenSSL project team would like to announce the forthcoming release > of OpenSSL versions 1.1.0g and 1.0.2m. > > These releases will be made available on 2nd

[openssl-dev] Forthcoming OpenSSL releases

Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0g and 1.0.2m. These releases will be made available on 2nd November 2017 between approximately 1300-1700 UTC. This is a bug-fix release. It

Re: [openssl-dev] Systemwide configurability of OpenSSL

On 25/10/17 16:19, Tomas Mraz wrote: >> |However libssl currently does not have a way to apply some policy such >> |as using just protocol TLS1.2 or better system-wide with a possibility >> |for sysadmin to configure this via some configuration file. Of course >> |it would still be up to

Re: [openssl-dev] New crypto algorithms in openSSL engine

On 23/10/17 12:51, APOB83 wrote: > Hi, > > I've noticed the following statement in another thread here... > > *May I suggest you have a look at the GOST engine? It does implement > the algorithm entirely in the engine. The only things added in the > OpenSSL code are the OIDs (not strictly

[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] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On 03/10/17 18:51, Robin H. Johnson wrote: > On Tue, Oct 03, 2017 at 09:45:43AM +0200, Tomas Mraz wrote: >> On Tue, 2017-10-03 at 08:23 +0100, Matt Caswell wrote: >>> >>>> 1.2. This also opens the path to stronger key derivation (PBKDF2) >>>> 2. During

Re: [openssl-dev] rejecting elliptic_curves/supported_groups in ServerHello (new behavior in master/1.1.1 vs 1.1.0)

On 03/10/17 16:15, Benjamin Kaduk via openssl-dev wrote: > Hi all, > > Doing some testing with a snapshot of master (s_client with -tls1_2 and > optionally a cipherspec that prefers ECDHE ciphers), we're running into > a sizeable number of servers that are sending extension 0xa (formerly >

Re: [openssl-dev] [RFC] enc utility & under-documented behavior changes: improving backward compatibility

On 02/10/17 20:20, Robin H. Johnson wrote: > Commit f8547f62c212837dbf44fb7e2755e5774a59a57b (documented in > 9e8b6f042749ded556380227c9f2db7ffad9a3aa), changed the default digest > for the 'enc' utility from MD5 to SHA256. > > While I do strongly encourage getting away from MD5, this has the >

Re: [openssl-dev] Missing EVP_PKEY_meth_get_xxx methods?

On 02/10/17 15:00, Blumenthal, Uri - 0553 - MITLL wrote: > Moving to openssl-dev, because I think OpenSSL-1.0.2 needs a fix. > >   > > To be more specific, the following get methods are missing in 1.0.2: > >   > > - EVP_PKEY_meth_get_sign(EVP_PKEY_METHOD *,  …) > > -

Re: [openssl-dev] New crypto algorithms in openSSL engine

On 27/09/17 15:32, Byrne, Andrew wrote: > I’m working on testing some lattice based algorithms in openSSL for the > establishment of a TLS channel. I’ve investigated the potential for > developing an engine to support this as it would mean I don’t need to > touch the core openSSL code. However,

Re: [openssl-dev] why TLSv1 need two tls1_enc to get decrypted data while TLSv1.1/TLSv1.2 need one in OpenSSL1.1.0f?

On 27/09/17 15:44, Ma chunhui wrote: > Hi,  > > I met one problem when using OpenSSL1.1.0f with protocol TLSv1. > In brief, when using TLSv1,  after server side received encrypted data, > and after function tls1_enc finished, the decrypted data is not put in > result buffer, after another

Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency

ymas.com >Director, Highland Sun http://highlandsun.com/hyc/ >Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Matt Caswell <m...@openssl.org>

[openssl-dev] QUIC

Issue 4283 (https://github.com/openssl/openssl/issues/4283) has caused me to take a close look at QUIC. This seems to have been getting a *lot* of attention just recently. See the IDs below for details: https://tools.ietf.org/html/draft-ietf-quic-transport-05

Re: [openssl-dev] 1.1.1 master consistently fails (was Re: openssl 1-1-0-stable fails)

On 03/09/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote: > MacOS 10.12.6, Xcode-8.3.3. Current Github master: > > Test Summary Report > --- > ../test/recipes/70-test_clienthello.t(Wstat: 256 Tests: 1 > Failed: 1) > Failed test: 1 > Non-zero exit status: 1 >

Re: [openssl-dev] TLS 1.3 non compliance with current draft

On 01/09/17 18:05, Hubert Kario wrote: > When openssl sends a second Client Hello message, it modifies it quite > extensively, not only client_random is changed but also advertised cipher > suites. > > see https://github.com/openssl/openssl/issues/4292 > > That makes it non-compliant with

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)

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 29/08/17 15:02, Salz, Rich via openssl-dev wrote: > > dev asap. If there are problems with it we can always revert it before > it makes it into a release. > > Someone on the OMC called that “flip-flopping” and seemed to be against this > kind of thing. > > If we are going to have

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

On 29/08/17 10:45, Dr. Matthias St. Pierre wrote > Currently, the OpenSSL core members seem to be reluctant to make the > API public, at least at this early stage. I understand Rich Salz's > viewpoint that this requires a thorough discussion, because a public > interface can't be easily changed

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 17/08/17 13:22, Salz, Rich via openssl-dev wrote: > I understand the concern. The issue I am wrestling with is strict > compatibility with the existing code. Does anyone really *want* the > RNG’s to not reseed on fork? It’s hard to imagine, but maybe > somewhere someone is. And then it’s

Re: [openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017

r setup. Will update if I face any > more issues. Yes - your kernel headers must be at least at 4.1.0 or better for afalg to work. Matt > > Thanks > Jitendra > > > > > ---- > On Wed, 8/16/17, Jitendra Lulla <lull...@yahoo.com> wrote: > > Subject: Re: af

Re: [openssl-dev] afalg with OpenSSL 1.1.0f 25 May 2017

Comments inserted. On 14/08/17 08:20, Jitendra Lulla wrote: > Hi, > > I am trying to use afalg on Linux 4.9.37 with OpenSSL 1.1.0f. > > I am facing 2 issues: > > ONE: when I issue the speed command, I see the following: > > [root@localhost apps]# ./openssl speed -evp aes-128-cbc -engine afalg

Re: [openssl-dev] Build issue

On 02/08/17 03:19, Matthew Stickney wrote: > Ok, progress (sort of)! It turns out I was indeed using the wrong > version of perl -- I was using the perl that was installed as part of > the msys2 base-devel group, not the mingw-w64--perl package, > which is a whole separate thing. Errr no. You

Re: [openssl-dev] openssl s_server "-legacy_renegotiation" option was present in version 1.0.1u but removed in version 1.0.2a

On 05/07/17 13:16, slon v sobstvennom palto wrote: > Hi, > openssl command line utility "s_server" command "-legacy_renegotiation" > option was present in version 1.0.1u but removed in version 1.0.2a. In > the source code of 1.0.2a the option is still present in the on screen > help but not

Re: [openssl-dev] TLS1.3 NewSessionTicket format

On 01/07/17 01:35, Hubert Le Van Gong wrote: > Greetings, > > We're doing some testings around TLS1.3 and in particular we're looking > at session resumption. > > We've captured some of the NewSessionTicket msgs sent by the server > (Nginx over openssl 1.1.1-dev) and have a hard time

Re: [openssl-dev] Work on a new RNG for OpenSSL

able as an option. I don't think we will necessary be able to do the latter on all platforms that we support. As for which of the two is the default: where it is available - the latter. Where it isn't the former. Matt > > Regards, > > Matthias St. Pierre > > > Vote 1: > >

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 27/06/17 19:50, Benjamin Kaduk wrote: > On 06/27/2017 02:28 AM, Matt Caswell wrote: >> >> On 26/06/17 21:18, Kurt Roeckx wrote: >> >>> I think it should by default be provided by the OS, and I don't >>> think any OS is documenting how much randomn

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26/06/17 21:18, Kurt Roeckx wrote: >> “Recommendation for Random Number Generation Using Deterministic Random >> Bit Generators” >> http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf >> >> That design may look complicated, but if you think you can >> leave out some of the

Re: [openssl-dev] Work on a new RNG for OpenSSL

On 26/06/17 19:57, Salz, Rich via openssl-dev wrote: > I was asked off-list why we're doing this. A reasonable question. :) > > There are many complains about the OpenSSL RNG. For started: > https://github.com/openssl/openssl/issues/2168 >

Re: [openssl-dev] Travis failures

On 16/06/17 10:25, Matt Caswell wrote:> Possibly a bad clang-3.9 update?? Any ideas? After this command in the logs: $ sudo -E apt-get -yq --no-install-suggests --no-install-recommends --force-yes install clang-3.9 Failing builds look like this: After this operation, 262 MB of additional d

[openssl-dev] Travis failures

I'm seeing some weird Travis failures: LD_LIBRARY_PATH=.: clang-3.9 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -Wall -O3 -pthread

Re: [openssl-dev] Questions about ASYNC API for engines and moving read buffer.

On 02/06/17 15:20, Emeric Brun wrote: > > I've just read the code and I see it is not possible. > > I'm disappointed because i think that a lot of applications which are using > openssl in asynchronous mode > also uses SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER and have > ephemeral/reused/circular

Re: [openssl-dev] Questions about ASYNC API for engines and moving read buffer.

On 02/06/17 11:00, Emeric Brun wrote: > Hi, > > I'm working on an ASYNC engine designed to offload crypto on multiple thread > for monoproc applications. > > No issue on asymetric crypto part but i'm facing a problem concerning ciphers: > > When an SSL_read operation perform a do_cipher

[openssl-dev] Forthcoming OpenSSL releases

Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2l and 1.1.0f. These releases will be made available on 25th May 2017 between approximately 1200-1600 UTC. Note: These are bug-fix only

Re: [openssl-dev] [openssl-users] OpenSSL 1.1.1 release timeframe

On 18/05/17 06:32, Jayalakshmi bhat wrote: > Please can any one let me know the release date or time line for OpenSSL > 1.1.1? We have not set a date as yet. At the very least we will not be able to release until the IETF takes TLSv1.3 out of draft status - which is not in our control. Matt

Re: [openssl-dev] shlibloadtest failure on non-Linux

On 09/05/17 18:12, Nick Reilly wrote: > > > On 2017-05-09 10:08 AM, Matt Caswell wrote: >> >> I'm not sure why this makes a difference. The return value of dlclose() >> tells you whether there has been an error or not. Not whether the >> library has actuall

Re: [openssl-dev] shlibloadtest failure on non-Linux

On 09/05/17 15:03, Salz, Rich via openssl-dev wrote: >> doesn't test for whether this is set. I think the shlibloadtest should only >> test >> the dlclose() return value on if OPENSSL_USE_NODELETE is set. > > Please see https://github.com/openssl/openssl/pull/3399 > >> 2) crypto/init.c at

Re: [openssl-dev] Null pointer dereferences?

On 09/05/17 01:22, Zubin Mevawalla wrote: > I was curious if these were real null pointer dereference issues? > > CodeAi, an automated repair tool being developed at Qbit logic, > suggested a couple of if-guards as fixes. > > The first was in crypto/async/async_wait.c on line 157. `prev` is >

[openssl-dev] Using TLS1.3 with OpenSSL

Hi all OpenSSL 1.1.1, when it is released, will support TLSv1.3 and it will be binary and source compatible with OpenSSL 1.1.0. If your application already supports 1.1.0 then, in theory, all you need to do to support TLSv1.3 is to drop in the new OpenSSL version. However there are various issues

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

Just to let you all know that we managed to close 58 old tickets as a result of this event. Fantastic! Thanks Matt On 27/04/17 08:43, Matt Caswell wrote: > > > Hi all > > Our next "Code Health Tuesday" event will be on Tuesday 2nd May. > > This time we wou

[openssl-dev] OpenSSL master now at TLSv1.3 draft-20

FYI, I have just made the necessary updates to bring the OpenSSL master branch up to TLSv1.3 draft-20 compatibility. I don't know of any other draft-20 implementations yet so treat with caution and please test! As with all new drafts, draft-20 is not compatible with draft-19. If you were using

[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 <m...@openssl.org> To: openssl-dev@openssl.org <op

[openssl-dev] Code Health Tuesday - old issues

Hi all Our next "Code Health Tuesday" event will be on Tuesday 2nd May. This time we would like to focus on closing off Github issues (with a particular focus on old ones - including all those we brought over from RT). Thanks! Matt FAQ: Q: How do I participate? A: Review the old issues in

Re: [openssl-dev] ETA: TLS 1.3 release

On 20/04/17 21:24, David Woodhouse wrote: > On Wed, 2017-04-19 at 12:14 +, Salz, Rich via openssl-dev wrote: >>> Out of curiosity, what's the ETA for TLS 1.3? >>> [1] mentions April 5 as the release date (which was two weeks ago). >>> >>> [1]:

Re: [openssl-dev] Testing CVE-2016-6309

On 14/04/17 21:11, Lysoněk Milan wrote: > > On 06/04/17 00:25 Matt Caswell wrote: >> Can you reproduce it using the fuzz corpora added in commit 44f206aa9df, >> or by running the large message test introduced in 84d5549e69? >> >> Matt >> > > Commit 44f

Re: [openssl-dev] Code Health Tuesday - summary

On 13/04/17 01:02, Paul Dale wrote: > Code Health Tuesday is over once again. > > > > In total 27 PRs were raised for the event with three of these as yet > unmerged. In total about thirty tests were updated which represents > roughly half of the outstanding test cases. > > All in all, a

Re: [openssl-dev] Question about commit 222333cf01e2fec4a20c107ac9e820694611a4db

On 12/04/17 00:20, Michael Reilly wrote: > Unfortunately the check breaks code which doesn't know nor need to know the > keysize. The engine takes care of allocating buffers required. So how does EVP_SignFinal() work with your engine? The "sig" parameter is supposed to be allocated by the

Re: [openssl-dev] Testing CVE-2016-6309

On 05/04/17 19:24, Lysoněk Milan wrote: > Hello, > I'd like to make test for CVE-2016-6309 > https://www.openssl.org/news/secadv/20160926.txt in tlsfuzzer. I tried > combining and sending different lengths (from small lengths to large) of > application data and padding, but I could not trigger

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

On 04/04/17 15:34, Thiago Arrais wrote: > Hmmm... The Getting Started page talks about writing test cases. > > It seems like a good start. Is there any area that needs special attention? Actually I have a suggestion for a fairly small self-contained piece of work suitable for a starting

Re: [openssl-dev] Renegotiation ticket 3712

gards > Darshan > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt > Caswell > Sent: Monday, April 03, 2017 2:53 PM > To: openssl-dev@openssl.org > Subject: Re: [openssl-dev] Renegotiation ticket 3712 > > > &g

Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

On 31/03/17 18:54, Raja ashok wrote: > Hi All, > > > > In ssl3_write_bytes, if (len < tot) we are returning failure with > SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to > “s->s3->wnum”. Otherwise when application calls back SSL_write with > correct buffer, it causes

Re: [openssl-dev] Code Health Tuesday - documentation!

On 23/03/17 17:57, Matt Caswell wrote: > Our next "Code Health Tuesday" event will be on Tuesday 28th March. > > We've seen some great contributions during our last two events with many > significant improvements merged as a result. We'd like to continue that >

Re: [openssl-dev] Code Health Tuesday - documentation!

Just a reminder about this event taking place tomorrow! Matt On 23/03/17 17:57, Matt Caswell wrote: > > Hi all > > Our next "Code Health Tuesday" event will be on Tuesday 28th March. > > We've seen some great contributions during our last two events with many >

Re: [openssl-dev] Memory leak in application when we use ECDH

s the > client certificate and chain. > darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY > passed to openssl from app is cleaned up by the app. > darshanmody> 3. Connect client with certificates that server does not trust. > darshanmody> 4. The con

[openssl-dev] Code Health Tuesday - documentation!

Hi all Our next "Code Health Tuesday" event will be on Tuesday 28th March. We've seen some great contributions during our last two events with many significant improvements merged as a result. We'd like to continue that trend with our next theme - documentation. Just find some missing

Re: [openssl-dev] Memory leak in application when we use ECDH

o fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. Matt > > Thanks Darshan > > -Original Message- From: openssl-dev > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell > Se

Re: [openssl-dev] Memory leak in application when we use ECDH

On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > Matt, > > Even after accounting for the EC_KEY we still observe some leak. The > leak started after we started using supporting EC with callback > SSL_set_tmp_ecdh_callback(). > > The core dump shows the string data of the far-end

Re: [openssl-dev] Memory leak in application when we use ECDH

else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } > > Thanks > Darshan > > -Original Message- > From: openssl-dev [mailto:openssl-dev-boun...@openssl.org]

Re: [openssl-dev] DTLS is not sending alert in case of BAD CCS

https://github.com/openssl/openssl/pull/3009 On 21/03/17 15:24, Raja ashok wrote: > Hi All, > > > > Looks like there is a typo mistake in dtls1_read_bytes, because of this > alert is not send for bad CCS. > > > > In dtls1_read_bytes, incase of bad change cipher spec we are setting > alert

Re: [openssl-dev] Memory leak in application when we use ECDH

On 21/03/17 09:46, Matt Caswell wrote: > > There is a potential leak in this case: > > if (s->s3->tmp.ecdh != NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >ERR_R_INTERNAL_ERROR); &g

Re: [openssl-dev] Memory leak in application when we use ECDH

On 15/03/17 05:44, Mody, Darshan (Darshan) wrote: > Hi, > > We have observed memory leak when we register for ECDH > callback(SSL_set_tmp_ecdh_callback). While performing negative testing > with load we find that the applications starts leaking memory. > > Further checking the Openssl

Re: [openssl-dev] Tuesday's code health day

On 16/03/17 16:29, Salz, Rich via openssl-dev wrote: > Our most recent code health Tuesday was a success. Nearly a dozen people > worked to achieved the following: > > - Our external contributors wrote completely new unit test for previously > untested API's (stack, LHASH, and

[openssl-dev] TLSv1.3 draft 19 support

All, I have just pushed to master the updates necessary for TLSv1.3 draft-19 support. This covers most of the required changes with the exception of CertificateRequests which are waiting on PR 2918 to be merged. Unfortunately there aren't other draft-19 implementations out there yet (that I know

Re: [openssl-dev] Openssl 1.0.2 snapshot bug

On 23/02/17 12:54, The Doctor wrote: > Please fix! > This fix is already on the way: https://github.com/openssl/openssl/pull/2713 Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Project Bylaws

I am pleased to be able to announce the publication of our new Project Bylaws. I have written a short blog post about what we are hoping to achieve and some of the thinking that went into these here: https://www.openssl.org/blog/blog/2017/02/13/bylaws/ The bylaws themselves are available here:

Re: [openssl-dev] SNI by default in s_client

On 13/02/17 16:55, Salz, Rich wrote: >> extension by default that wasn't there before - and that we've already >> decided to add new extensions in 1.1.1 due to the forthcoming >> TLSv1.3 support. > > You mean adding new extensions in the wire protocol? Or are did we modify > any API/ABI

[openssl-dev] SNI by default in s_client

I'd like to canvas opinion on this PR: https://github.com/openssl/openssl/pull/2614 At the moment s_client does not add the SNI extension by default. You have to explicitly ask for it using the "-servername" option. This can lead to some problems where servers reject connection attempts from

Re: [openssl-dev] Bug reports and patches for OpenSSL

On 05/02/17 06:54, yuchi tian wrote: > Dear OpenSSL developers, > > We are software engineering researchers at University of Virginia. As > part of a research project, we have built a tool for automatically > finding and fixing error handling bugs and are testing it on > various cryptographic

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

counter assertion failure from: > https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L977-L978 > The only other thing could be that the code (which I inherited) is calling a > SSL_shutdown() beforehand which does something I have missed...? > > Best wishes, > Mischa

Re: [openssl-dev] SSL_set_bio(ssl, bio, bio) and BIO_up_ref(bio)

On 30/01/17 10:13, Mischa Salle wrote: > Hi all, > > I noticed a doublefree when calling SSL_set_bio(ssl, bio, bio) followed > by either SSL_set_bio(ssl, NULL, NULL) or SSL_set_io_SSL_free(ssl). > Valgrind shows the double free, and I see the assert in >

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

On 27/01/17 16:54, Benjamin Kaduk via openssl-dev wrote: > [moving from github to -dev] > > On 01/27/2017 07:36 AM, mattcaswell wrote: >> >> 1.0.2 is the software version. >> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - >> which is different. Software version 1.0.2 is a

[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] Build fail when configured using no-nextprotoneg

On 11/01/17 08:58, Michel wrote: > Can we assume it is temporary due to “the process of transitioning from > NPN to ALPN” mentioned in ssl_locl.h ? Its a bug: https://github.com/openssl/openssl/pull/2212 Matt -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] Revert commit 10621ef white space nightmare

On 09/01/17 17:46, Leonard den Ottolander wrote: > Hello, > > https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12 > > is a white space nightmare. The replacement of "#define"s by "# define"s > etc. is just silly and makes it

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

On 03/01/17 12:44, Salz, Rich wrote: >>> I'm still waiting on a reply ... I assume holidays are contributing to the >>> delay. >>> However, openssl_tpm_engine is a DCO project, so that concern is >>> irrelevant here. >> >> Sorry, I'll push to get the bylaws made public, is that what you need? >

Re: [openssl-dev] backporting CVE-2016-8610 fix to 1.0.1 branch

On 17/12/16 01:59, Peter Djalaliev (CS) wrote: > Hello, > > > > Will commit > > > > Don't allow too many consecutive warning alerts > > > > author Matt Caswell <m...@openssl.org> > > Wed, 21 S

Re: [openssl-dev] Typo in BUF_reverse manual

Matt, > > https://github.com/openssl/openssl/pull/2075 > <https://github.com/openssl/openssl/pull/2075> > > On Mon, Dec 12, 2016 at 3:17 PM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > Coul

Re: [openssl-dev] Typo in BUF_reverse manual

Could you open that as an issue in GitHub? Or even better a PR to fix it ;-) Thanks Matt On 12/12/16 12:16, Dmitry Belyavsky wrote: > Hello! > > I found a typo in the BUF_reverse manual > (https://www.openssl.org/docs/man1.1.0/crypto/BUF_MEM_new_ex.html) > > The manual says: > >

Re: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue

On 28/11/16 09:51, Matt Caswell wrote: > > > On 27/11/16 13:27, The Doctor wrote: >> Can you get his fixed? >> >> ../util/shlib_wrap.sh ./heartbeat_test >> test_dtls1_not_bleeding failed: expected return value -1, received 0 >

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

On 28/11/16 23:00, Blumenthal, Uri - 0553 - MITLL wrote: > > The problem is in the test. Version negotiation happens before cipher > > selection. The test creates a connection which negotiates TLSv1.3. It > > then attempts to select a cipher. However no TLSv1.3 ciphers are offered >

Re: [openssl-dev] Openssl 1.1 port - hash state serializing

On 28/11/16 20:16, Ken Goldman wrote: > There was no answer on the 'users' list, so this is perhaps now a > feature request. Please raise feature requests as issues on Github. Matt > > Is there a possibility of getting this function? > > ~~ > > I have a simulation of a hardware device that

Re: [openssl-dev] FW: 1.1 master fails mac-then-encrypt test

On 28/11/16 21:58, Blumenthal, Uri - 0553 - MITLL wrote: >> I can't reproduce this. But on the other hand I don't have previous > >installation on --prefix. > > But did you add “enable-tls1_3” to your config? > > >I mean I would guess this is because test > >program picks shared

Re: [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue

On 27/11/16 13:27, The Doctor wrote: > Can you get his fixed? > > ../util/shlib_wrap.sh ./heartbeat_test > test_dtls1_not_bleeding failed: expected return value -1, received 0 > ** test_dtls1_not_bleeding failed ** > > test_dtls1_not_bleeding_empty_payload failed: expected return value

Re: [openssl-dev] Tag for 1.1.0c?

On 10/11/16 17:52, Benjamin Kaduk wrote: > I'm failing to find a tag for 1.1.0c either on git.openssl.org or on github. > > Am I missing something? Oops. My mistake. I forgot to push it. Matt -- 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

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, >

Re: [openssl-dev] [openssl-users] iStill seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases

On 02/11/16 17:04, The Doctor wrote: > On Wed, Nov 02, 2016 at 05:00:27PM +, Salz, Rich wrote: >> >>> Why is this not solved? >> >> It will be solved before the next release. No further promises. > > I will report back tomorrow. > > Still It is a good thing to gripe if you see an issue.

Re: [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases

On 02/11/16 14:47, The Doctor wrote: > Why is this not solved? > > ../util/shlib_wrap.sh ./v3nametest > ../util/shlib_wrap.sh ./heartbeat_test > test_dtls1_not_bleeding failed: expected return value 0, received -1 > ** test_dtls1_not_bleeding failed ** > >

Re: [openssl-dev] DTLS encrypt-then-mac

On 13/10/16 11:45, David Woodhouse wrote: > ... is broken in 1.1. We negotiate it, then don't actually *do* it. > > https://github.com/openssl/openssl/pull/1705 contains a patch to > disable it unconditionally for DTLS, on both server and client. > > In that same PR there's also a patch to

Re: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11

On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote: > Hi, > I have downloaded and builded last tree openssl versions for linux: > 1) openssl-1.0.1u.tar.gz > 2) openssl-1.0.2j.tar.gz > 3) openssl-1.1.0b.tar.gz Any particular reason why you need all three? > > I successful

Re: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11

On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote: > Hi, > I have downloaded and builded last tree openssl versions for linux: > 1) openssl-1.0.1u.tar.gz > 2) openssl-1.0.2j.tar.gz > 3) openssl-1.1.0b.tar.gz Any particular reason why you need all three? > > I successful

Re: [openssl-dev] Calculating DTLS payload MTU

On 05/10/16 22:51, David Woodhouse wrote: > On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: >> Hwell its not constant even by cipher. It depends on the >> transport (IPv6 has a bigger overhead than IPv4). > > That is included in d1->lin

Re: [openssl-dev] Calculating DTLS payload MTU

On 05/10/16 15:37, David Woodhouse wrote: > DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > > /* We already set the link MTU, but hopefully by the time we >* finish it, this function will be better at working out the >* actual tunnel MTU than OpenSSL is. So do that

Re: [openssl-dev] Calculating DTLS payload MTU

On 05/10/16 15:37, David Woodhouse wrote: > On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >> How's this for a start... > > Now I think I have it right for CCM too, although having to use > strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... > and then maybe I can

  1   2   3   4   5   6   7   8   9   10   >