Re: [openssl-project] Beta release on Tuesday

>As normal we are planning a new beta release on Tuesday. This means that >we will be freezing the repo from Monday afternoon (UTC). I'm in US but available if nobody "closer" can do it. ___ openssl-project mailing list

[openssl-project] FW: [TLS] WGLC for draft-ietf-tls-tls13-vectors

Anyone want to take a look at wedging this into our test suite? On 5/8/18, 12:31 PM, "Sean Turner" wrote: All, This is the working group last call for the "Example Handshake Traces for TLS 1.3" draft available at

Re: [openssl-project] Current votes FYI

ote simply did not pass. Tim. On Thu, 24 May 2018, 12:59 am Salz, Rich, <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: Another update VOTE: Remove the second paragraph ("Binary compatibility...improve security") from the relea

Re: [openssl-project] build/test before merging

>Unfortunately, I didn't have time to follow my vision yet. Also, it would > have been easier for me to do it in Python than in Perl. +1 for python! :) ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

>My main concern is that currently, openssl pkcs12 may create broken pkcs12 > files (because it misinterprets the pass phrase when constructing a > BMPString), and doesn't notify the user at all (doesn't even check). For those who haven't reada the PR and all its comments, I propose that

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

password to valid UTF-8 encoding if this flag is given. On 6/7/18, 3:42 PM, "Salz, Rich" wrote: >So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other f

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

>Except that, because of the way PKCS12_gen_mac() works, this isn't true. If the input pass phrase looks like a UTF-8 encoded string (because there are valid characters in other encodings that will like like UTF-8 byte sequences), it will be used as if -passutf8 was given

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

> If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that

Re: [openssl-project] [openssl-omc] stepping down from OMC

* I'm leaving the project. https://www.youtube.com/watch?v=YtsZoIe3Czk You have a great deal to be proud of, and OpenSSL is much better for the time you spent here. We will miss you. I will miss you. ___ openssl-project mailing list

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

>However, what's going to happen is that PKCS12_gen_mac() will generate this for a BMPString: Which is what we do now, right? And the docs for this *new flag* explain that the behavior could change in the future. To be "pass8bit" means "pass 8bit bytes through to lower layer" But if

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

>I have zero idea what the doc says, because I haven't seen the docs yet. Did I miss the PR? No. It's posted here on the mailing list for discussion and reposted here: +=item B<-passutf8>, B<-pass8bit> + +These flags indicate the character set encoding on the password value. +By

Re: [openssl-project] Beta release today

>It would still be good if someone can freeze the repo though please: ssh openssl-...@git.openssl.org freeze openssl matt I will do this tonight, eastern time. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Is Mac a supported platform?

>Regarding the original question, it's "supported" insofar that we have osx among the Travis builds (at least usually... there have been times when the osx backlog has been so great that we've temporarly disabled it). So maybe I should just create a PR to update INSTALL with

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

>I think that the gist of the difference of opinion is whether it's OK to use locale dependent functions such as mbstowcs in libcrypto or not. Thanks for the summary. I am against use locale-dependent functions in libcrypto. ___

Re: [openssl-project] Is Mac a supported platform?

https://github.com/openssl/openssl/pull/6404 On 6/1/18, 5:33 PM, "Richard Levitte" wrote: In message <1bd96940-3b3b-4758-938a-01e576306...@akamai.com> on Fri, 1 Jun 2018 21:26:12 +0000, "Salz, Rich" said: rsalz> >Regarding the original qu

[openssl-project] FW: [openssl-commits] Build failed in Jenkins: master_noec #574

FYI On 6/26/18, 2:45 PM, "Barry Fussell (bfussell)" wrote: The evp_test is failing intermittently because there is an attempt to malloc zero bytes when running the new test that came in with this commit.

[openssl-project] GitHub labels

I think it’s a good idea that we periodically review the labels we’re using. Please look at https://github.com/openssl/openssl/labels and maybe suggest changes. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Freezing the repo

