Please change your mind about your announced release plans

I think the current plan, to do QUIC over a series of releases, is a mistake it seems seriously likely to make OpenSSL less relevant. Some reasons follow. According to https://www.openssl.org/blog/blog/2019/11/07/3.0-update/, the initial target for 3.0 was end of 2019, but the announced

TLS intro testing

https://github.com/xvzcf/tls-interop-runner : The TLS Interop Test Runner aims to test interoperability between implementations of TLS by running various tests involving clients and servers drawn from differing implementations. It is fashioned after the QUIC Interop Runner.

Re: #8765

I assume nobody is surprised to see me say this: I do not see a requirement to do this in 3.0. In particular, I hope that none of the contributors who already have 3.0 work spend time on this. If this is going to be considered for 3.0, I would like to know the rationale for doing so. I don’t

Re: Assigning OpenSSL 3.0.0 beta1 issues

> I thought he had a "rethinking how we deprecate" PR or issue, but I can't find it now. I think it was [#13074] (now merged). Yes it was, thanks.

Re: Assigning OpenSSL 3.0.0 beta1 issues

On 14/10/2020 17:08, Salz, Rich wrote: > I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in? > I'm not sure which of Richard's PRs you're referring to? I thought he had a "rethin

Re: Assigning OpenSSL 3.0.0 beta1 issues

I am interested in helping out with the deprecation tasks. Should I assume that Richard's PR to change how it's done will be going in?

Re: Vote proposal: Technical items still to be done

>Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it stable for many years to come. Any bugs in the API design for providers will have to live with us at least until the 4.0 release and so it

Re: Alpha releases

On 06/10/2020 15:53, Salz, Rich wrote: > Is it the project's understanding that Alpha and Beta releases are, in fact, capital-R releases and therefore subject to OMC? > That seems weird to me. Yes - that is the case at the moment. Looking at the release strategy [1] it

Re: Alpha releases

Is it the project's understanding that Alpha and Beta releases are, in fact, capital-R releases and therefore subject to OMC? That seems weird to me.

Re: Freeze?

As a sponsor of this release, we are concerned about further slippages in the schedule. I understand open source and “scratch your itch” and all that, but the project made a commitment and several companies have contributed money and/or engineering time. Some of those groups are making plans

Re: Beta1 PR deadline

>Please can anyone with PRs that they wish to have included in OpenSSL 3.0 beta1 ensure that they are merged to master by 8th September. And how are non-committers supposed to do that

Re: Backports to 1.1.1 and what is allowed

* I suggest everyone takes a read through

The hold on PR 12089

What is the timetable for resolving https://github.com/openssl/openssl/pull/12089 ? The Beta is planned for a July 16 release. There is a massive RAND/DRBG PR (https://github.com/openssl/openssl/pull/11682, the provider-friendly random) that is in the pipeline, and 12089 and 11682 will

Re: Detecting Bad OpenSSL Usage

It would be really interesting to run this over the apps. Maybe reach out to the author for help with that? From: Dmitry Belyavsky Date: Sunday, May 31, 2020 at 5:44 AM To: "openssl-project@openssl.org" Subject: Detecting Bad OpenSSL Usage Hello, Here is a nice article about a tool desired

Re: Reducing the security bits for MD5 and SHA1 in TLS

If you do this, you should add a FAQ (in addition to NEWS) explaining it.

error conversion macro's

Perhaps the next Alpha release can do the error macro conversion? Add script to convert XXXerr() to XXXerror, https://github.com/openssl/openssl/pull/9441 In particular, https://github.com/openssl/openssl/pull/9441#issuecomment-522171044 It might need updating if any new “error facility”

Re: Alpha2

>releases - we would simply do them every 3 weeks or so. I'd like to hear opinions on that proposal too. I am in favor of this, but you HAVE to keep the cadence regular: no slipping.

Re: Stale PR stats @May01