Done. On 4/30/18, 3:02 PM, "Matt Caswell" wrote: Please could someone freeze the repo for me for tomorrow's release: $ ssh openssl-...@git.openssl.org freeze openssl matt Thanks Matt ___

Re: [openssl-project] Beta release on Tuesday

>Nobody else has stepped forward. Are you still available for this? Sure. >I would normally start around 12.00 UTC, but could push it a bit later if it works better for you. So that's 7am, it would be best to delay an hour. ___

[openssl-project] FW: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto

Can anyone lend John a hand with ed25519 signatures via command-line? This is important for the next version of domain-key email signing (spam avoidance) On 2/1/18, 2:14 PM, "John Levine" wrote: In article <3569aeba-5089-4827-8c18-ec13246bc...@akamai.com> you write:

Re: [openssl-project] chatty make output

it used to do. Also, the message is geared to disappear with 1.1.1a or above. Cheers Richard "Salz, Rich" <rs...@akamai.com> skrev: (1 februari 2018 18:00:57 CET) I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE:

[openssl-project] chatty make output

I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the disabled options or the "make variables" with their values. Instead, you must use 'configdata.pm' as a script to get a

Re: [openssl-project] Style guide update -- summary so far

➢ In general we should prefer ossl_assert over assert. Never use OPENSSL_assert() in libcrypto or libssl. Maybe that’s all to put into the guide, then. ___ openssl-project mailing list openssl-project@openssl.org

[openssl-project] FW: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC.

I filed the annual registration for OpenSSL Software Services and paid with the OpenSSL credit card. From: CT Corporation Reply-To: "[DO NOT REPLY] CT Corporation" Date: Monday, February 5, 2018 at 1:32 PM To: "rs...@openssl.org"

[openssl-project] Style guide update -- summary so far

A summary of the discussion thread so far. Not surprisingly, it’s all about the whitespace. :) The descriptions here were written to be understandable stand-alone. Once we come to a conclusion, we’ll wordsmith them into the coding style. Do not put a size after sizeof; do use parens. When

[openssl-project] FW: [vendor-meetings] Invitation to the 2018 CERT Vendor Meeting [INFO#384036]

IN case anyone is going to be in the area. On 2/8/18, 2:26 PM, "Art Manion" wrote: The CERT Coordination Center invites you to attend the 2018 CERT Vendor Meeting. The meeting will be held on Monday April 16, 2018, at the Westin St. Francis in San Francisco,

Re: [openssl-project] Style question

The error return is not documented. We are definitely moving to a "don't check params for NULL". I would like to see this changed to be the obvious one-liner. Tim will disagree, but he's on the wrong side of history :) ___ openssl-project mailing

Re: [openssl-project] Removing assembler for outdated algorithms

mbler for outdated algorithms Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: This is

Re: [openssl-project] Removing assembler for outdated algorithms

I am not suggesting we remove blowfish or any of those algorithms. I am suggesting we remove the assembler versions of them. On 2/10/18, 5:33 PM, "Viktor Dukhovni" <vik...@dukhovni.org> wrote: On Sat, Feb 10, 2018 at 10:19:20PM +, Salz, Rich wrote: >

[openssl-project] Removing assembler for outdated algorithms

This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not

Re: [openssl-project] Removing assembler for outdated algorithms

significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following

Re: [openssl-project] Removing assembler for outdated algorithms

> Those same systems will probably not have the newest OpenSSL either, and OpenSSH on those machines will certainly not be linked with a newer OpenSSL... I apologize for not being clear enough. I do not want to remove any of those algorithms. I just want to remove 10,000 lines

Re: [openssl-project] Removing assembler for outdated algorithms

> So we should tread with some care. Perhaps the software-only Blowfish is fast enough, but my point is that Blowfish is much less of an obvious outdated cipher than the others... That's a different point. I still don't agree. The difference between hand-tuned assembler and C

Re: [openssl-project] Removing assembler for outdated algorithms

> Is blowfish actually outdated? I thought it had some significant use, > and don't recall any major weakness... In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for the underlying cipher... PGP use to be a heavy user, but now it only decrypts or does

Re: [openssl-project] Draft Travel Reimbursement policy

Any commentary on this? Otherwise I’ll do a (two-week) vote next week. From: Rich Salz Reply-To: "openssl-project@openssl.org" Date: Monday, January 29, 2018 at 11:18 AM To: "openssl-project@openssl.org" Subject:

Re: [openssl-project] Style guide update -- summary so far

* nit: Do not put a space after sizeof. fixed. * Wasn't there also the suggestion by someone that if one part of an if-else statements needs braces that the other part should get some, too? It already says that. ___ openssl-project mailing

[openssl-project] Coding style updates

I’ve written up everything that seemed to have agreement, and kept the couple of items where it was less clear. Please comment here: https://github.com/openssl/web/pull/43 I want to do a vote by the end of the month. ___ openssl-project mailing list

Re: [openssl-project] Removal of NULL checks

>it's NULL. Now imagine that this stack was some kind of deny list. If >entry producer didn't pay attention to error when creating stack and >putting things into it, consumer would be led to belief that there is >nothing to deny and let through the requests that are supposed to be

Re: [openssl-project] Removal of NULL checks

>Whether one's for them, or against them, removing a check from a function that would formerly return an error and making it crash is a substantial API change. I don't disagree. ___ openssl-project mailing list

Re: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3

>"We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 PSKs) then we should disable TLSv1.3." This seems reasonable to me, albeit a bit wordy since you could delete the first sentence. :)

[openssl-project] TLS 1.3 and the release

You probably know by now that TLS 1.3 was just released as RFC 8446;

[openssl-project] FW: Certificate fractional time processing in upcoming openssl releases

So it seems counter to the spirit of the RFC to prevent openSSL from being able to interoperate with certs issued by IAIK or whatever noncompliant systems. Thanks, David From: "Salz, Rich" mailto:rs...@akamai.com>> Date: Friday, August 10, 2018 at 12:24 PM To: "Barry Fus

Re: [openssl-project] Releases tomorrow

>- "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to be merged. I have the required approval, just giving Rich some time to see if he has any further comments. Thanks, I'm good. >- If we're going to make any changes for issue 6904 (broken pipe for clients

Re: [openssl-project] Fractional seconds, etc.

>This seems to have been done in both the 1.0.2 and 1.1.0 after the release. Do you want to revert it in both branches, but keep it in 1.1.1? Or only revert it in 1.0.2? Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1. Sadly. And fix in a future release (I would re-open the

[openssl-project] Fractional seconds, etc.

I think we should revert https://github.com/openssl/openssl/pull/2668 The stricter RFC compliance turns out to impact many certs embedded in devices. Some estimates had thousands to millions. It affects interop with IAIK and Bouncy Castle. I looked at the code, and tried to figure out how to

[openssl-project] Taking a break

I am going to take a break from most of OpenSSL governance for the rest of the month. As I have been mostly the person handling all those other things, and as I am usually very very quick with email, I thought the project should know. I’m not going anywhere, it’s really just like the first

Re: [openssl-project] master is broken?

On 7/24/18, 1:42 PM, "Richard Levitte" wrote: Would you mind installing it? The package is called libcarp-always-perl on Debian and derivates, and if my RPM search fu isn't entirely off, the corresponding RPM package is perl-Carp-Always Or install with cpan... Okay.

Re: [openssl-project] master is broken?

sudo cpan Carp::Always I did this. Same results for config and the PERLOPT setting. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] master is broken?

; env | grep PERL ; PERL5OPT=-MCarp::Always ./config Operating system: x86_64-whatever-linux2 Can't locate Carp/Always.pm in @INC (you may need to install the Carp::Always module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5

[openssl-project] master is broken?

; g status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ; g pull Current branch master is up to date. ; ; ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 1.1.1-pre9-dev (0x10101009L) for linux-x86_64

[openssl-project] Finishing up this release