This is great transparency info. Failed CI's are a problem since it's often the fault of timeouts, or sometimes master is broken. Any thoughts on how to handle that? >So, ignoring deferred issues too you could summarise this as: Stale PRs waiting for us to do something: 27 (last

Re: CI build timeouts

* Disabling memory leak checking doesn’t sound like a great idea.. On that one platform, no?

Re: Cherry-pick proposal

I suspect that the primary motivation for this proposal is that PR’s against master often become stale because nobody on the project looks at them. And then submitters are told to rebase, fix conflicts, etc. It gets disheartening. If that is the motivation, then perhaps the project should

Re: Deprecations

>Moreover, the deprecated commands print something to the effect of: "The >command dsa is deprecated. Use ‘pkey’ instead." when executed. I hope it only does that If (isatty(0) && isatty(1) && isatty(2)) { BIO_printf(bio_errerr, “%s: This command

Re: OpenSSL Logo (was: New GitHub Project Landing Page)

For what it’s worth, during the Website redesign I asked if anyone could provide a scalable logo so that our website worked on mobile, tablets, etc. Tony Arceri sent me a pure-CSS solution that worked and looked similar.

Re: Deprecations

>A small note about the 'no-deprecated' configuration option: this is an > option to simulate the far future when the deprecated stuff has been removed > from the public eye. Deprecated openssl commands should not build with such a > configuration. How can that work? If the deprecated

Re: Deprecation

* I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. I share this concern. This is the first release of the provider infrastructure, and while it will be known to work for FIPS modules, it’s hubris to think OpenSSL

QUIC support

A month ago Tim said[2] that PR 8797[1] requires on OMC decision on “whether or not QUIC in this manner of approach should be added into OpenSSL at this time.” To save you a click, this PR adds API’s to OpenSSL so that Google’s open source QUIC implementation can be built on top of OpenSSL.

Re: Travis in solid red mode again

> Could we add a CI check for PRs that confirms that the target branch is green in travis? Looking at https://docs.travis-ci.com/user/notifications/#conditional-notifications and https://config.travis-ci.com/ref/notifications/email it seems like it should be fairly easy configure

Re: Travis in solid red mode again

>Oh, actually, maybe I'm wrong. Is it just Appveyor that posts failures and not Travis? Yes. You need to config travis to mail failures, as I pointed out in my earlier message.

Re: fips mode and key management

>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be more fitting than FIPS_MODE? Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use OPENSSL_BUILDING_OPENSSL ... There's no reason to use OSSL for internal macros.

Re: crypt(3)

* I meant “what default makes the most sense for the passwd command line application?” * It was crypt which is deprecated. Should it be BSD’s MD5? One of the SHA2 based algorithms? Or should it produce an error if no algorithm is selected? If you change the default, then the program

FW: Coverity Scan: Analysis completed for OpenSSL-1.0.2

Someone should turn off 1.0.2 :) On 1/2/20, 11:48 PM, "scan-ad...@coverity.com" wrote: Your request for analysis of OpenSSL-1.0.2 has been completed successfully. The results are available at

OTC membership?

The list of committers is at https://www.openssl.org/community/committers.html The list of OMC members is at https://www.openssl.org/community/omc.html Will there be a list of OTC members also in the community tab soon? Or a mark in the committers table?

Re: Check NULL pointers or not...

* In a production environment, it is almost never appropriate to simply crash in an uncontrolled manner (i.e. dereferencing a NULL pointer). Applications that want this can check parameters themselves before calling the function. Saying “C arguments don’t hold” is only because it goes

Re: Check NULL pointers or not...

if (!ossl_assert(ptr != NULL)) { ERR_raise(ERR_LIB_WHATEVER, ERR_R_PASSED_NULL_PARAMETER); return 0; } If the project decides to do this, I would like a configure option to ONLY turn on ossl_assert so that previous behavior can be restored without debug

Re: Malloc failures check

* It would be possible to implement a malloc failure feature in the test suite that systematically runs a test many times, failing successive malloc calls. It’s there; look crypto/mem.c, shouldfail() and FAILTEST. More detail, from off-list discusson: i=0 while : ; do

Re: Malloc failures check

* It would be possible to implement a malloc failure feature in the test suite that systematically runs a test many times, failing successive malloc calls. It’s there; look crypto/mem.c, shouldfail() and FAILTEST.

Re: #10388

>I’m more concerned about adding these to 3.0. It means we’ll have to support >the new API for a long time and it is one which we are currently trying to >move away from. Will you? Have you already decided that 3.0 is an LTS release? Otherwise, you have the LTS burden and when the rest of

Re: Confirmed bug labels

What about "proposed bug" "proposed feature" etc. And a single "accepted" label?

FW: Interview participation request

Folks, I did a Skype call with James. You might want to let him talk to you so that it’s more than just my view :) It was fun. He’s done a lot of number-crunching of OpenSSL through the years, including things like complexity (depth of nesting) and such. Maybe you can do a group-chat during

Re: RAND, FIPS and providers

FWIW, I agree with Matt's points.

Re: Thread sanitiser problems

Do you need to hold the lock across dependant items? For example, why can't the DRBG code unlock before fetching the AES-CTR code?

Re: Do we really want to have the legacy provider as opt-in only?

> If DSA is almost never used, why enable it by default? I am amused/bemused that, after years of saying we do not know what people are doing with OpenSSL, it now is now becoming common practice to blithely assert "this is not used" when it fits the personal viewpoint of some folks.

Re: Do we really want to have the legacy provider as opt-in only?

>>DSA > > What is the cryptographic weakness of DSA that you are avoiding? It's a good question. I don't recall the specific reason why that was added to the list. Perhaps others can comment. The only weakness I know about is that if you re-use the nonce, the

Re: Do we really want to have the legacy provider as opt-in only?

>DSA What is the cryptographic weakness of DSA that you are avoiding?

Re: punycode licensing

I will take the hint and stop commenting on this thread.

Re: punycode licensing

Thank you for the reply. >The license under which the OpenSSL software is provided does not require >"permission" to be sought for use of the software. See

Re: punycode licensing

* Unfortunately, the issue isn't the compatibility of the license - they do indeed look relatively compatible to me - and the discussion on this thread has so far been about that. * However the contributor license agreement requires that the copyright owner grants such permission - it

Re: Removing function names from errors (PR 9058)

I think exposing the function internals is a mistake for a couple of reasons: it encourages familiarity with, and dependence on, OpenSSL library internals, and it goes against the spirit of layering, and there is no guarantee that the function code does not change as internal code gets moved

Re: OSSL_PARAMs

* Is this workable or should something more significantly different be used before things freeze with the 3.0 release? Well, since you asked: https://github.com/openssl/openssl/pull/8377

Re: OSSL_PARAMs

>Part of the idea was that this would be a means of communication between application and provider, just like controls are with libcrypto sub-systems. I can probably find the email thread (or maybe it was a GitHub comment on my proposal for params), where you said, quite

Re: proposed change to committers policy

Nicely worded. It doesn’t go as far as I’d like, but it’s a step.

Re: No two reviewers from same company

> In that example the potential conflict of interest comes from the > individual's employment with the third party organisation, not because they are fellows. Do you disagree with my contention that the OMC represents the project, and not the fellows? Regardless of where the conflict

Re: No two reviewers from same company

> In private email, and https://github.com/openssl/openssl/pull/8886#issuecomment-494624313 the implication is that this was a policy. AFAIK this is not the case. Is the comment wrong, either factually or because it is implementing something that isn't an official policy? >

Re: No two reviewers from same company

> I understand that OpenSSL is changing things so that, by mechanism (and maybe by > policy although it’s not published yet), two members of the same company cannot > approve the same PR. That’s great. (I never approved Akamai requests unless it > was trivial back when I was

Re: Update

>> I'd be opposed to this last option without IANA/IETF being on board. By doing so >we are effectively no longer compliant with IETF TLS since we're using certain >codepoints and version numbers to mean things that IETF/IANA have no visibility >of, i.e. we would be

Re: Update

> I'd be opposed to this last option without IANA/IETF being on board. By > doing so we are effectively no longer compliant with IETF TLS since we're using certain codepoints and version numbers to mean things that IETF/IANA have no visibility of, i.e. we would be doing

Re: Update

>I don't see it that way. As I understand it this is a completely different protocol to standard TLS. That's an interesting point, but ... they use the SSL "name." > It is not intended to interoperate with it in any way. Is that true? I didn't look closely at the protocol changes, but

Re: Update

* The current requirement for inclusion is “national

Re: SP 800-90C 10.1.2

No love from Akamai for this: it seems to be done for completionist reasons and it seems risky. From: "paul.d...@oracle.com" Date: Tuesday, April 9, 2019 at 8:07 PM To: "fips-spons...@openssl.org" Cc: "openssl-project@openssl.org" Subject: SP 800-90C 10.1.2 Do any of the FIPS sponsors or

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

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

[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

[openssl-project] TLS 1.3 and the release

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

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. :)

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] 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?

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?

; 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] 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

[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] 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] 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] 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

>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] 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] [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

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

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

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

[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] 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. ___

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

>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

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

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

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

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

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

  1   2   >