We’re close to finishing the 1.1.1 release. As we’ve said before, this is our next LTS release which means it will be supported for five years. There are a few things we still need to do and we’re encouraging the community to help. These include: Address all the “1.1.1” open issues, found at

[openssl-project] External contributors and the next release

I think we should make sure to set aside time to review as many of the non-project pull requests as possible. I think it is important to show a commitment to the larger community. One way to do this is to say that we will extend the BETA date by a week, and in that week no new code from the

[openssl-project] Copyrights, AUTHORS file, etc.

For some background you can take a look at https://github.com/openssl/openssl/pull/5499 and the blog posts here: https://www.openssl.org/blog/blog/categories/license/ The OMC voted in 2014 to work to an eventual change of license to Apache 2. That led to the CLA’s. We had calls with various

Re: [openssl-project] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

>Well, the condition for this vote is a bit extraordinary as well. I couldn't in good conscience propose a week long vote, because that potentially would have the effect to push the release a week anyway, because the release would have to wait for the result of the vote. We

Re: [openssl-project] OID policy

No there is no policy. We should have OID's for the things we implement ( On 3/14/18, 6:28 PM, "Paul Dale" wrote: Is there a policy about filling in missing OIDs in objects.txt? I noticed that AES-128-XTS is in objects.txt but doesn't include an OID even

[openssl-project] Applying system defaults to TLS config

https://github.com/openssl/openssl/pull/4848 The crux of the issue is that this would change SSL_CTX to apply system defaults when the object is created. In conjunction with the system config file include stuff, this makes it easy to change the behavior of all applications running on a system.

Re: [openssl-project] DRBGs, threads and locking

So is having a high-quality, lockless (per-thread) CSPRNG good enough for now? Phrased like that, I think so. We have enough other stuff to do. So +1 to Kurt's per-thread approach. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] OpenSSL FIPS Wiki Update

No mention of whether or not this will apply to EVERYTHING in a program, or will it be left to administrative guidance. Your thoughts, for example, on a “FIPS mode” flag for SSL or SSL_CTX? At a minimum, that needs to be listed as a stakeholder requirement (from Akamai). From:

Re: [openssl-project] DRBGs, threads and locking

So a major reason, as you explained, for having per-thread DRBG's is to reduce contention. When threadA creates an SSL object, the parent DRBG will be the threadA one. Therefore you have to introducing locking, since threadA might create two SSL objects and they could end up being used in

[openssl-project] Entropy seeding the DRBG

I had not realized that we just increased the “entropy” requirements by 50%, from 256 to 384. The original DRBG submission that I did only required 128 bits. I think that is wrong, and I think the PR that did it (#5503) should be reverted. I am concerned that we are trying to meet

[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

I would like to see this put on hold until we fix the ‘now requires 50% more random seeding’ issue. What should I do to force that issue? From: Richard Levitte Reply-To: openssl/openssl

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

>Yes, after what I all said previously, it's clear the code could use improvements. I think at least Matthias and I assumed the code about the minimum size was correct and that there was a minimum requirement of 128 bit. My expectation was that the *maximum* would also be 128

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

rsalz> My expectation was that the *maximum* would also be 128 bits. >Not sure what you're saying there. If the entropy acquisition routines is over enthusiastic and delivers 277 bits of entropy, are you saying it shouldn't be allowed to? I meant to say that the

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

kurt> So then I suggest we support the syscalls on all platforms that kurt> provide it. Who takes responsibility for fixing this? ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

>The 384 comes straight out of SP800-90A, see the table 10.2.1. I think we're getting close to needing a team vote on whether or not we want to follow SP800-90A for this release. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Entropy seeding the DRBG

>Note that with a nonce, that'll be 192 bits, unless I'm thinking wrong... But I agree with you, at least from a very practical point of view. I think using a nonce is needless. Use a personalization string (I used the address of the new DRBG).

Re: [openssl-project] Entropy seeding the DRBG

Is it expected that the number of bits of seed must equal the number of bits in the key strength? But at any rate, raising the seed size to 256 seems mildly tolerable, although I would prefer to keep it at 128. Raising it to 384 is wrong. ___

[openssl-project] Vote results

results: 7 yes, 1 no-vote topic: Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed during the beta as long as at least 3 OMC members approve the change Proposed by Matt Caswell Public: yes opened: 2018-03-29 closed: 2018-04-05 ONE WEEK VOTE

[openssl-project] build broken?

Making update CONF function code 122 collision at CONF_F_SSL_MODULE_INIT diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt index d1cc039..de3dacc 100644 --- a/crypto/err/openssl.txt +++ b/crypto/err/openssl.txt @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio

Re: [openssl-project] Some TLS 1.3 drafts don't have branches

+1 On 4/12/18, 5:51 AM, "Matt Caswell" <m...@openssl.org> wrote: On 12/04/18 02:42, Salz, Rich wrote: > ; g branch -r -v -a | grep -i draft > > remotes/origin/tls1.3-draft-18 669c623 Update PR#3925 > >

Re: [openssl-project] FIPS support and sponsorship

Hi there. I’m happy to talk and can explain things based on our public statements and policies so far. I’m based in Boston. (We’ll invite anyone else from the team in case they want to attend as well.) From: Phillip Moore Reply-To: "openssl-project@openssl.org"

Re: [openssl-project] FIPS support and sponsorship

Hi there. I’m happy to talk and can explain things based on our public statements and policies so far. I’m based in Boston. (We’ll invite anyone else from the team in case they want to attend as well.) From: Phillip Moore Reply-To: "openssl-project@openssl.org"

[openssl-project] VOTE on coding style changes

This email starts a vote. Two notes: The contents of the PR are also attached. I have BCC’d openssl-project, for public notification about the vote. I’m not sure if this is the best way to do things, but it’s worth a shot. Incorporate the text topic: Incorporate

Re: [openssl-project] VOTE on coding style changes

This is an old message that had been held up in the moderator queue. Ignore it. From: Rich Salz Reply-To: "openssl-project@openssl.org" Date: Monday, April 9, 2018 at 10:02 PM To: "openssl-...@openssl.org" Subject:

[openssl-project] Vote results -- coding style

This vote failed. It was two in favor, two opposed, three no-care, and one not voting. I hope someone else will pick this up and run with it. I am closing the PR. topic: Incorporate the text of https://github.com/openssl/web/pull/43 into the coding style policy.

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

>NIST SP800-90A rev1 section 8.6.7 has: Compliance with this was never a stated goal of this release. So not relevant. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

>Like I said in the post I just made, I see zero problems with having that requirement on systems that can support it. I don't see why we must lower the bar for *everyone* just because we currently need to do so for VMS Because - It is not clear we need to do so

Re: [openssl-project] build broken?

u make a PR from this? In message <f3e1c9d0-51f2-4dea-84a6-545d1df01...@akamai.com> on Thu, 5 Apr 2018 17:18:13 +, "Salz, Rich" <rs...@akamai.com> said: rsalz> Making update rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT rsalz> rsal

[openssl-project] Some TLS 1.3 drafts don't have branches

; g branch -r -v -a | grep -i draft remotes/origin/tls1.3-draft-18 669c623 Update PR#3925 remotes/origin/tls1.3-draft-19 d4d9864 Update PR#3925 ; I recently had someone need draft-21 and they did git checkout 515982154031b679f58d5e2cbd7752294779221e Can we create

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

I have not heard that any application program -- NOT COUNTING OUR TESTS -- that break. The one counterpoint we have is that s_client/s_server work. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

We have *no* data points, except our tests, that anything fails to work. In fact, we are increasingly collecting data that shows everything is just fine. I believe we were led into the current situation, because our tests don't completely work *going backwards.* Do the 1.1.0 tests basically

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

>Would still like to know what's motivating Google's insistence on SNI... The TLS WG is probably the place to ask this. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Constant time by default

I think this is a great idea, but that it is way too late for this release. We really should be concentrating on testing and fixes, and open PR's and other release criteria. Ideally the release goes out in a month (IETF RFC editor willing) ___

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

> I believe we were led into the current situation, because our tests don't completely work *going backwards.* Do the 1.1.0 tests basically work *going forwards* ? >It is unclear what you mean by forwards and backwards, but some 1.1.0 tests failed when using a 1.1.1 library.

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

Tim and Viktor have convinced me that “it’s not worth it” is wrong. Thanks, Richard, for testing 1.1.0 tests with 1.1.1 library. We do need to analyze the results and not say any failure means something 1.1.1 has to fix – it could be failing because of an assumption in the 1.1.0 tests. Am I

Re: [openssl-project] Problems with waiting for specific person to merge

>Self assigning is a good habit... unless you have my tendencies, to *ahem* forget that you've self assigned something. There's a built-in filter that says "find my PR's" It's just on the left side of the search box. ___ openssl-project

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. David has pointed out valid use-cases. I think most use-cases will "just work." We should document the known sharp edges. ___ openssl-project

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client). That seems easy to code. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] About PR 5702, etc.

Discussion seems to have stalled out on this. Please review https://github.com/openssl/openssl/pull/5702 if necessary. Do folks want a general “TLS 1.3 is okay post-freeze” policy? I don’t know, but I think it will take too long to get to a decision. Is anyone (on the OMC) going to take that

Re: [openssl-project] Speeding up the fuzz test...

Neat. What does CPIO have over TAR? Is it better enough that it is a compelling reason to introduce yet another file format? ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

>Please note that that 50% extra is only used for instantiating the DRBG. On reseed we it only uses 256 bits. True. And now we're finding that VMS won't work. And I bet there are other systems that will also find this amount excessive. >There is an alternative to that 50%

Re: [openssl-project] Entropy seeding the DRBG

If you say that AES256 needs CSPRNG seeding with 256 bits, then why doesn't RSA 2048 keygen need seed to be seeded with 2048 bits? I am not a cryptographer, but I do not agree with this argument algorithms with a security level of 256 bit in TLS (like AES-256-CTR), so it is necessary

[openssl-project] FW: [openssl/openssl] Free allow null (#5761)

Someone want to make the PR ? From: Andy Polyakov Reply-To: openssl/openssl Date: Tuesday, March 27, 2018 at 4:07 PM To: openssl/openssl

Re: [openssl-project] About PR 5702, etc.

>"Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed during the beta as long as at least 3 OMC members approve the change" Fine. Please run the vote soon as there is not much time. ___ openssl-project mailing list

[openssl-project] Apache update

Apache trunk now supports OpenSSL’s TLS 1.3 Woo hoo! ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub milestone for 1.1.1

Yes, SM2 ECC is a big one that seems to have fallen thru the cracks. And 4848. That is *very* unfortunate. Instead time and energy went to FIXING Android, configure command-line, and various no-XXX builds. ___ openssl-project mailing list

Re: [openssl-project] Code Repo

We still have a lot of work to do to meet our release goals. It was really bad last time and we definitely lost our focus multiple times. If in two weeks we get everything done and we’re just sitting aroun waiting for the IETF to publish, great. But if not, I strongly believe the only thing we

Re: [openssl-project] Accept PR 5702 after the feature-freeze?

the feature freeze, if it is related to TLS 1.3, and approved by at > least 3 OMC members (without veto, of course) I think that's not a bad idea. See also: https://github.com/openssl/openssl/pull/5227 Matt > > Matthias >

[openssl-project] Accept PR 5702 after the feature-freeze?

https://github.com/openssl/openssl/pull/5702 It is after our declared feature-freeze. I think we should allow this PR. From the description: NSS 3.34 and boringssl have support for "EXPORTER_SECRET" (https://bugzilla.mozilla.org/show_bug.cgi?id=1287711) which is

Re: [openssl-project] Forthcoming OpenSSL releases

This should include the fix to the bug Guido found. On 3/20/18, 1:18 PM, "Matt Caswell" wrote: Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0h and

  1   2   >