From appro at openssl.org  Thu Mar  1 09:59:53 2018
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 1 Mar 2018 10:59:53 +0100
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>

>>> I'd like to request more opinions on
>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>> whether or not following fragment should work
>>>
>>>     unsigned char *inp = buf, *out = buf;
>>>
>>>     for (i = 0; i < sizeof(buf); i++) {
>>>         EVP_EncryptUpdate(ctx, out, &outl, inp++, 1);
>>> 	out += outl;
>>>     }
>>
>> This should work.
>>
> 
> It does only work, if you know that ctx->buf_len == 0
> before the loop is entered.

It's naturally implied that ctx is used *consistently*. I mean it's not
like it's suggested that you can just use the above snippet in random
place. Application would have to adhere to above pattern all along, for
the life time of in-place processing "session". [I write "session" in
quotes, because there might be better term.]

> It does not work with CFB1, CCM, XTS and WRAP modes.

Yes, some modes are so to say "one-shot", i.e. you have to pass all the
data there is at once, no increments are allowed. But what does it have
to do with question at hand, question about in-place processing that is?
These two things are independent. So that question is rather should the
snippet work in cases when incremental processing is an option. Related
thing to recognize in the context is that *disputable* condition, the
one that triggered this discussion, is exercised only when
ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
it's special...

> There is no access function to get the internal state of the cipher
> context.

But there is notion of in-place processing "session".

> I the documentation does not cover this at all, and most of
> all I really wonder how the wording could look like.

That in-place processing "session" would be customarily tied up with
call to EVP_EncryptFinal[_ex]?

From appro at openssl.org  Thu Mar  1 10:13:43 2018
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 1 Mar 2018 11:13:43 +0100
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
Message-ID: <47e9aa8f-57c4-7b1c-193b-1a87b61320f9@openssl.org>

> Related
> thing to recognize in the context is that *disputable* condition, the
> one that triggered this discussion, is exercised only when
> ctx->block_size is larger than 1, because then ctx->buf_len remains 0.

I naturally meant "because *otherwise* ctx->buf_len remains 0". In other
words ctx->buf_len remains 0 when ctx->block_size is 1.

From rsalz at akamai.com  Thu Mar  1 12:09:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 1 Mar 2018 12:09:41 +0000
Subject: [openssl-project] FW: [openssl-commits] Still Failing:
 winnerof2010/openssl#8 (master - 6f7c7aa)
In-Reply-To: <5a97898bcd3d8_43fddc03b4c68123297b@9241f5fa-6535-416d-b41e-76f178fb84b5.mail>
References: <5a97898bcd3d8_43fddc03b4c68123297b@9241f5fa-6535-416d-b41e-76f178fb84b5.mail>
Message-ID: <20B91FBF-65AA-43CA-93CE-23F6E9F7BA88@akamai.com>

I thought our travis setup was so that other forks could not send email to our mailing list.

From: Travis CI <builds at travis-ci.org>
Date: Thursday, March 1, 2018 at 12:19 AM
To: "openssl-commits at openssl.org" <openssl-commits at openssl.org>
Subject: [openssl-commits] Still Failing: winnerof2010/openssl#8 (master - 6f7c7aa)

[https://avatars2.githubusercontent.com/u/16300432?v=4?s=40&d=https%3A%2F%2Ftravis-ci.org%2Fimages%2Fmailer%2Fmascot-avatar-40px.png]winnerof2010 / openssl<https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_winnerof2010_openssl-3Futm-5Fsource-3Demail-26utm-5Fmedium-3Dnotification&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=ranHB8LWf7O3RvzxcwOxw5AfvojEYjO6WgmyJgZj3XQ&e=> (master<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_winnerof2010_openssl_tree_master&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=bZqgvdLEAzp73FYbbga--t4y8NqkBaI6srPSv9ZupDY&e=>)


[https://travis-ci.org/images/mailer/failed.png]

Build #8 is still failing.<https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_winnerof2010_openssl_builds_347594907-3Futm-5Fsource-3Demail-26utm-5Fmedium-3Dnotification&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=fDR9W140_LkMvef_8cFJIz2MciJix3r523hhDajcQwQ&e=>[https://travis-ci.org/images/mailer/arrow-failed.png]

[https://travis-ci.org/images/mailer/stopwatch-failed.png]
44 minutes and 42 seconds

[https://secure.gravatar.com/avatar/eda66fcb4f9c4798ce0b84d54044dcce?s=15&d=https%3A%2F%2Ftravis-ci.org%2Fimages%2Fmailer%2Fmascot-avatar-15px.png]

winnerof2010

6f7c7aa<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_winnerof2010_openssl_commit_6f7c7aa6ac58fac31fa8cf53cea2d9995d59b074&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=GS7pqUbOKN5xNXyJREeo7a3Blnb4W9C1a5Jmuvl-mJk&e=> Changeset ?<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_winnerof2010_openssl_compare_d38d93a51da1...6f7c7aa6ac58&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=lp9d8kL0JRVszkusjHhW7UYrJ_s-UP7WkCP2KY-Hrew&e=>



Added Jenkinsfile


Want to know about upcoming build environment updates?

Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here<https://urldefense.proofpoint.com/v2/url?u=http-3A__eepurl.com_9OCsP&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=tdNpVGfScrGs3va5c3ZvItM7_dRlK5dHICxgN01jrpw&e=>.
[https://travis-ci.org/images/mailer/email-footer-travis-logo.png]

Documentation<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.travis-2Dci.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=qYx-MBUebHb0U9kDCcNch8Kf_WArsd6fTnB_xEB6Hiw&e=> about Travis CI
Need help? Mail support<mailto:support at travis-ci.com>!
Choose who receives these build notification emails in your configuration file<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.travis-2Dci.com_user_notifications&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=MO1B-btV1RWCvt1giFWxyck42LUTonMNwFQlA2nxHuw&e=>.

[https://travis-ci.org/images/mailer/travis-mascot.png]

Would you like to test your private code?

Travis CI for Private Projects<https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.com-3Futm-5Fsource-3Dbuild-5Femail-5Ffooter-26utm-5Fcampaign-3Dtravis-2Dci.org-26utm-5Fmedium-3Demail&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=SK_0Xf46Ar4cyUUhMcn7issb0Jc6s8py4qjOrCL-oEI&s=Fe6p3G1HEsGgnx7PgU7Z57pGQSAt9xzrgSjSCl-tzo4&e=> could be your new best friend!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180301/8309ab7e/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180301/8309ab7e/attachment-0001.txt>

From matt at openssl.org  Fri Mar  2 11:09:30 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 2 Mar 2018 11:09:30 +0000
Subject: [openssl-project] Next release is beta1
Message-ID: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>

Just a reminder, in case anyone missed it, that our next planned release
on 13th March is beta1. This means we will be calling a feature freeze
for 1.1.1 and we will create the new branch. If you've got any
outstanding feature PRs that you want in for 1.1.1 - then now is the
time to get them finished off!

Matt

From bernd.edlinger at hotmail.de  Sat Mar  3 12:25:48 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Sat, 3 Mar 2018 12:25:48 +0000
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
Message-ID: <AM5PR0701MB265749D8ADC8C14E1BFB236CE4C40@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 03/01/18 10:59, Andy Polyakov wrote:
>>>> I'd like to request more opinions on
>>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>>> whether or not following fragment should work
>>>>
>>>>      unsigned char *inp = buf, *out = buf;
>>>>
>>>>      for (i = 0; i < sizeof(buf); i++) {
>>>>          EVP_EncryptUpdate(ctx, out, &outl, inp++, 1);
>>>> 	out += outl;
>>>>      }
>>>
>>> This should work.
>>>
>>
>> It does only work, if you know that ctx->buf_len == 0
>> before the loop is entered.
> 
> It's naturally implied that ctx is used *consistently*. I mean it's not
> like it's suggested that you can just use the above snippet in random
> place. Application would have to adhere to above pattern all along, for
> the life time of in-place processing "session". [I write "session" in
> quotes, because there might be better term.]
> 
>> It does not work with CFB1, CCM, XTS and WRAP modes.
> 
> Yes, some modes are so to say "one-shot", i.e. you have to pass all the
> data there is at once, no increments are allowed. But what does it have
> to do with question at hand, question about in-place processing that is?
> These two things are independent. So that question is rather should the
> snippet work in cases when incremental processing is an option. Related
> thing to recognize in the context is that *disputable* condition, the
> one that triggered this discussion, is exercised only when
> ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
> Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
> it's special...
> 
>> There is no access function to get the internal state of the cipher
>> context.
> 
> But there is notion of in-place processing "session".
> 

Well, I'd say, apparently the consensus is at least not to restrict
what is currently recognized as "fully" overlapping.

All depends obviously on how "partially" overlapping is defined:
a) by humans
b) by OpenSSL

a)
I think humans would normally say two objects are partially overlapping
when they overlap, but do not fully overlap, in other words partially
overlapping in and out do have some common bytes, but do not start at
the same address, thus in != out.

b)
What is currently recognized as partially overlapping in the evp_enc.c
is a) but adds some I would say ad-hoc exceptions to accommodate one
special use case with certain block ciphers.  Yet it does for instance
artificially restrict use cases where other ciphers work just fine.

I think for instance of WRAP mode, where the primitive basically
supports arbitrary overlapping (uses memmove) but we can no longer
use that feature because of the partially overlapping check in the
EVP cipher handling.

And the other use case, which I think is worth to mention is

unsigned char *inp = buf + sizeof(buf) - 1, *out = buf;
for (i = 0; i<sizeof(buf)-X; i++) {
     *inp = getc();
     EVP_EncryptUpdate(ctx, out, &outl, inp, 1);
     out += outl;
}

This could work for some cipher modes at least.

And I think our overall assumption here is the user knows perfectly
well how the internal state of the ctx is at any time, otherwise
EVP_EncryptUpdate would probably need to have an input parameter to
tell how large the output buffer is in reality :)

So I think maybe we can just change the definition for b) to be

Partially overlapping is any kind of overlapping that is known to be
not working in the evp cipher update function.
It is dependent on the cipher mode, and dependent on the internal state
of the cipher context.

It is often the case that partially overlapping means overlapping
with in != out but most importantly the code in evp_enc.c is known
to fail if it was allowed to continue after EVP_R_PARTIALLY_OVERLAPPING.


Bernd.

From kurt at roeckx.be  Sun Mar  4 12:57:05 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 4 Mar 2018 13:57:05 +0100
Subject: [openssl-project] Next release is beta1
In-Reply-To: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
Message-ID: <20180304125705.GA25882@roeckx.be>

On Fri, Mar 02, 2018 at 11:09:30AM +0000, Matt Caswell wrote:
> Just a reminder, in case anyone missed it, that our next planned release
> on 13th March is beta1. This means we will be calling a feature freeze
> for 1.1.1 and we will create the new branch. If you've got any
> outstanding feature PRs that you want in for 1.1.1 - then now is the
> time to get them finished off!

The other option is that we delay going to beta, but then people
would need to speak up now about what they would like to see
happen before going to beta.


Kurt


From rsalz at akamai.com  Sun Mar  4 14:39:33 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 4 Mar 2018 14:39:33 +0000
Subject: [openssl-project] Next release is beta1
In-Reply-To: <20180304125705.GA25882@roeckx.be>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
Message-ID: <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>

Kurt raises an excellent point.

I want this in the release:
	https://github.com/openssl/openssl/pull/5438

I want discussion about these two, hopefully concluding that they be in the release:
	https://github.com/openssl/openssl/pull/5326
	https://github.com/openssl/openssl/pull/5320

?On 3/4/18, 7:57 AM, "Kurt Roeckx" <kurt at roeckx.be> wrote:

    On Fri, Mar 02, 2018 at 11:09:30AM +0000, Matt Caswell wrote:
    > Just a reminder, in case anyone missed it, that our next planned release
    > on 13th March is beta1. This means we will be calling a feature freeze
    > for 1.1.1 and we will create the new branch. If you've got any
    > outstanding feature PRs that you want in for 1.1.1 - then now is the
    > time to get them finished off!
    
    The other option is that we delay going to beta, but then people
    would need to speak up now about what they would like to see
    happen before going to beta.
    
    
    Kurt
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From rsalz at akamai.com  Sun Mar  4 14:44:01 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 4 Mar 2018 14:44:01 +0000
Subject: [openssl-project] Next release is beta1
In-Reply-To: <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
 <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
Message-ID: <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>

I also intend to merge the config file .include PR (5351), and I want us to decide about 4848.  With new protocol verison and its required new ciphers coming into this release, *now* is the time.


?On 3/4/18, 9:39 AM, "Salz, Rich" <rsalz at akamai.com> wrote:

    Kurt raises an excellent point.
    
    I want this in the release:
    	https://github.com/openssl/openssl/pull/5438
    
    I want discussion about these two, hopefully concluding that they be in the release:
    	https://github.com/openssl/openssl/pull/5326
    	https://github.com/openssl/openssl/pull/5320
    
    On 3/4/18, 7:57 AM, "Kurt Roeckx" <kurt at roeckx.be> wrote:
    
        On Fri, Mar 02, 2018 at 11:09:30AM +0000, Matt Caswell wrote:
        > Just a reminder, in case anyone missed it, that our next planned release
        > on 13th March is beta1. This means we will be calling a feature freeze
        > for 1.1.1 and we will create the new branch. If you've got any
        > outstanding feature PRs that you want in for 1.1.1 - then now is the
        > time to get them finished off!
        
        The other option is that we delay going to beta, but then people
        would need to speak up now about what they would like to see
        happen before going to beta.
        
        
        Kurt
        
        _______________________________________________
        openssl-project mailing list
        openssl-project at openssl.org
        https://mta.openssl.org/mailman/listinfo/openssl-project
        
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From kurt at roeckx.be  Sun Mar  4 16:30:32 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 4 Mar 2018 17:30:32 +0100
Subject: [openssl-project] Next release is beta1
In-Reply-To: <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
 <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
 <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>
Message-ID: <20180304163031.GA1453@roeckx.be>

On Sun, Mar 04, 2018 at 02:44:01PM +0000, Salz, Rich wrote:
> I also intend to merge the config file .include PR (5351), and I want us to decide about 4848.

I have to agree that I want to resolv 4848 (reading config file to
select things like supported ciphers.)

An other important change is related to cipher selection and TLS
1.3, not sure what the status there is.

There is also still work going on related to the DRBG API.


Kurt


From kaduk at mit.edu  Mon Mar  5 01:35:24 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Sun, 4 Mar 2018 19:35:24 -0600
Subject: [openssl-project] Next release is beta1
In-Reply-To: <20180304163031.GA1453@roeckx.be>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
 <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
 <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>
 <20180304163031.GA1453@roeckx.be>
Message-ID: <20180305013524.GL50954@kduck.kaduk.org>

On Sun, Mar 04, 2018 at 05:30:32PM +0100, Kurt Roeckx wrote:
> On Sun, Mar 04, 2018 at 02:44:01PM +0000, Salz, Rich wrote:
> > I also intend to merge the config file .include PR (5351), and I want us to decide about 4848.
> 
> I have to agree that I want to resolv 4848 (reading config file to
> select things like supported ciphers.)

So far my personal opinion on this one is that I'd rather wait until
1.2 and actually change the SSL_CTX_new() behavior, as opposed to
having to add a new API that not much software would be using.  (To
be clear, I think that changing SSL_CTX_new() to read a systemwide
config file is inconsistent with our API stability policy for dot
releases.)  This is perhaps complicated by the interplay with #2397,
which also wants to extend SSL_CTX_new() for sharing session caches
between SSL_CTXes.  (This behavior inherently requires a new API.)

-Ben

From Matthias.St.Pierre at ncp-e.com  Mon Mar  5 08:09:55 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Mon, 5 Mar 2018 09:09:55 +0100
Subject: [openssl-project] Next release is beta1
In-Reply-To: <20180304163031.GA1453@roeckx.be>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
 <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
 <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>
 <20180304163031.GA1453@roeckx.be>
Message-ID: <799ed45c-cf9e-bd22-29fc-017eec7852d8@ncp-e.com>

Am 04.03.2018 um 17:30 schrieb Kurt Roeckx:
> There is also still work going on related to the DRBG API.

Kurt convinced me that the DRBG backend (the reseeding) needs some
adjustments in order to comply to NIST SP 800-90C. This applies in
particular to the prediction_resistance feature. And there might be more
changes required in the course of the future FIPS evaluation. Since
these questions affect only the FIPS certification, my suggestion is to
postpone major adjustments for NIST SP 800-90C compliance to post-1.1.1
and not start overhauling the DRBG shortly before the code freeze. The
new CSPRNG implentation is already much better than the one we had in
1.1.0, even if it is not fully compliant yet.

The recommendation for postponing changes does not apply to the
following pull requests which are already en queue. In particular it is
reasonable to  have the change of the get_entropy callback signature
(#5402) merged before the freeze.

    https://github.com/openssl/openssl/pull/5402
    https://github.com/openssl/openssl/pull/5503
    https://github.com/openssl/openssl/pull/5506

In view of the above said, I will refrain from publishing (and
documenting) the RAND_POOL API and will only publish the RAND_DRBG API 
(TBD).

    https://github.com/openssl/openssl/pull/5461
    https://github.com/openssl/openssl/pull/5462

Matthias




From matt at openssl.org  Mon Mar  5 09:12:56 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 5 Mar 2018 09:12:56 +0000
Subject: [openssl-project] Next release is beta1
In-Reply-To: <20180304163031.GA1453@roeckx.be>
References: <693891fd-0eb8-2222-c39f-6ae4e41215d0@openssl.org>
 <20180304125705.GA25882@roeckx.be>
 <6725C8D6-DFAB-4AC0-B45C-76C205F008DA@akamai.com>
 <A7698105-FDB1-46B4-9942-0297C3ACC375@akamai.com>
 <20180304163031.GA1453@roeckx.be>
Message-ID: <66223a51-762d-427c-da6b-a1b7bf2b789d@openssl.org>



On 04/03/18 16:30, Kurt Roeckx wrote:
> On Sun, Mar 04, 2018 at 02:44:01PM +0000, Salz, Rich wrote:
>> I also intend to merge the config file .include PR (5351), and I want us to decide about 4848.
> 
> I have to agree that I want to resolv 4848 (reading config file to
> select things like supported ciphers.)
> 
> An other important change is related to cipher selection and TLS
> 1.3, not sure what the status there is.

Yes, this is a good point. That does need to go in before beta.

https://github.com/openssl/openssl/pull/5392

The status is that, although there has been some discussion on the PR,
no one has started to review it yet. Hint hint! Anyone?

Matt

From matt at openssl.org  Mon Mar  5 12:34:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 5 Mar 2018 12:34:06 +0000
Subject: [openssl-project] Monthly Status Report (February)
Message-ID: <a3b859d7-7030-e6e1-bb3d-dcc297b962ba@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Performed both the alpha1 and alpha2 1.1.1 releases
- Completed work on the primitives, EVP layer and TLS implementation for
X448 and Ed448.
- Updated the TLSv1.3 blog post on the latest information
- Implemented a PR for solving the issue where legacy ciphersuite
configuration can end up disabling all TLSV1.3 ciphersuites leading to
connection failures.
- Fixed some documentation issues with Middlebox compat mode
- Enabled TLSv1.3 by default
- Fixed various no- options (no-nextprotoneg, no-chacha, no-poly1305,
no-tls1_2)
- Resolved an issue where the Finished MAC was being calculated twice
- Fixed an interoperability issue due to overestimating the ticket age
by up to 1s
- Reviewed a lot of the outstanding Coverity issues and implemented
fixes for a number of them
- Updates for TLSv1.3 draft-24
- Investigated and fixed an issue in TLSProxy where a spurious
additional byte was being sent
- Investigated issues associated with a crash in the ca app (there is
some ongoing work associated with this issue).
- Currently working on improving the EVP API for curves 25519 and 448.
- Performed some interoperability testing (mainly focused on X448/Ed448)
with a few other implementations and fixed some issues as a result

Matt

From matt at openssl.org  Mon Mar  5 16:34:51 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 5 Mar 2018 16:34:51 +0000
Subject: [openssl-project] Looking for Christophe Renou
Message-ID: <8096e4c7-5372-6b72-52a6-24f624f0bb7a@openssl.org>

Hi all

As many of you know we are looking to change the licence for OpenSSL to
the Apache Licence. To do that we are trying to trace all previous
committers.

We have a small number of people left to find. See:

https://license.openssl.org/trying-to-find

Of these one stands out as being a particularly large commit. We are
very keen to track down one of the authors of this commit:

<christophe.renou at edelweb.fr>
    57 +5105 -602 edc032b5 2011-03-12 Add SRP support.

https://github.com/openssl/openssl/commit/edc032b5

If anyone can help us find Christophe that would be much appreciated.

Please send any information you might have on how we can contact
Christophe (or any of the other people in the above trying-to-find list)
to license at openssl.org (please don't reply to this list).

Thanks

Matt

From bernd.edlinger at hotmail.de  Tue Mar  6 16:31:09 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Tue, 6 Mar 2018 16:31:09 +0000
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
Message-ID: <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>

Hi,

Andy pointed out that my last e-mail was probably not clear enough.

I want to drop the current partially overlapping checks
on the WRAP mode ciphers (which were ineffective anyways).

And allow the following additional use case for any cipher

unsigned char *in = buf + sizeof(buf) - X, *out = buf;
EVP_EncryptUpdate(ctx, out, &outl, &head, sizeof(head));
out += outl;
EVP_EncryptUpdate(ctx, out, &outl, in, X);
out += outl;
EVP_EncryptUpdate(ctx, out, &outl, &tail, sizeof(tail));
out += outl;

with X > 75% sizeof(buf)
sizeof(head), sizeof(tail) not necessary multiple of block size

And make the definition of allowed in-place partially overlapping
effectively be driven by the implementation requirements.


Bernd.

On 03/03/18 13:25, Bernd Edlinger wrote:
> On 03/01/18 10:59, Andy Polyakov wrote:
>>>>> I'd like to request more opinions on
>>>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>>>> whether or not following fragment should work
>>>>>
>>>>> ???? unsigned char *inp = buf, *out = buf;
>>>>>
>>>>> ???? for (i = 0; i < sizeof(buf); i++) {
>>>>> ???????? EVP_EncryptUpdate(ctx, out, &outl, inp++, 1);
>>>>> ????out += outl;
>>>>> ???? }
>>>>
>>>> This should work.
>>>>
>>>
>>> It does only work, if you know that ctx->buf_len == 0
>>> before the loop is entered.
>>
>> It's naturally implied that ctx is used *consistently*. I mean it's not
>> like it's suggested that you can just use the above snippet in random
>> place. Application would have to adhere to above pattern all along, for
>> the life time of in-place processing "session". [I write "session" in
>> quotes, because there might be better term.]
>>
>>> It does not work with CFB1, CCM, XTS and WRAP modes.
>>
>> Yes, some modes are so to say "one-shot", i.e. you have to pass all the
>> data there is at once, no increments are allowed. But what does it have
>> to do with question at hand, question about in-place processing that is?
>> These two things are independent. So that question is rather should the
>> snippet work in cases when incremental processing is an option. Related
>> thing to recognize in the context is that *disputable* condition, the
>> one that triggered this discussion, is exercised only when
>> ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
>> Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
>> it's special...
>>
>>> There is no access function to get the internal state of the cipher
>>> context.
>>
>> But there is notion of in-place processing "session".
>>
> 
> Well, I'd say, apparently the consensus is at least not to restrict
> what is currently recognized as "fully" overlapping.
> 
> All depends obviously on how "partially" overlapping is defined:
> a) by humans
> b) by OpenSSL
> 
> a)
> I think humans would normally say two objects are partially overlapping
> when they overlap, but do not fully overlap, in other words partially
> overlapping in and out do have some common bytes, but do not start at
> the same address, thus in != out.
> 
> b)
> What is currently recognized as partially overlapping in the evp_enc.c
> is a) but adds some I would say ad-hoc exceptions to accommodate one
> special use case with certain block ciphers.? Yet it does for instance
> artificially restrict use cases where other ciphers work just fine.
> 
> I think for instance of WRAP mode, where the primitive basically
> supports arbitrary overlapping (uses memmove) but we can no longer
> use that feature because of the partially overlapping check in the
> EVP cipher handling.
> 
> And the other use case, which I think is worth to mention is
> 
> unsigned char *inp = buf + sizeof(buf) - 1, *out = buf;
> for (i = 0; i<sizeof(buf)-X; i++) {
>  ??? *inp = getc();
>  ??? EVP_EncryptUpdate(ctx, out, &outl, inp, 1);
>  ??? out += outl;
> }
> 
> This could work for some cipher modes at least.
> 
> And I think our overall assumption here is the user knows perfectly
> well how the internal state of the ctx is at any time, otherwise
> EVP_EncryptUpdate would probably need to have an input parameter to
> tell how large the output buffer is in reality :)
> 
> So I think maybe we can just change the definition for b) to be
> 
> Partially overlapping is any kind of overlapping that is known to be
> not working in the evp cipher update function.
> It is dependent on the cipher mode, and dependent on the internal state
> of the cipher context.
> 
> It is often the case that partially overlapping means overlapping
> with in != out but most importantly the code in evp_enc.c is known
> to fail if it was allowed to continue after EVP_R_PARTIALLY_OVERLAPPING.
> 
> 
> Bernd.

From rsalz at akamai.com  Wed Mar  7 01:20:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 7 Mar 2018 01:20:41 +0000
Subject: [openssl-project] External contributors and the next release
Message-ID: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>

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 team, only third-party existing pull requests will be considered
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180307/ecde2a5d/attachment-0001.html>

From kaduk at mit.edu  Wed Mar  7 04:40:12 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 6 Mar 2018 22:40:12 -0600
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
Message-ID: <20180307044012.GJ27850@kduck.kaduk.org>

On Wed, Mar 07, 2018 at 01:20:41AM +0000, Salz, Rich wrote:
> 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.

I agree.  I started looking at this last week, when we had something
like 170 open issues+pull requests for the 1.1.1 milestone.  We
still have 165, and that excludes a couple things that I would like
to see get in but are not part of the milestone (like #3082 and
#1130).  I also have several changes open myself that are small and
could easily go in, though none of them are especially critical.
(Richard, could you reconfirm on #3958, though, please?)

> 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 team, only third-party existing pull requests will be considered

I'm open to extending the date, though am interested to see what we
can do if everybody chips in this week.  (Though, I myself will only
be able to start on Friday, as my next couple days are fully
booked.)

-Ben

From tjh at openssl.org  Wed Mar  7 05:01:03 2018
From: tjh at openssl.org (Tim Hudson)
Date: Wed, 7 Mar 2018 15:01:03 +1000
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <20180307044012.GJ27850@kduck.kaduk.org>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
 <20180307044012.GJ27850@kduck.kaduk.org>
Message-ID: <CAHEJ-S4xNhkpc8R7vJaewOY5ODTs71JTtsuEUw3Vi1LATR9j+g@mail.gmail.com>

If you are blocked on review please drop a note (like the one you just did)
to the group.
Some of us review the specifically blocked things when such notes are sent.

#3082 is already closed and merged - did you mean another PR?
#3958 approved (in case Richard doesn't get back to it)
#1130 approved
#3958 approved

Tim.



On Wed, Mar 7, 2018 at 2:40 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Wed, Mar 07, 2018 at 01:20:41AM +0000, Salz, Rich wrote:
> > 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.
>
> I agree.  I started looking at this last week, when we had something
> like 170 open issues+pull requests for the 1.1.1 milestone.  We
> still have 165, and that excludes a couple things that I would like
> to see get in but are not part of the milestone (like #3082 and
> #1130).  I also have several changes open myself that are small and
> could easily go in, though none of them are especially critical.
> (Richard, could you reconfirm on #3958, though, please?)
>
> > 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 team, only third-party existing
> pull requests will be considered
>
> I'm open to extending the date, though am interested to see what we
> can do if everybody chips in this week.  (Though, I myself will only
> be able to start on Friday, as my next couple days are fully
> booked.)
>
> -Ben
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180307/65bd91e8/attachment.html>

From kaduk at mit.edu  Wed Mar  7 05:04:11 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 6 Mar 2018 23:04:11 -0600
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <CAHEJ-S4xNhkpc8R7vJaewOY5ODTs71JTtsuEUw3Vi1LATR9j+g@mail.gmail.com>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
 <20180307044012.GJ27850@kduck.kaduk.org>
 <CAHEJ-S4xNhkpc8R7vJaewOY5ODTs71JTtsuEUw3Vi1LATR9j+g@mail.gmail.com>
Message-ID: <20180307050410.GM27850@kduck.kaduk.org>

On Wed, Mar 07, 2018 at 03:01:03PM +1000, Tim Hudson wrote:
> If you are blocked on review please drop a note (like the one you just did)
> to the group.
> Some of us review the specifically blocked things when such notes are sent.
> 
> #3082 is already closed and merged - did you mean another PR?

Yup, I meant #3802, sorry.
(tmshort is my team lead at work)

> #3958 approved (in case Richard doesn't get back to it)
> #1130 approved
> #3958 approved

Thanks!

-Ben

> Tim.
> 
> 
> 
> On Wed, Mar 7, 2018 at 2:40 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> > On Wed, Mar 07, 2018 at 01:20:41AM +0000, Salz, Rich wrote:
> > > 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.
> >
> > I agree.  I started looking at this last week, when we had something
> > like 170 open issues+pull requests for the 1.1.1 milestone.  We
> > still have 165, and that excludes a couple things that I would like
> > to see get in but are not part of the milestone (like #3082 and
> > #1130).  I also have several changes open myself that are small and
> > could easily go in, though none of them are especially critical.
> > (Richard, could you reconfirm on #3958, though, please?)
> >
> > > 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 team, only third-party existing
> > pull requests will be considered
> >
> > I'm open to extending the date, though am interested to see what we
> > can do if everybody chips in this week.  (Though, I myself will only
> > be able to start on Friday, as my next couple days are fully
> > booked.)
> >
> > -Ben
> > _______________________________________________
> > openssl-project mailing list
> > openssl-project at openssl.org
> > https://mta.openssl.org/mailman/listinfo/openssl-project
> >

> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


From openssl-users at dukhovni.org  Wed Mar  7 05:37:45 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 7 Mar 2018 00:37:45 -0500
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <20180307044012.GJ27850@kduck.kaduk.org>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
 <20180307044012.GJ27850@kduck.kaduk.org>
Message-ID: <FE864B26-8F31-4B38-A56C-04B9040D4CB5@dukhovni.org>



> On Mar 6, 2018, at 11:40 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
>> 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 team, only third-party existing pull requests will be considered
> 
> I'm open to extending the date, though am interested to see what we
> can do if everybody chips in this week.  (Though, I myself will only
> be able to start on Friday, as my next couple days are fully
> booked.)

I would like to see my OCSP enhancement go through.  Matt mostly
finished reviewing it, and I addressed the various style issues.
I won't be adding anything new, but would like to not have the
pending PR excluded from consideration.

And yes, reviewing more PRs makes sense.

-- 
	Viktor.


From levitte at openssl.org  Wed Mar  7 07:47:43 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 07 Mar 2018 08:47:43 +0100 (CET)
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
Message-ID: <20180307.084743.141047820720114299.levitte@openssl.org>

In message <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E at akamai.com> on Wed, 7 Mar 2018 01:20:41 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I think we should make sure to set aside time to review as many
rsalz> of the non-project pull requests as possible. I think it is
rsalz> important to show a commitment to the larger community.

I agree.

rsalz> One way to do this is to say that we will extend the BETA date
rsalz> by a week, and in that week no new code from the team, only
rsalz> third-party existing pull requests will be considered

I like this idea.  +1

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From Matthias.St.Pierre at ncp-e.com  Thu Mar  8 09:29:53 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 8 Mar 2018 10:29:53 +0100
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <CAHEJ-S4xNhkpc8R7vJaewOY5ODTs71JTtsuEUw3Vi1LATR9j+g@mail.gmail.com>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
 <20180307044012.GJ27850@kduck.kaduk.org>
 <CAHEJ-S4xNhkpc8R7vJaewOY5ODTs71JTtsuEUw3Vi1LATR9j+g@mail.gmail.com>
Message-ID: <a36550a7-3e98-e008-d081-11cd2c553032@ncp-e.com>


> If you are blocked on review please drop a note (like the one you just
> did) to the group.?
> Some of us review the specifically blocked things when such notes are
> sent.
>

I will try hard to complete the documentation for the RAND_DRBG api
until saturday. And I would be happy if #5461 and #5462 would make it
into the beta release.

I also agree that it is a good idea to look through the outstanding
third party pull requests.

Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180308/1f659255/attachment-0001.html>

From appro at openssl.org  Thu Mar  8 11:06:47 2018
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 8 Mar 2018 12:06:47 +0100
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
 <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>


> Andy pointed out that my last e-mail was probably not clear enough.
> 
> I want to drop the current partially overlapping checks
> on the WRAP mode ciphers (which were ineffective anyways).
> 
> And allow the following additional use case for any cipher
> 
> unsigned char *in = buf + sizeof(buf) - X, *out = buf;
> EVP_EncryptUpdate(ctx, out, &outl, &head, sizeof(head));
> out += outl;
> EVP_EncryptUpdate(ctx, out, &outl, in, X);
> out += outl;
> EVP_EncryptUpdate(ctx, out, &outl, &tail, sizeof(tail));
> out += outl;
> 
> with X > 75% sizeof(buf)
> sizeof(head), sizeof(tail) not necessary multiple of block size
> 
> And make the definition of allowed in-place partially overlapping
> effectively be driven by the implementation requirements.

Nobody? OK. *Formal* objection to this is that you are making assumption
that underlying implementation processes data in specific order. Note
that it's not actually unreasonable assumption(*), yet in most general
sense it's an assumption, and question rather is if you are in position
to **formally** make it(**). One can argue that all our underlying
implementations do that, process data in expected order that is, but it
doesn't lift the question. One can even argue that suggested code worked
in 1.0.1, yet it doesn't lift the question. So instead one simply aims
for not making the assumption [or making least amount of assumptions].
Yes, you can sense contradiction, because in-place processing also rests
on an assumption. Yeah, world is not ideal and life is full of
compromises. I mean there are pros and cons, and in-place is considered
to bring more pros.

(*) And in some cases it's even 100% justified, most notably in CBC
encrypt case, when each block is dependent on previous.

(**) Note that you can avoid the question by processing data strictly on
per-block basis, so that you'll be in control of accessing data in
specific order, not underlying implementation. But that's not what is
suggested, right?

From bernd.edlinger at hotmail.de  Fri Mar  9 16:13:30 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 9 Mar 2018 16:13:30 +0000
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
 <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>
Message-ID: <AM5PR0701MB26579B27806AF68A1BB5968CE4DE0@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 03/08/18 12:06, Andy Polyakov wrote:
> 
>> Andy pointed out that my last e-mail was probably not clear enough.
>>
>> I want to drop the current partially overlapping checks
>> on the WRAP mode ciphers (which were ineffective anyways).
>>
>> And allow the following additional use case for any cipher
>>
>> unsigned char *in = buf + sizeof(buf) - X, *out = buf;
>> EVP_EncryptUpdate(ctx, out, &outl, &head, sizeof(head));
>> out += outl;
>> EVP_EncryptUpdate(ctx, out, &outl, in, X);
>> out += outl;
>> EVP_EncryptUpdate(ctx, out, &outl, &tail, sizeof(tail));
>> out += outl;
>>
>> with X > 75% sizeof(buf)
>> sizeof(head), sizeof(tail) not necessary multiple of block size
>>
>> And make the definition of allowed in-place partially overlapping
>> effectively be driven by the implementation requirements.
> 
> Nobody? OK. *Formal* objection to this is that you are making assumption
> that underlying implementation processes data in specific order. Note
> that it's not actually unreasonable assumption(*), yet in most general
> sense it's an assumption, and question rather is if you are in position
> to **formally** make it(**). One can argue that all our underlying
> implementations do that, process data in expected order that is, but it
> doesn't lift the question. One can even argue that suggested code worked
> in 1.0.1, yet it doesn't lift the question. So instead one simply aims
> for not making the assumption [or making least amount of assumptions].
> Yes, you can sense contradiction, because in-place processing also rests
> on an assumption. Yeah, world is not ideal and life is full of
> compromises. I mean there are pros and cons, and in-place is considered
> to bring more pros.
> 
> (*) And in some cases it's even 100% justified, most notably in CBC
> encrypt case, when each block is dependent on previous.
> 
> (**) Note that you can avoid the question by processing data strictly on
> per-block basis, so that you'll be in control of accessing data in
> specific order, not underlying implementation. But that's not what is
> suggested, right?

No.  The intention is to make the partially overlapping check follow
the underlying cipher's implementation needs, not the other way round.
And to document that the term "partially overlapping" is meant this way.


Bernd.

From Matthias.St.Pierre at ncp-e.com  Sat Mar 10 10:03:53 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sat, 10 Mar 2018 11:03:53 +0100
Subject: [openssl-project] External contributors and the next release
In-Reply-To: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
References: <51CF9902-32AF-4D08-82EC-6BCA04AF5A0E@akamai.com>
Message-ID: <e99abbd9-4afa-4a33-6a59-ad6237ed48dc@ncp-e.com>

Am 07.03.2018 um 02:20 schrieb Salz, Rich:
>
> 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 team, only third-party
> existing pull requests will be considered
>
>

Will there be an official announcement of the prolongation and/or an
update to https://www.openssl.org/policies/releasestrat.html?

Matthias




From levitte at openssl.org  Sat Mar 10 10:45:46 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 10 Mar 2018 11:45:46 +0100 (CET)
Subject: [openssl-project] VOTE report: Push the release of 1.1.1 beta1
 (pre3) forward one week
Message-ID: <20180310.114546.780593698922932617.levitte@openssl.org>

I started a vote moments ago on the OMC list with the content that
follows.  The OMC will vote on it, hopefully on time, and the
resulting tally will be posted here.

Vote text:

NOTE: THREE DAY VOTE
Why?  Because beta1 is currently scheduled to be released in three
days.  A longer voting period would hold the release hostage in
practice, and thereby force a push of the release date regardless of
the vote result.

----------
topic: Push the release of 1.1.1 beta1 (pre3) forward one week

       Reason: we have a number of unreviewed PRs on github marked
       1.1.1 and time is getting short.

       All other current future release dates will be pushed one week as well.
       https://www.openssl.org/policies/releasestrat.html will be updated.
       An official announcement should be made.
Proposed by Richard Levitte
Public: yes
opened: 2018-03-10
closed: yyyy-mm-dd
THREE DAY VOTE!

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sat Mar 10 12:43:18 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 10 Mar 2018 13:43:18 +0100
Subject: [openssl-project] VOTE report: Push the release of 1.1.1 beta1
 (pre3) forward one week
In-Reply-To: <20180310.114546.780593698922932617.levitte@openssl.org>
References: <20180310.114546.780593698922932617.levitte@openssl.org>
Message-ID: <20180310124318.GA26207@roeckx.be>

On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote:
> Vote text:
> 
> NOTE: THREE DAY VOTE
> Why?  Because beta1 is currently scheduled to be released in three
> days.  A longer voting period would hold the release hostage in
> practice, and thereby force a push of the release date regardless of
> the vote result.

As explained by Rich on the OMC list, we can't have that. I assume
it's a 1 week vote. But the vote can be closed earlier.


Kurt


From levitte at openssl.org  Sat Mar 10 12:50:56 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 10 Mar 2018 13:50:56 +0100 (CET)
Subject: [openssl-project] VOTE report: Push the release of 1.1.1 beta1
 (pre3) forward one week
In-Reply-To: <20180310124318.GA26207@roeckx.be>
References: <20180310.114546.780593698922932617.levitte@openssl.org>
 <20180310124318.GA26207@roeckx.be>
Message-ID: <20180310.135056.2305113788576393445.levitte@openssl.org>

In message <20180310124318.GA26207 at roeckx.be> on Sat, 10 Mar 2018 13:43:18 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote:
kurt> > Vote text:
kurt> > 
kurt> > NOTE: THREE DAY VOTE
kurt> > Why?  Because beta1 is currently scheduled to be released in three
kurt> > days.  A longer voting period would hold the release hostage in
kurt> > practice, and thereby force a push of the release date regardless of
kurt> > the vote result.
kurt> 
kurt> As explained by Rich on the OMC list, we can't have that. I assume
kurt> it's a 1 week vote. But the vote can be closed earlier.

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.

Basically, it's a catch 22 that noone thought of...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Sat Mar 10 13:15:49 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 10 Mar 2018 13:15:49 +0000
Subject: [openssl-project] VOTE report: Push the release of 1.1.1 beta1
 (pre3) forward one week
In-Reply-To: <20180310.135056.2305113788576393445.levitte@openssl.org>
References: <20180310.114546.780593698922932617.levitte@openssl.org>
 <20180310124318.GA26207@roeckx.be>
 <20180310.135056.2305113788576393445.levitte@openssl.org>
Message-ID: <827E8C51-E74C-4EDC-9BCC-31BCA2794664@akamai.com>

>    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 didn't plan well enough, and we didn't give ourselves enough time to re-evaluate. That is, deciding to ship the schedule should have happened at least seven days before the next release.  I think those are the key things we need to take away from this, not an attempt to change the voting process.



From levitte at openssl.org  Mon Mar 12 20:16:28 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 12 Mar 2018 21:16:28 +0100 (CET)
Subject: [openssl-project] VOTE report: Push the release of 1.1.1 beta1
 (pre3) forward one week
In-Reply-To: <20180310.114546.780593698922932617.levitte@openssl.org>
References: <20180310.114546.780593698922932617.levitte@openssl.org>
Message-ID: <20180312.211628.767193592013312885.levitte@openssl.org>

The vote closes today with 6 +1's, 0 -1's and one not voted.

In other words, the 1.1.1 pre3 (beta1) release is pushed to Tuesday,
March 20th, and the dates following are to be adjusted accordingly.

Cheers,
Richard

In message <20180310.114546.780593698922932617.levitte at openssl.org> on Sat, 10 Mar 2018 11:45:46 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> I started a vote moments ago on the OMC list with the content that
levitte> follows.  The OMC will vote on it, hopefully on time, and the
levitte> resulting tally will be posted here.
levitte> 
levitte> Vote text:
levitte> 
levitte> NOTE: THREE DAY VOTE
levitte> Why?  Because beta1 is currently scheduled to be released in three
levitte> days.  A longer voting period would hold the release hostage in
levitte> practice, and thereby force a push of the release date regardless of
levitte> the vote result.
levitte> 
levitte> ----------
levitte> topic: Push the release of 1.1.1 beta1 (pre3) forward one week
levitte> 
levitte>        Reason: we have a number of unreviewed PRs on github marked
levitte>        1.1.1 and time is getting short.
levitte> 
levitte>        All other current future release dates will be pushed one week as well.
levitte>        https://www.openssl.org/policies/releasestrat.html will be updated.
levitte>        An official announcement should be made.
levitte> Proposed by Richard Levitte
levitte> Public: yes
levitte> opened: 2018-03-10
levitte> closed: yyyy-mm-dd
levitte> THREE DAY VOTE!
levitte> 
levitte> -- 
levitte> Richard Levitte         levitte at openssl.org
levitte> OpenSSL Project         http://www.openssl.org/~levitte/
levitte> _______________________________________________
levitte> openssl-project mailing list
levitte> openssl-project at openssl.org
levitte> https://mta.openssl.org/mailman/listinfo/openssl-project
levitte> 

From levitte at openssl.org  Mon Mar 12 20:33:19 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 12 Mar 2018 21:33:19 +0100 (CET)
Subject: [openssl-project] Updated 1.1.1 release timetable
Message-ID: <20180312.213319.566978485018951640.levitte@openssl.org>

Following the vote to change the coming release dates, the release
timetable has been change to the following:

  * 13th February 2018, alpha release 1 (pre1)
  * 27th February 2018, alpha release 2 (pre2)
  * 20th March 2018, beta release 1 (pre3)
    - OpenSSL_1_1_1-stable created (feature freeze)
    - master becomes basis for 1.1.2 or 1.2.0 (TBD)
  * 3rd April 2018, beta release 2 (pre4)
  * 17th April 2018, beta release 3 (pre5)
  * 1st May 2018, beta release 4 (pre6)
  * 8th May 2018, release readiness check (new release cycles added if
    required, first possible final release date: 15th May 2018)

See https://www.openssl.org/policies/releasestrat.html for a reminder
of all details.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Tue Mar 13 01:22:55 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 13 Mar 2018 01:22:55 +0000
Subject: [openssl-project] Copyrights, AUTHORS file, etc.
Message-ID: <16330C03-AB1A-4F11-A6DE-25CB6C2F7028@akamai.com>

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 open source folks who we thought could help us. This include Max Sills from the Google open source office, Gervais Markham who led the Mozilla relicensing effort, someone from GitHub (to talk about CLA automation), and probably another person who I am forgetting.  We also talked with our legal counsel, Mishi Choudhary of the Software Freedom Law Center.

Around 2Q 3Q 2015 the discussions were completed, and we had coalesced around a plan. There was no formal OMC vote (it was called the openssl-team at that point). But there were no objections.  OMC members can skim the archives, starting around July 2015 if they need to refresh their memories.

The key points of the plan are

  *   Move to Apache license
  *   Require CLA?s from all contributors
  *   Reach out to everyone we can identify and get them to approve of the change, or not
  *   Have a uniform copyright in all source files that points to the license and authors separately, for easier maintenance

The ?removing some code? blog post gives more details about the scripts we developed and what code we removed. Since then, nobody else has asked for their code to be removed.

The file/copyright changes happened during the 1.1.0 release.

We?re on the verge of being able to change the license, and as we said in our last press release, we are hoping and planning to do that for 1.1.1

The PR that marks part of this has a -1 from Tim, which is a hold.  That means we have to discuss and the OMC vote on this.  This email is intended to give the background and start the discussion.

So what are your objections Tim, and what do you want to see done differently? And also, please explain why it is better than the current plan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180313/001c6ded/attachment.html>

From tjh at openssl.org  Tue Mar 13 23:45:49 2018
From: tjh at openssl.org (Tim Hudson)
Date: Wed, 14 Mar 2018 09:45:49 +1000
Subject: [openssl-project] Copyrights, AUTHORS file, etc.
In-Reply-To: <16330C03-AB1A-4F11-A6DE-25CB6C2F7028@akamai.com>
References: <16330C03-AB1A-4F11-A6DE-25CB6C2F7028@akamai.com>
Message-ID: <CAHEJ-S4UNcFH-kp-bvbUNKcR5XtBLHxNrUtQ+V+h-xeGdnJC0A@mail.gmail.com>

This discussion has been taken to the OMC mailing list (where it continues)
rather than the openssl-project list as it goes across previous team
decisions.
An update once that discussion completes will be sent to the
openssl-project list.

Thanks,
Tim.


On Tue, Mar 13, 2018 at 11:22 AM, Salz, Rich <rsalz at akamai.com> wrote:

> 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 open source folks who
> we thought could help us. This include Max Sills from the Google open
> source office, Gervais Markham who led the Mozilla relicensing effort,
> someone from GitHub (to talk about CLA automation), and probably another
> person who I am forgetting.  We also talked with our legal counsel, Mishi
> Choudhary of the Software Freedom Law Center.
>
>
>
> Around 2Q 3Q 2015 the discussions were completed, and we had coalesced
> around a plan. There was no formal OMC vote (it was called the openssl-team
> at that point). But there were no objections.  OMC members can skim the
> archives, starting around July 2015 if they need to refresh their memories.
>
>
>
> The key points of the plan are
>
>    - Move to Apache license
>    - Require CLA?s from all contributors
>    - Reach out to everyone we can identify and get them to approve of the
>    change, or not
>    - Have a uniform copyright in all source files that points to the
>    license and authors separately, for easier maintenance
>
>
>
> The ?removing some code? blog post gives more details about the scripts we
> developed and what code we removed. Since then, nobody else has asked for
> their code to be removed.
>
>
>
> The file/copyright changes happened during the 1.1.0 release.
>
>
>
> We?re on the verge of being able to change the license, and as we said in
> our last press release, we are hoping and planning to do that for 1.1.1
>
>
>
> The PR that marks part of this has a -1 from Tim, which is a hold.  That
> means we have to discuss and the OMC vote on this.  This email is intended
> to give the background and start the discussion.
>
>
>
> So what are your objections Tim, and what do you want to see done
> differently? And also, please explain why it is better than the current
> plan.
>
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180314/cdf6a6b2/attachment-0001.html>

From kurt at roeckx.be  Wed Mar 14 00:27:47 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 14 Mar 2018 01:27:47 +0100
Subject: [openssl-project] DRBGs, threads and locking
Message-ID: <20180314002746.GA5659@roeckx.be>

So Tim has voted -1 on PR #5547 and wants us to discuss it here
and vote on it.

I don't know if it's clear to everybody what this is about. If
something is not clear, please ask. PR #5461 contains a
lot of documentation updates that is related to it, and it might
be useful to read it as background information. There are many
other related issues and pull request. I will try to make a basic
summary here.

The DRBGs is what we use to generate random numbers. They have the
possibility to chain, where 1 DRBG gets it's entropy from it's
parent. You can make long chains with this.

The current state in master is that you have 1 master DRBG that
gets it's entropy from the OS, and then 1 public and 1 private
DRBG that gets the entropy from the master. Then there is an DRBG
in the SSL struct that gets it's entropy from the public DRBG.

I have 2 problems with the current setup that I would like to
solve:
- On SSL_new() we create a new DRBG. That needs to get initialized
  and that requires getting entropy from somewhere, where that's
  currently the global public DRBG. This requires taking a lock.
- If we actually want to use the DRBG for everything related to
  that SSL connections to avoid having to lock a global DRBG
  everything that SSL code calls needs to be able to say with
  which DRBG it needs to generate random data. There was already 1
  PR related to this merged. PR #5510 is still open that deals at
  least with mot of it that I know about. I find that a very ugly
  hack and really don't see an easy way improve it.

My solution is to just have 1 master DRBG, and a public and
private DRBG per thread. The only lock that then is needed is when
the public or private DRBG needs to reseed. All the rest of the
code can stay just as it is, but we might want to change some
places to use the (thread local) private DRBG, which is what #4665
is about.

Some people seem to have a desire to have a separate the DRBGs per
SSL connection, at least for the public data. This is for cases
where from that data it would be possible to get the internal
state of the DRBG that is at least allegedly possible with the
DUAL_EC_DRBG. I believe this is mitigated somewhat by our mixing
in additional data when calling RAND_bytes() (or RAND_priv_bytes()),
but I'm not an expert in this and will leave this to the others to
comment on.

So the suggestion was to still have a per SSL public DRBG, but
then the problem is that that SSL object might have moved to a
different thread between creating and being used and so that the
parent DRBG might actually belong to a different thread. One
solution there is that we just take the current thread's public
DRBG as parent instead of the original threads public DRBG.


I hope I at least covered most of it.


Kurt


From kaduk at mit.edu  Wed Mar 14 01:01:01 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 13 Mar 2018 20:01:01 -0500
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <20180314002746.GA5659@roeckx.be>
References: <20180314002746.GA5659@roeckx.be>
Message-ID: <20180314010100.GS55987@kduck.kaduk.org>

On Wed, Mar 14, 2018 at 01:27:47AM +0100, Kurt Roeckx wrote:
> My solution is to just have 1 master DRBG, and a public and
> private DRBG per thread. The only lock that then is needed is when
> the public or private DRBG needs to reseed. All the rest of the
> code can stay just as it is, but we might want to change some
> places to use the (thread local) private DRBG, which is what #4665
> is about.
[...]
> So the suggestion was to still have a per SSL public DRBG, but
> then the problem is that that SSL object might have moved to a
> different thread between creating and being used and so that the
> parent DRBG might actually belong to a different thread. One
> solution there is that we just take the current thread's public
> DRBG as parent instead of the original threads public DRBG.

This should be fine from a thread-safety point of view.  I don't
know whether it could potentially affect the standards compliance,
for the intermediate DRBG to potentially change over time (even
though it still chains to a common grandparent/master DRBG).

Per-SSL DRBGs (especially if split to public and private) seem
excessive to me, so architecture described in the quoted text seems
like the best option, to me.

-Ben

From rsalz at akamai.com  Wed Mar 14 01:26:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 14 Mar 2018 01:26:38 +0000
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <20180314002746.GA5659@roeckx.be>
References: <20180314002746.GA5659@roeckx.be>
Message-ID: <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>

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 threadB and threadC and each need to reseed from their parent.  In order to do that safely, threadA also has to do the locking to avoid conflict. That defeats the major gain of per-thread.

I think having the SSL object parent be whatever the *current* thread DRBG is seems like the best, if not only, way to go.

 


From kaduk at mit.edu  Wed Mar 14 01:48:30 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 13 Mar 2018 20:48:30 -0500
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
Message-ID: <20180314014830.GW55987@kduck.kaduk.org>

On Wed, Mar 14, 2018 at 01:26:38AM +0000, Salz, Rich wrote:
> 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 threadB and threadC and each need to reseed from their parent.  In order to do that safely, threadA also has to do the locking to avoid conflict. That defeats the major gain of per-thread.
> 
> I think having the SSL object parent be whatever the *current* thread DRBG is seems like the best, if not only, way to go.

Either that or just always use the per-thread DRBG for the current
thread, and don't bother to do per-SSL at all.

-Ben

From rsalz at akamai.com  Wed Mar 14 02:10:14 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 14 Mar 2018 02:10:14 +0000
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <20180314014830.GW55987@kduck.kaduk.org>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <20180314014830.GW55987@kduck.kaduk.org>
Message-ID: <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>

>    Either that or just always use the per-thread DRBG for the current
    thread, and don't bother to do per-SSL at all.
  
There is appeal to isolating each SSL connection so that an adversary can't use information it has about *it's* connection to attack another.  Granted, this might not be practical, but still...


From tjh at cryptsoft.com  Wed Mar 14 03:15:02 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Wed, 14 Mar 2018 13:15:02 +1000
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <20180314014830.GW55987@kduck.kaduk.org>
 <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>
Message-ID: <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>

We have to keep in mind what threats we care about and their practicality.
The security of a DRBG is dependent on both the secrecy of the seed
material provided and the security of the algorithm in terms of its output
not leaking information that materially leaks the internal state in a
manner that enables it to be discovered or reversed in a manner to enable
determination of previous or future outputs.

For some of the arguments used to date there appears to be an assumption
that there is a practical difference between a broken DRBG algorithm such
that it is not such a security issue if we separate out the DRBG instances
on a per SSL connection.
In real terms if a DRBG is broken and its state is able to be determined
remotely there is no practical difference in separating DRBG instances -
they are all equally vulnerable in the same manner.
In the case of the DualEC-DRBG this was clear - and no one I've seen has
ever suggested that you were safer if you had separate instances of a
broken algorithm for a DRBG - it makes no practical difference to the
security at all.
Sure there is a slight technical difference - but from a security
perspective there is no difference - you are susceptible to the same attack
- so the minor technical difference offers no actual meaningful security
value - and everyone that has referenced this to date has also indicated
that they don't think that there is actually any real practical value to
the difference - it has been more of a "it cannot harm" sort of comment.

In more general terms we need to have a clear view on what we think about
our thread model - what is considered inside the scope of what we care to
address - and what is frankly outside the scope (for our view).


   - We don't consider attacks from the same process against itself within
   our threat model.
   - Correspondingly we don't consider attacks from one thread against
   another thread without our threat model.
   - We don't consider privileged user attacks against the user in our
   threat model (i.e. root can read the memory of the process on most
   Unix-like systems).
   - We also don't actually consider a need to protect all secret
   information from every possible other bug that might leak arbitrary parts
   of memory. We could. But we don't. And if we did we would need to protect
   both the seeding material for the DRBG and its internal state and
   potentially its output. We don't do that - because that isn't within our
   threat model.


Typical applications share an SSL_CTX between multiple SSL instances and we
maintain the session cache against the SSL_CTX. This may be in a single
process (thread) or shared across multiple threads - or even shared across
multiple prcesses (which is simply the same as being in a single process
from our perspective where the "magic" to coordinate the session id cache
between processes is left to the developer/user).

In a FIPS context, every DRBG has requirements on its inputs (seeding) and
on maintaining a continuous RNG test (block-based compare for non-repeating
outputs at a block level).
All of these would be a per-instance requirement on the DRBG. They have to
be factored in.

There is also the argument that locking is bad and fewer locks are better -
and that argument needs to be backed up by looking at the overall status -
which particular application model are we concerned about? Have we measured
it? Have we figured out where the bottlenecks are? Have we worked through
optimising the actual areas of performance impact? Or are we just
prematurely optimising? Excessive locking will have an impact for certain
application models - but I don't think anyone is suggesting that what we
had previously was excessive - and given the significant performance impact
of the recent changes which went unmeasured and unaddressed I think it is
clear we haven't been measuring performance related items for the DRBG at
all to date - so there wasn't any "science" behind the choices made.

Simple, clear, well documented code with good tests and known architectural
assumptions is what we are trying to achieve - and my sense from the
conversations on this topic to date was that we don't have a consensus as
to what problem we are actually trying to solve - so the design approach
shifts, and shifts again - all of which are the authors of the PRs
responding to what is (in my view at least) conflicting suggestions based
on different assumptions.

That is what I put the -1 on the the PR - to have this discussion - and
agree on what we are trying to solve - and also agree on what we are not
trying to solve. And perhaps we can actually document some of our "threat
model" - as I'm sure we have different views on that as well.

I don't think we should have per-SSL DRBGs - it offers no meaningful
security value. We could have a per-SSL_CTX - but I'm not sure that is
needed. We could have a per-thread - but again that is unclear if we
actually need that either.
My thoughts are per-SSL_CTX might make the most sense based on my
understanding of the high-performance server contexts (in various web
servers and custom servers).
You can make a reasonable argument that we are sharing many security
related things between SSL_CTXs already so this is the right place.

And if we cannot reach a consensus because we cannot get to a shared view
then perhaps it needs to be configurable for the user.

Tim.


On Wed, Mar 14, 2018 at 12:10 PM, Salz, Rich <rsalz at akamai.com> wrote:

> >    Either that or just always use the per-thread DRBG for the current
>     thread, and don't bother to do per-SSL at all.
>
> There is appeal to isolating each SSL connection so that an adversary
> can't use information it has about *it's* connection to attack another.
> Granted, this might not be practical, but still...
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180314/56aee76d/attachment-0001.html>

From paul.dale at oracle.com  Wed Mar 14 01:35:13 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 13 Mar 2018 18:35:13 -0700 (PDT)
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
Message-ID: <7583c9d4-8428-46fa-b33a-8bfce71f0e9a@default>

I think the intention is to ditch the drbg from the ssl object and then call the global function (either public or private) which has been changed to use the current thread's drbg rather than being global.

I'm in favour of a single per ssl drbg still, I'm not sure what a clean way to hook it up to avoid locks is (yet).


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Salz, Rich [mailto:rsalz at akamai.com] 
Sent: Wednesday, 14 March 2018 11:27 AM
To: openssl-project at openssl.org
Subject: 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 threadB and threadC and each need to reseed from their parent.  In order to do that safely, threadA also has to do the locking to avoid conflict. That defeats the major gain of per-thread.

I think having the SSL object parent be whatever the *current* thread DRBG is seems like the best, if not only, way to go.

 

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From paul.dale at oracle.com  Wed Mar 14 03:42:10 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 13 Mar 2018 20:42:10 -0700 (PDT)
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <20180314014830.GW55987@kduck.kaduk.org>
 <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>
 <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
Message-ID: <f7e254e0-4cbb-4c44-b07f-9c64f722566a@default>

We did a performance analysis for Oracle?s equivalent of Nginx, OTD, about two years ago.  We were looking at the number of connections per second that could be established and the limiting factor was locking in ssleay_rand_bytes.  Approximately a third of the CPU and over 90% of the lock wait time was there from memory.  For this kind of workload (many threads, many connections) a non-locking RNG would have been an improvement.  I?ll see if I can find the analyses and then find out what I can release.

This was using 1.0.2 not 1.1 so things might have changed.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From: Tim Hudson [mailto:tjh at cryptsoft.com] 
Sent: Wednesday, 14 March 2018 1:15 PM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] DRBGs, threads and locking

We have to keep in mind what threats we care about and their practicality.?
The security of a DRBG is dependent on both the secrecy of the seed material provided and the security of the algorithm in terms of its output not leaking information that materially leaks the internal state in a manner that enables it to be discovered or reversed in a manner to enable determination of previous or future outputs.

For some of the arguments used to date there appears to be an assumption that there is a practical difference between a broken DRBG algorithm such that it is not such a security issue if we separate out the DRBG instances on a per SSL connection.
In real terms if a DRBG is broken and its state is able to be determined remotely there is no practical difference in separating DRBG instances - they are all equally vulnerable in the same manner.?
In the case of the DualEC-DRBG this was clear - and no one I've seen has ever suggested that you were safer if you had separate instances of a broken algorithm for a DRBG - it makes no practical difference to the security at all.
Sure there is a slight technical difference - but from a security perspective there is no difference - you are susceptible to the same attack - so the minor technical difference offers no actual meaningful security value - and everyone that has referenced this to date has also indicated that they don't think that there is actually any real practical value to the difference - it has been more of a "it cannot harm" sort of comment.?

In more general terms we need to have a clear view on what we think about our thread model - what is considered inside the scope of what we care to address - and what is frankly outside the scope (for our view).?

? We don't consider attacks from the same process against itself within our threat model.?
? Correspondingly we don't consider attacks from one thread against another thread without our threat model.
? We don't consider privileged user attacks against the user in our threat model (i.e. root can read the memory of the process on most Unix-like systems).?
? We also don't actually consider a need to protect all secret information from every possible other bug that might leak arbitrary parts of memory. We could. But we don't. And if we did we would need to protect both the seeding material for the DRBG and its internal state and potentially its output. We don't do that - because that isn't within our threat model.

Typical applications share an SSL_CTX between multiple SSL instances and we maintain the session cache against the SSL_CTX. This may be in a single process (thread) or shared across multiple threads - or even shared across multiple prcesses (which is simply the same as being in a single process from our perspective where the "magic" to coordinate the session id cache between processes is left to the developer/user).?

In a FIPS context, every DRBG has requirements on its inputs (seeding) and on maintaining a continuous RNG test (block-based compare for non-repeating outputs at a block level).?
All of these would be a per-instance requirement on the DRBG. They have to be factored in.

There is also the argument that locking is bad and fewer locks are better - and that argument needs to be backed up by looking at the overall status - which particular application model are we concerned about? Have we measured it? Have we figured out where the bottlenecks are? Have we worked through optimising the actual areas of performance impact? Or are we just prematurely optimising? Excessive locking will have an impact for certain application models - but I don't think anyone is suggesting that what we had previously was excessive - and given the significant performance impact of the recent changes which went unmeasured and unaddressed I think it is clear we haven't been measuring performance related items for the DRBG at all to date - so there wasn't any "science" behind the choices made.

Simple, clear, well documented code with good tests and known architectural assumptions is what we are trying to achieve - and my sense from the conversations on this topic to date was that we don't have a consensus as to what problem we are actually trying to solve - so the design approach shifts, and shifts again - all of which are the authors of the PRs responding to what is (in my view at least) conflicting suggestions based on different assumptions.

That is what I put the -1 on the the PR - to have this discussion - and agree on what we are trying to solve - and also agree on what we are not trying to solve. And perhaps we can actually document some of our "threat model" - as I'm sure we have different views on that as well.

I don't think we should have per-SSL DRBGs - it offers no meaningful security value. We could have a per-SSL_CTX - but I'm not sure that is needed. We could have a per-thread - but again that is unclear if we actually need that either.
My thoughts are per-SSL_CTX might make the most sense based on my understanding of the high-performance server contexts (in various web servers and custom servers).?
You can make a reasonable argument that we are sharing many security related things between SSL_CTXs already so this is the right place.?

And if we cannot reach a consensus because we cannot get to a shared view then perhaps it needs to be configurable for the user.

Tim.


On Wed, Mar 14, 2018 at 12:10 PM, Salz, Rich <rsalz at akamai.com> wrote:
>? ? Either that or just always use the per-thread DRBG for the current
? ? thread, and don't bother to do per-SSL at all.

There is appeal to isolating each SSL connection so that an adversary can't use information it has about *it's* connection to attack another.? Granted, this might not be practical, but still...

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From tjh at openssl.org  Wed Mar 14 09:33:06 2018
From: tjh at openssl.org (Tim Hudson)
Date: Wed, 14 Mar 2018 19:33:06 +1000
Subject: [openssl-project] OpenSSL FIPS Wiki Update
Message-ID: <CAHEJ-S40WA=TEyT15gPn4jXWpSY1p747eQNL_oOF=SaZ=dMi=Q@mail.gmail.com>

https://wiki.openssl.org/index.php/FIPS_module_3.0

I've edited that to be closer to the list of items we are discussing and to
remove things which looked like commitments that are out of scope of our
current plans.

As always, feedback is welcome - but we have had a few people referencing
that out of date information so I fixed at least that issue (hopefully).

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180314/259d286a/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Wed Mar 14 10:31:36 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 14 Mar 2018 11:31:36 +0100
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <20180314014830.GW55987@kduck.kaduk.org>
 <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>
 <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
Message-ID: <a1b15d3e-f006-0665-bfc4-98f1eef2f050@ncp-e.com>

It is good that Tim hit the break and requested a discussion. That was
overdue and it is unfortunate that we did not start it much earlier. I
think Tim brought up to important points:

1. We need to to pause for a discussion to determine the direction to
go. Otherwise the DRBG implementation will become an ever moving target

2. Instead of guessing about the performance impacts of our change we
should more rely on measuring them.

Ad 1: Unfortunately, it was not clear until a few days ago that there
was so much disagreement on how to do it right. In view of the upcoming
beta freeze, it would probably be the best to leave the status-quo on
master for 1.1.1, and continue the discussion under the premise that it
will be implemented in 1.1.2-dev or 1.2.0-dev. This would give us more
time to think about the optimal solution.

Ad 2: All the haste and the last-minute changes were in some way caused
by the fact that we did not notice the performance regressions until
#5559, because we were not measuring them on a regular base. Having
'openssl speed' is not sufficient and it would really be great if we
could have feedback about the actual performance of "real world" high
performance web servers. But that is out of reach for ordinary persons
and can only be done by a larger company.


per-thread vs. per-ssl

As for the discussion about whether per-thread or per-ssl DRBGs are
better from a security perspective: I am not a professional
cryptographer, so I'm not in the position to decide that. But I can say
that currently the per-thread implementation is far superior when it
comes to simplicity of design. And simplicity of design is an important
countermeasure to prevent bugs and security holes. One of the reasons
why Kurt reverted the per-ssl implementation was that it was a bit ugly
and unsatisfactory, because a lot of changes had to be made to functions
for handing down the correct DRBG through the callstack down to the low
level functions that needed to use it.


If per-ssl DRBGs are desired, I propose the following solution which
reconciles the two approaches without loosing simplicity: If the public
and private DRBGs are thread-local anyway, then it is easy to implement
them as a stack so that the per-thread DRBG can be exchanged by the
per-ssl DRBG within the scope of a function. The correct DRBG would then
be picked up automatically further down in the stack when RAND_bytes()
resp. RAND_priv_bytes() is called.

I am thinking of an API like

??? RAND_DRBG_push_public(RAND_DRBG *public);
??? RAND_DRBG_push_private(RAND_DRBG *private);

??? RAND_DRBG_pop_public();
??? RAND_DRBG_push_private();

As said before, this does not imply a preference in one of the two
directions, it's only a suggestion about how it could be implemented.
And I will not throw in a quick pull request for this... ;-)

Matthias



From rsalz at akamai.com  Wed Mar 14 12:49:46 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 14 Mar 2018 12:49:46 +0000
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <7583c9d4-8428-46fa-b33a-8bfce71f0e9a@default>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <7583c9d4-8428-46fa-b33a-8bfce71f0e9a@default>
Message-ID: <135F99B5-2A61-4DBE-B7C8-8CA0BB026307@akamai.com>

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.


From rsalz at akamai.com  Wed Mar 14 13:44:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 14 Mar 2018 13:44:40 +0000
Subject: [openssl-project] OpenSSL FIPS Wiki Update
In-Reply-To: <CAHEJ-S40WA=TEyT15gPn4jXWpSY1p747eQNL_oOF=SaZ=dMi=Q@mail.gmail.com>
References: <CAHEJ-S40WA=TEyT15gPn4jXWpSY1p747eQNL_oOF=SaZ=dMi=Q@mail.gmail.com>
Message-ID: <50209F14-5912-4A29-97FC-8AE200538E75@akamai.com>

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: "tjh at openssl.org" <tjh at openssl.org>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Wednesday, March 14, 2018 at 5:33 AM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: [openssl-project] OpenSSL FIPS Wiki Update

https://wiki.openssl.org/index.php/FIPS_module_3.0<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openssl.org_index.php_FIPS-5Fmodule-5F3.0&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=_eDCHauz0_yvlroQYx4dezKXLU9Lc1eYfZlzseS6Mvw&s=4ntdPoDarQosCoGaVQMCiq9PGQ0oktGO7IgRZr7ntf0&e=>

I've edited that to be closer to the list of items we are discussing and to remove things which looked like commitments that are out of scope of our current plans.

As always, feedback is welcome - but we have had a few people referencing that out of date information so I fixed at least that issue (hopefully).

Tim.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180314/44cf5211/attachment.html>

From kurt at roeckx.be  Wed Mar 14 16:57:13 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 14 Mar 2018 17:57:13 +0100
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <135F99B5-2A61-4DBE-B7C8-8CA0BB026307@akamai.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <7583c9d4-8428-46fa-b33a-8bfce71f0e9a@default>
 <135F99B5-2A61-4DBE-B7C8-8CA0BB026307@akamai.com>
Message-ID: <20180314165712.GA16956@roeckx.be>

On Wed, Mar 14, 2018 at 12:49:46PM +0000, Salz, Rich wrote:
> 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.

I think it's better than what we have in 1.1.0. And if we think we
can improve it, I suggest we improve it after 1.1.1.

So I think the discussion is both about speed and security.

>From what I understand from various things is that the random
number generate is now for some workloads at least a limiting
factor. Having it lockless and per thread is both the easiest
thing to do and gives the best performance.

When it comes to security, there seems to be a concern that from
the public data it might be possible to determine the internal
state, and that this might possibly have an effect on the security
of a different connection. But we have the same situation now in
1.1.0. And I'm still waiting for people to properly explain that
having it per SSL is better or not, there at least doesn't seem
to be an agreement on that part.


Kurt


From paul.dale at oracle.com  Wed Mar 14 21:28:44 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Wed, 14 Mar 2018 14:28:44 -0700 (PDT)
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
References: <20180314002746.GA5659@roeckx.be>
 <8F8EF7CB-D940-45F5-9090-2F96D3B1AFCB@akamai.com>
 <20180314014830.GW55987@kduck.kaduk.org>
 <00425708-02F3-4A9F-8912-C43A1BF70575@akamai.com>
 <CAHEJ-S5LPiuM24KAGWg8nPa3GMhyeU3MmMFg1tw62sfbN1SERg@mail.gmail.com>
Message-ID: <78a1f4ff-d064-4e2e-a16f-f87a55161394@default>

Consider a hypothetical scenario of a large high performance multi-user database.  All connections are via TLS.  A lot of other cryptographic operations are done, some involving random numbers.  This is an example where the dual ec attack could have been partially mitigated with per TLS DRBGs.  Each TLS connection would reveal enough over the wire to be easily broken.  Yes bad.  Very bad.  However, the majority of the database would remain secure simply because there is no way to expand the attack from the broken DRBG to its parent as this requires reversing a hash.

The extra separation of per SSL DRBS could have helped in the past, nobody knows if it would again.  I'd like to see this but can live without it (our current DRBS are secure after all :)

As I mentioned in my previous email, non-locking is important for performance, I definitely want this.  I've not found the numbers yet :(


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From: Tim Hudson [mailto:tjh at cryptsoft.com] 
Sent: Wednesday, 14 March 2018 1:15 PM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] DRBGs, threads and locking

We have to keep in mind what threats we care about and their practicality.?
The security of a DRBG is dependent on both the secrecy of the seed material provided and the security of the algorithm in terms of its output not leaking information that materially leaks the internal state in a manner that enables it to be discovered or reversed in a manner to enable determination of previous or future outputs.

For some of the arguments used to date there appears to be an assumption that there is a practical difference between a broken DRBG algorithm such that it is not such a security issue if we separate out the DRBG instances on a per SSL connection.
In real terms if a DRBG is broken and its state is able to be determined remotely there is no practical difference in separating DRBG instances - they are all equally vulnerable in the same manner.?
In the case of the DualEC-DRBG this was clear - and no one I've seen has ever suggested that you were safer if you had separate instances of a broken algorithm for a DRBG - it makes no practical difference to the security at all.
Sure there is a slight technical difference - but from a security perspective there is no difference - you are susceptible to the same attack - so the minor technical difference offers no actual meaningful security value - and everyone that has referenced this to date has also indicated that they don't think that there is actually any real practical value to the difference - it has been more of a "it cannot harm" sort of comment.?

In more general terms we need to have a clear view on what we think about our thread model - what is considered inside the scope of what we care to address - and what is frankly outside the scope (for our view).?

? We don't consider attacks from the same process against itself within our threat model.?
? Correspondingly we don't consider attacks from one thread against another thread without our threat model.
? We don't consider privileged user attacks against the user in our threat model (i.e. root can read the memory of the process on most Unix-like systems).?
? We also don't actually consider a need to protect all secret information from every possible other bug that might leak arbitrary parts of memory. We could. But we don't. And if we did we would need to protect both the seeding material for the DRBG and its internal state and potentially its output. We don't do that - because that isn't within our threat model.

Typical applications share an SSL_CTX between multiple SSL instances and we maintain the session cache against the SSL_CTX. This may be in a single process (thread) or shared across multiple threads - or even shared across multiple prcesses (which is simply the same as being in a single process from our perspective where the "magic" to coordinate the session id cache between processes is left to the developer/user).?

In a FIPS context, every DRBG has requirements on its inputs (seeding) and on maintaining a continuous RNG test (block-based compare for non-repeating outputs at a block level).?
All of these would be a per-instance requirement on the DRBG. They have to be factored in.

There is also the argument that locking is bad and fewer locks are better - and that argument needs to be backed up by looking at the overall status - which particular application model are we concerned about? Have we measured it? Have we figured out where the bottlenecks are? Have we worked through optimising the actual areas of performance impact? Or are we just prematurely optimising? Excessive locking will have an impact for certain application models - but I don't think anyone is suggesting that what we had previously was excessive - and given the significant performance impact of the recent changes which went unmeasured and unaddressed I think it is clear we haven't been measuring performance related items for the DRBG at all to date - so there wasn't any "science" behind the choices made.

Simple, clear, well documented code with good tests and known architectural assumptions is what we are trying to achieve - and my sense from the conversations on this topic to date was that we don't have a consensus as to what problem we are actually trying to solve - so the design approach shifts, and shifts again - all of which are the authors of the PRs responding to what is (in my view at least) conflicting suggestions based on different assumptions.

That is what I put the -1 on the the PR - to have this discussion - and agree on what we are trying to solve - and also agree on what we are not trying to solve. And perhaps we can actually document some of our "threat model" - as I'm sure we have different views on that as well.

I don't think we should have per-SSL DRBGs - it offers no meaningful security value. We could have a per-SSL_CTX - but I'm not sure that is needed. We could have a per-thread - but again that is unclear if we actually need that either.
My thoughts are per-SSL_CTX might make the most sense based on my understanding of the high-performance server contexts (in various web servers and custom servers).?
You can make a reasonable argument that we are sharing many security related things between SSL_CTXs already so this is the right place.?

And if we cannot reach a consensus because we cannot get to a shared view then perhaps it needs to be configurable for the user.

Tim.


On Wed, Mar 14, 2018 at 12:10 PM, Salz, Rich <rsalz at akamai.com> wrote:
>? ? Either that or just always use the per-thread DRBG for the current
? ? thread, and don't bother to do per-SSL at all.

There is appeal to isolating each SSL connection so that an adversary can't use information it has about *it's* connection to attack another.? Granted, this might not be practical, but still...

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From paul.dale at oracle.com  Wed Mar 14 22:28:08 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Wed, 14 Mar 2018 15:28:08 -0700 (PDT)
Subject: [openssl-project] OID policy
Message-ID: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>

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 though the IEEE Security in Storage Working Group has defined one.

Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia


From rsalz at akamai.com  Wed Mar 14 23:36:17 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 14 Mar 2018 23:36:17 +0000
Subject: [openssl-project] OID policy
In-Reply-To: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
References: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
Message-ID: <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>

No there is no policy.  We should have OID's for the things we implement (

?On 3/14/18, 6:28 PM, "Paul Dale" <paul.dale at oracle.com> 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 though the IEEE Security in Storage Working Group has defined one.
    
    Pauli
    -- 
    Oracle
    Dr Paul Dale | Cryptographer | Network Security & Encryption 
    Phone +61 7 3031 7217
    Oracle Australia
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From paul.dale at oracle.com  Wed Mar 14 23:40:24 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Wed, 14 Mar 2018 16:40:24 -0700 (PDT)
Subject: [openssl-project] OID policy
In-Reply-To: <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
References: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
 <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
Message-ID: <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>

> We should have OID's for the things we implement

Sounds like a policy :)
Vote time?


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From levitte at openssl.org  Thu Mar 15 08:05:02 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 15 Mar 2018 09:05:02 +0100 (CET)
Subject: [openssl-project] OID policy
In-Reply-To: <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
References: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
 <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
 <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
Message-ID: <20180315.090502.2143972695067215526.levitte@openssl.org>

In message <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b at default> on Wed, 14 Mar 2018 16:40:24 -0700 (PDT), Paul Dale <paul.dale at oracle.com> said:

paul.dale> > We should have OID's for the things we implement
paul.dale> 
paul.dale> Sounds like a policy :)
paul.dale> Vote time?

Not sure if there's a need for a vote.  I'll just wait for the PR ;-)

Thing is, we probably have no need for the OIDs in the library, just
the names, as long as they don't have to be included in any DER stuff
we generate or parse.  Each name becomes an object and a NID anyway,
and that's all we need internally.

So in some cases, OIDs are more "nice to have" than useful, although
they might become useful in the future, so it's never wrong to include
the actual official OIDs when they're available.

So can I assume there's a PR coming up?  Policy wise, I think that's
what it takes, plus the approval.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Thu Mar 15 08:06:04 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 15 Mar 2018 09:06:04 +0100 (CET)
Subject: [openssl-project] OID policy
In-Reply-To: <20180315.090502.2143972695067215526.levitte@openssl.org>
References: <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
 <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
 <20180315.090502.2143972695067215526.levitte@openssl.org>
Message-ID: <20180315.090604.1368325447992095282.levitte@openssl.org>

In message <20180315.090502.2143972695067215526.levitte at openssl.org> on Thu, 15 Mar 2018 09:05:02 +0100 (CET), Richard Levitte <levitte at openssl.org> said:

levitte> So can I assume there's a PR coming up?

Ah, saw it!

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/



From matt at openssl.org  Thu Mar 15 08:33:22 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 15 Mar 2018 08:33:22 +0000
Subject: [openssl-project] OID policy
In-Reply-To: <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
References: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
 <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
 <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
Message-ID: <54778bd4-7365-821e-b934-e2cef225d1a6@openssl.org>



On 14/03/18 23:40, Paul Dale wrote:
>> We should have OID's for the things we implement
> 
> Sounds like a policy :)
> Vote time?

In the past we've also put in OIDs on request (i.e. not necessarily for
something we implement) if someone has given a reasonable argument for
its inclusion.

Matt


From rsalz at akamai.com  Thu Mar 15 12:12:27 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 15 Mar 2018 12:12:27 +0000
Subject: [openssl-project] Applying system defaults to TLS config
Message-ID: <1036756E-BDAA-42BB-AB5E-A038EA71C7D5@akamai.com>

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.

This comes from RedHat.

Viktor is concerned about changing the semantics of an existing call and argues that there are applications that are smart enough to configure securely.  (Unh, postfix and ? what others? :)  He prefers an explicit opt-in. Others have pointed out the hundreds of programs that would have to be changed make this impractical.

I think we have a real opportunity to (a) help downstream distro?s and (b) make it easy to make things more secure. Imagine being able to disable 3DES with a one-line config change (to DEFAULT cipher setting) and a reboot?

Yes, it changes the semantics of an important API. I think the security trade-off is very much worth it.  We add new option that lets postfix (still waiting for other apps to be named :) opt-out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180315/e477bb38/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Thu Mar 15 13:54:43 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 15 Mar 2018 14:54:43 +0100
Subject: [openssl-project] Merge conflicts caused by pull request #5462 -
 Publish the RAND_DRBG API
Message-ID: <be77bca9-cab6-fa93-9402-74df0ef285a4@ncp-e.com>

Hi,

in a few hours I will merge pull request

? #5462 - Publish the RAND_DRBG API

This pull request removes 14 public symbols (symbols RAND_POOL_*,?
numbers 4351 - 4364) and closes the gap by renumbering all following
symbols. Anyone of you who as added new symbols to libcrypto.num in his
pull request will encounter a merge-conflict during his next rebase.

Don't be scared about the size of the conflict, there is a simple
solution: accept all incoming changes (discarding yours) and then run
'make update' again.

HTH,

Matthias



From openssl-users at dukhovni.org  Thu Mar 15 19:41:27 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 15 Mar 2018 15:41:27 -0400
Subject: [openssl-project] Applying system defaults to TLS config
In-Reply-To: <1036756E-BDAA-42BB-AB5E-A038EA71C7D5@akamai.com>
References: <1036756E-BDAA-42BB-AB5E-A038EA71C7D5@akamai.com>
Message-ID: <26ECDD58-AF70-4443-B158-5D105E4D62FC@dukhovni.org>



> On Mar 15, 2018, at 8:12 AM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> https://github.com/openssl/openssl/pull/4848

I am also concerned about the performance implications of applying
the system settings at every SSL_CTX_new() (if that's the mechanism).

How does this interact with the creation of SSL contexts used for
server-side SNI support?

Finally, how is the configuration file specified? Do environment
variables influence the file location, and if so is that still
the case for setuid/setgid processes?

-- 
	Viktor.


From paul.dale at oracle.com  Thu Mar 15 21:33:55 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Thu, 15 Mar 2018 21:33:55 +0000 (UTC)
Subject: [openssl-project] OID policy
In-Reply-To: <54778bd4-7365-821e-b934-e2cef225d1a6@openssl.org>
References: <90f7ab6f-68b0-4d11-8cc1-ab902645d234@default>
 <E872728B-E6DB-4B16-81F1-F76D59FCD45D@akamai.com>
 <6f9a7c53-f40f-4794-bf1a-f59eb1db6d4b@default>
 <54778bd4-7365-821e-b934-e2cef225d1a6@openssl.org>
Message-ID: <bcefce0f-cd00-44ce-b752-ec12fb827b56@default>

Thanks for the guidance.  My PR was only for the two OIDs I noticed.  There are about an hundred other entries without OIDs, some just don't have anything assigned but others might.  It sounds, from Richard's comment, that there is no need to chase these down but that they should be added opportunistically when noticed.

Thanks,

Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Matt Caswell [mailto:matt at openssl.org] 
Sent: Thursday, 15 March 2018 6:33 PM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] OID policy



On 14/03/18 23:40, Paul Dale wrote:
>> We should have OID's for the things we implement
> 
> Sounds like a policy :)
> Vote time?

In the past we've also put in OIDs on request (i.e. not necessarily for something we implement) if someone has given a reasonable argument for its inclusion.

Matt

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From kurt at roeckx.be  Fri Mar 16 18:15:40 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 16 Mar 2018 19:15:40 +0100
Subject: [openssl-project] DRBGs, threads and locking
In-Reply-To: <20180314002746.GA5659@roeckx.be>
References: <20180314002746.GA5659@roeckx.be>
Message-ID: <20180316181539.GA19582@roeckx.be>

So it's not really clear currently that there is someone who
doesn't want to see the per thread DRBGs. Should we hold a vote on
this? Or Tim, do you want to retractor your -1?


Kurt


From Matthias.St.Pierre at ncp-e.com  Mon Mar 19 08:27:40 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Mon, 19 Mar 2018 09:27:40 +0100
Subject: [openssl-project] GitHub milestone for 1.1.1
Message-ID: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>

Hi,

in view of the upcoming beta release and the release strategy (see
below) it is a little bit disturbing that our GitHub milestone for 1.1.1
<https://github.com/openssl/openssl/milestone/9> shows only 30%
completion. How are we going to deal with this? Shouldn't the PR's and
issues be examined and categorized into bugs and features? The former
could still be merged during beta, but what happens to the latter? What
is with outstanding documentation (e.g. #5461, #5629), will it be
treated like a bugfix and be mergeable past the beta freeze?

Regards,
Matthias

--
We have defined the following release criteria for 1.1.1:

All open github issues/PRs older than 2 weeks at the time of release to
be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone
to be closed (see below)
Clean builds in Travis and Appveyor for two days
run-checker.sh to be showing as clean 2 days before release
No open Coverity issues (not flagged as "False Positive" or "Ignore")
TLSv1.3 RFC published
https://www.openssl.org/policies/releasestrat.html



From levitte at openssl.org  Mon Mar 19 08:35:41 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 09:35:41 +0100 (CET)
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
Message-ID: <20180319.093541.148432787073882763.levitte@openssl.org>

In message <15c91d39-bf3c-86e7-6666-756bc942dc95 at ncp-e.com> on Mon, 19 Mar 2018 09:27:40 +0100, "Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com> said:

Matthias.St.Pierre> Hi,
Matthias.St.Pierre> 
Matthias.St.Pierre> in view of the upcoming beta release and the release strategy (see
Matthias.St.Pierre> below) it is a little bit disturbing that our GitHub milestone for 1.1.1
Matthias.St.Pierre> <https://github.com/openssl/openssl/milestone/9> shows only 30%
Matthias.St.Pierre> completion. How are we going to deal with this? Shouldn't the PR's and
Matthias.St.Pierre> issues be examined and categorized into bugs and features? The former
Matthias.St.Pierre> could still be merged during beta, but what happens to the latter? What
Matthias.St.Pierre> is with outstanding documentation (e.g. #5461, #5629), will it be
Matthias.St.Pierre> treated like a bugfix and be mergeable past the beta freeze?

I'd categorically say that missing documentation is a bug.  That
should make categorisation a bit easier...

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Mar 19 09:12:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 09:12:06 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
Message-ID: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>



On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> in view of the upcoming beta release and the release strategy (see
> below) it is a little bit disturbing that our GitHub milestone for 1.1.1
> <https://github.com/openssl/openssl/milestone/9> shows only 30%
> completion. How are we going to deal with this?

Up until now, understandably, people have been focusing on getting the
required features in. My expectation is that, once we're past the beta
release and new features are no longer allowed for 1.1.1, focus will
shift to closing off as many of the open issues/PRs as possible.

> Shouldn't the PR's and
> issues be examined and categorized into bugs and features? The former
> could still be merged during beta, but what happens to the latter? What
> is with outstanding documentation (e.g. #5461, #5629), will it be
> treated like a bugfix and be mergeable past the beta freeze?

Mostly, I think what remains are bugs and not features. If there are
features then no one cared enough about them to push them forward to get
into 1.1.1 and so we should reclassify them with a post-1.1.1 milestone.
In some exceptional cases, if someone can make a good enough case, we
might consider merging them during the beta - but that might take an omc
vote, so the case would have to be very strong.

We have always treated missing documentation as a bug so I don't see a
problem there.

Matt

> 
> Regards,
> Matthias
> 
> --
> We have defined the following release criteria for 1.1.1:
> 
> All open github issues/PRs older than 2 weeks at the time of release to
> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1 milestone
> to be closed (see below)
> Clean builds in Travis and Appveyor for two days
> run-checker.sh to be showing as clean 2 days before release
> No open Coverity issues (not flagged as "False Positive" or "Ignore")
> TLSv1.3 RFC published
> https://www.openssl.org/policies/releasestrat.html
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Mon Mar 19 10:00:01 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 10:00:01 +0000
Subject: [openssl-project] Code freeze later today
Message-ID: <4dca049c-d740-2863-1ab9-eede1cfdd5a0@openssl.org>

Just a reminder that beta1 is scheduled for release tomorrow so, in
preparation for that, I will be freezing the repo later today. Of course
this really means feature freeze as well since this will be your last
opportunity to push features before the beta release. So if there is
anything still outstanding, please get it pushed asap!

Matt

From levitte at openssl.org  Mon Mar 19 10:58:41 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 11:58:41 +0100
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
 <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
Message-ID: <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>

Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot.

I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort.

Note: this affects VMS only, at least re make variables.

Cheers
Richard

(*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this:

     /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")

The same goes for include paths, similarly collected in the qualifier /INCLUDE


Matt Caswell <matt at openssl.org> skrev: (19 mars 2018 10:12:06 CET)
>
>
>On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
>> Hi,
>> 
>> in view of the upcoming beta release and the release strategy (see
>> below) it is a little bit disturbing that our GitHub milestone for
>1.1.1
>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
>> completion. How are we going to deal with this?
>
>Up until now, understandably, people have been focusing on getting the
>required features in. My expectation is that, once we're past the beta
>release and new features are no longer allowed for 1.1.1, focus will
>shift to closing off as many of the open issues/PRs as possible.
>
>> Shouldn't the PR's and
>> issues be examined and categorized into bugs and features? The former
>> could still be merged during beta, but what happens to the latter?
>What
>> is with outstanding documentation (e.g. #5461, #5629), will it be
>> treated like a bugfix and be mergeable past the beta freeze?
>
>Mostly, I think what remains are bugs and not features. If there are
>features then no one cared enough about them to push them forward to
>get
>into 1.1.1 and so we should reclassify them with a post-1.1.1
>milestone.
>In some exceptional cases, if someone can make a good enough case, we
>might consider merging them during the beta - but that might take an
>omc
>vote, so the case would have to be very strong.
>
>We have always treated missing documentation as a bug so I don't see a
>problem there.
>
>Matt
>
>> 
>> Regards,
>> Matthias
>> 
>> --
>> We have defined the following release criteria for 1.1.1:
>> 
>> All open github issues/PRs older than 2 weeks at the time of release
>to
>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
>milestone
>> to be closed (see below)
>> Clean builds in Travis and Appveyor for two days
>> run-checker.sh to be showing as clean 2 days before release
>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
>> TLSv1.3 RFC published
>> https://www.openssl.org/policies/releasestrat.html
>> 
>> 
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>> 
>_______________________________________________
>openssl-project mailing list
>openssl-project at openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From matt at openssl.org  Mon Mar 19 11:14:27 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 11:14:27 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
 <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
Message-ID: <7aa44215-febf-73d2-3d0f-12f99b44b8aa@openssl.org>



On 19/03/18 10:58, Richard Levitte wrote:
> Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot.
> 
> I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort.

Well what is a "fix" has always been a bit of a grey area.

Does the proposed change offer new capabilities to the user that they
didn't have before?

If the answer is "yes" that tends to indicate a feature.

Does the proposed change fix existing capabilities so that they work as
originally intended?

An answer of "yes" to that tends to indicate a fix.

It becomes more difficult when something is a a general clean up or
optimisation of existing code. In which case nothing is fixed, but it
also doesn't provide new capabilities to the user either.

In the past, sometimes we have let this sort of thing through and
sometimes not. I suppose it comes down to the scale of the change and
risk associated with it. For example the WPACKET refactor didn't make it
into 1.1.0. It wasn't a new feature and was a clean up of existing code.
We didn't backport it because the scale of the change and risk
associated with it is too great. On the other hand if a change is much
more localised with a low level of risk then we might allow it. Probably
we make these decisions on a case by case basis, unless someone can
think of some better "rules".

I haven't got a good understanding of the particular change you are
proposing to be able to say where in all of this that one fits.

Matt

> 
> Note: this affects VMS only, at least re make variables.
> 
> Cheers
> Richard
> 
> (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this:
> 
>      /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
> 
> The same goes for include paths, similarly collected in the qualifier /INCLUDE
> 
> 
> Matt Caswell <matt at openssl.org> skrev: (19 mars 2018 10:12:06 CET)
>>
>>
>> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
>>> Hi,
>>>
>>> in view of the upcoming beta release and the release strategy (see
>>> below) it is a little bit disturbing that our GitHub milestone for
>> 1.1.1
>>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
>>> completion. How are we going to deal with this?
>>
>> Up until now, understandably, people have been focusing on getting the
>> required features in. My expectation is that, once we're past the beta
>> release and new features are no longer allowed for 1.1.1, focus will
>> shift to closing off as many of the open issues/PRs as possible.
>>
>>> Shouldn't the PR's and
>>> issues be examined and categorized into bugs and features? The former
>>> could still be merged during beta, but what happens to the latter?
>> What
>>> is with outstanding documentation (e.g. #5461, #5629), will it be
>>> treated like a bugfix and be mergeable past the beta freeze?
>>
>> Mostly, I think what remains are bugs and not features. If there are
>> features then no one cared enough about them to push them forward to
>> get
>> into 1.1.1 and so we should reclassify them with a post-1.1.1
>> milestone.
>> In some exceptional cases, if someone can make a good enough case, we
>> might consider merging them during the beta - but that might take an
>> omc
>> vote, so the case would have to be very strong.
>>
>> We have always treated missing documentation as a bug so I don't see a
>> problem there.
>>
>> Matt
>>
>>>
>>> Regards,
>>> Matthias
>>>
>>> --
>>> We have defined the following release criteria for 1.1.1:
>>>
>>> All open github issues/PRs older than 2 weeks at the time of release
>> to
>>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
>> milestone
>>> to be closed (see below)
>>> Clean builds in Travis and Appveyor for two days
>>> run-checker.sh to be showing as clean 2 days before release
>>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
>>> TLSv1.3 RFC published
>>> https://www.openssl.org/policies/releasestrat.html
>>>
>>>
>>> _______________________________________________
>>> openssl-project mailing list
>>> openssl-project at openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Mon Mar 19 11:52:11 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 12:52:11 +0100 (CET)
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <7aa44215-febf-73d2-3d0f-12f99b44b8aa@openssl.org>
References: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <7aa44215-febf-73d2-3d0f-12f99b44b8aa@openssl.org>
Message-ID: <20180319.125211.1064322115131682794.levitte@openssl.org>

In message <7aa44215-febf-73d2-3d0f-12f99b44b8aa at openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 19/03/18 10:58, Richard Levitte wrote:
matt> > Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot.
matt> > 
matt> > I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort.
matt> 
matt> Well what is a "fix" has always been a bit of a grey area.
matt> 
matt> Does the proposed change offer new capabilities to the user that they
matt> didn't have before?
matt> 
matt> If the answer is "yes" that tends to indicate a feature.

So I'll answer "yes and no", with a bit of explanation.

The whole thing with supporting the use of "make variables" with
Configure in GNU autoconf style is a new feature, but that's already
in, so I count that is already existing capabilities re the beta
release.

Being able to define macros and include directories via CPPFLAGS is
thusly already available...  except that for VMS users, we have
CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.

So phrased "being able to define extra C macros and include
directories via 'make variables' when configuring", this is not a new
capability.  However, phrased "being able to define extra C macros and
include directories via CPPFLAGS in when configuring", this could be
viewed as a new capability.

matt> Does the proposed change fix existing capabilities so that they
matt> work as originally intended?
matt> 
matt> An answer of "yes" to that tends to indicate a fix.

Well, I could say "yes" if the original intent is phrased "CPPFLAGS
is used for all C preprocessor flags"...  which is the usual intent,
at least on platforms with Unix style flags, and considering CPPFLAGS
has originated on Unix as far as I know, ...

matt> I haven't got a good understanding of the particular change you
matt> are proposing to be able to say where in all of this that one
matt> fits.

The idea I have would affect Configurations/descrip.mms.tmpl more or
less entirely, and would be to parse $config{CPPFLAGS}, extract and
put aside any macro definitions and include directory specs and put
back the rest of what was parsed back in $config{CPPFLAGS}, and use
the extracted macro definitions and include directory specs further
on, in these lines:

    DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -}
    INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}

What happens in practice is that $config{CPPDEFINES} and
$config{CPPINCLUDES} would stop existing, and template internal
variables would take their place in those two lines.

And of course, all traces of CPPDEFINES and CPPINCLUDES would be
removed anywhere else...  that's mostly config and Configure.

Cheers,
Richard

matt> 
matt> Matt
matt> 
matt> > 
matt> > Note: this affects VMS only, at least re make variables.
matt> > 
matt> > Cheers
matt> > Richard
matt> > 
matt> > (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this:
matt> > 
matt> >      /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
matt> > 
matt> > The same goes for include paths, similarly collected in the qualifier /INCLUDE
matt> > 
matt> > 
matt> > Matt Caswell <matt at openssl.org> skrev: (19 mars 2018 10:12:06 CET)
matt> >>
matt> >>
matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
matt> >>> Hi,
matt> >>>
matt> >>> in view of the upcoming beta release and the release strategy (see
matt> >>> below) it is a little bit disturbing that our GitHub milestone for
matt> >> 1.1.1
matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
matt> >>> completion. How are we going to deal with this?
matt> >>
matt> >> Up until now, understandably, people have been focusing on getting the
matt> >> required features in. My expectation is that, once we're past the beta
matt> >> release and new features are no longer allowed for 1.1.1, focus will
matt> >> shift to closing off as many of the open issues/PRs as possible.
matt> >>
matt> >>> Shouldn't the PR's and
matt> >>> issues be examined and categorized into bugs and features? The former
matt> >>> could still be merged during beta, but what happens to the latter?
matt> >> What
matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be
matt> >>> treated like a bugfix and be mergeable past the beta freeze?
matt> >>
matt> >> Mostly, I think what remains are bugs and not features. If there are
matt> >> features then no one cared enough about them to push them forward to
matt> >> get
matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1
matt> >> milestone.
matt> >> In some exceptional cases, if someone can make a good enough case, we
matt> >> might consider merging them during the beta - but that might take an
matt> >> omc
matt> >> vote, so the case would have to be very strong.
matt> >>
matt> >> We have always treated missing documentation as a bug so I don't see a
matt> >> problem there.
matt> >>
matt> >> Matt
matt> >>
matt> >>>
matt> >>> Regards,
matt> >>> Matthias
matt> >>>
matt> >>> --
matt> >>> We have defined the following release criteria for 1.1.1:
matt> >>>
matt> >>> All open github issues/PRs older than 2 weeks at the time of release
matt> >> to
matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
matt> >> milestone
matt> >>> to be closed (see below)
matt> >>> Clean builds in Travis and Appveyor for two days
matt> >>> run-checker.sh to be showing as clean 2 days before release
matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
matt> >>> TLSv1.3 RFC published
matt> >>> https://www.openssl.org/policies/releasestrat.html
matt> >>>
matt> >>>
matt> >>> _______________________________________________
matt> >>> openssl-project mailing list
matt> >>> openssl-project at openssl.org
matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> >>>
matt> >> _______________________________________________
matt> >> openssl-project mailing list
matt> >> openssl-project at openssl.org
matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From matt at openssl.org  Mon Mar 19 11:56:23 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 11:56:23 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <20180319.125211.1064322115131682794.levitte@openssl.org>
References: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <7aa44215-febf-73d2-3d0f-12f99b44b8aa@openssl.org>
 <20180319.125211.1064322115131682794.levitte@openssl.org>
Message-ID: <a55791e9-83d8-199d-9d8b-c6157e16452c@openssl.org>

This is definitely in the grey area, but I tend to think it is more
towards the "fix" side than the "feature" side. Also the risk is
significantly mitigated by it only impacting VMS.

Matt


On 19/03/18 11:52, Richard Levitte wrote:
> In message <7aa44215-febf-73d2-3d0f-12f99b44b8aa at openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> 
> matt> 
> matt> On 19/03/18 10:58, Richard Levitte wrote:
> matt> > Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot.
> matt> > 
> matt> > I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort.
> matt> 
> matt> Well what is a "fix" has always been a bit of a grey area.
> matt> 
> matt> Does the proposed change offer new capabilities to the user that they
> matt> didn't have before?
> matt> 
> matt> If the answer is "yes" that tends to indicate a feature.
> 
> So I'll answer "yes and no", with a bit of explanation.
> 
> The whole thing with supporting the use of "make variables" with
> Configure in GNU autoconf style is a new feature, but that's already
> in, so I count that is already existing capabilities re the beta
> release.
> 
> Being able to define macros and include directories via CPPFLAGS is
> thusly already available...  except that for VMS users, we have
> CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.
> 
> So phrased "being able to define extra C macros and include
> directories via 'make variables' when configuring", this is not a new
> capability.  However, phrased "being able to define extra C macros and
> include directories via CPPFLAGS in when configuring", this could be
> viewed as a new capability.
> 
> matt> Does the proposed change fix existing capabilities so that they
> matt> work as originally intended?
> matt> 
> matt> An answer of "yes" to that tends to indicate a fix.
> 
> Well, I could say "yes" if the original intent is phrased "CPPFLAGS
> is used for all C preprocessor flags"...  which is the usual intent,
> at least on platforms with Unix style flags, and considering CPPFLAGS
> has originated on Unix as far as I know, ...
> 
> matt> I haven't got a good understanding of the particular change you
> matt> are proposing to be able to say where in all of this that one
> matt> fits.
> 
> The idea I have would affect Configurations/descrip.mms.tmpl more or
> less entirely, and would be to parse $config{CPPFLAGS}, extract and
> put aside any macro definitions and include directory specs and put
> back the rest of what was parsed back in $config{CPPFLAGS}, and use
> the extracted macro definitions and include directory specs further
> on, in these lines:
> 
>     DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -}
>     INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}
> 
> What happens in practice is that $config{CPPDEFINES} and
> $config{CPPINCLUDES} would stop existing, and template internal
> variables would take their place in those two lines.
> 
> And of course, all traces of CPPDEFINES and CPPINCLUDES would be
> removed anywhere else...  that's mostly config and Configure.
> 
> Cheers,
> Richard
> 
> matt> 
> matt> Matt
> matt> 
> matt> > 
> matt> > Note: this affects VMS only, at least re make variables.
> matt> > 
> matt> > Cheers
> matt> > Richard
> matt> > 
> matt> > (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this:
> matt> > 
> matt> >      /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
> matt> > 
> matt> > The same goes for include paths, similarly collected in the qualifier /INCLUDE
> matt> > 
> matt> > 
> matt> > Matt Caswell <matt at openssl.org> skrev: (19 mars 2018 10:12:06 CET)
> matt> >>
> matt> >>
> matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
> matt> >>> Hi,
> matt> >>>
> matt> >>> in view of the upcoming beta release and the release strategy (see
> matt> >>> below) it is a little bit disturbing that our GitHub milestone for
> matt> >> 1.1.1
> matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
> matt> >>> completion. How are we going to deal with this?
> matt> >>
> matt> >> Up until now, understandably, people have been focusing on getting the
> matt> >> required features in. My expectation is that, once we're past the beta
> matt> >> release and new features are no longer allowed for 1.1.1, focus will
> matt> >> shift to closing off as many of the open issues/PRs as possible.
> matt> >>
> matt> >>> Shouldn't the PR's and
> matt> >>> issues be examined and categorized into bugs and features? The former
> matt> >>> could still be merged during beta, but what happens to the latter?
> matt> >> What
> matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be
> matt> >>> treated like a bugfix and be mergeable past the beta freeze?
> matt> >>
> matt> >> Mostly, I think what remains are bugs and not features. If there are
> matt> >> features then no one cared enough about them to push them forward to
> matt> >> get
> matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1
> matt> >> milestone.
> matt> >> In some exceptional cases, if someone can make a good enough case, we
> matt> >> might consider merging them during the beta - but that might take an
> matt> >> omc
> matt> >> vote, so the case would have to be very strong.
> matt> >>
> matt> >> We have always treated missing documentation as a bug so I don't see a
> matt> >> problem there.
> matt> >>
> matt> >> Matt
> matt> >>
> matt> >>>
> matt> >>> Regards,
> matt> >>> Matthias
> matt> >>>
> matt> >>> --
> matt> >>> We have defined the following release criteria for 1.1.1:
> matt> >>>
> matt> >>> All open github issues/PRs older than 2 weeks at the time of release
> matt> >> to
> matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
> matt> >> milestone
> matt> >>> to be closed (see below)
> matt> >>> Clean builds in Travis and Appveyor for two days
> matt> >>> run-checker.sh to be showing as clean 2 days before release
> matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
> matt> >>> TLSv1.3 RFC published
> matt> >>> https://www.openssl.org/policies/releasestrat.html
> matt> >>>
> matt> >>>
> matt> >>> _______________________________________________
> matt> >>> openssl-project mailing list
> matt> >>> openssl-project at openssl.org
> matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project
> matt> >>>
> matt> >> _______________________________________________
> matt> >> openssl-project mailing list
> matt> >> openssl-project at openssl.org
> matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project
> matt> > 
> matt> _______________________________________________
> matt> openssl-project mailing list
> matt> openssl-project at openssl.org
> matt> https://mta.openssl.org/mailman/listinfo/openssl-project
> matt> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Mon Mar 19 11:59:20 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 12:59:20 +0100 (CET)
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <a55791e9-83d8-199d-9d8b-c6157e16452c@openssl.org>
References: <7aa44215-febf-73d2-3d0f-12f99b44b8aa@openssl.org>
 <20180319.125211.1064322115131682794.levitte@openssl.org>
 <a55791e9-83d8-199d-9d8b-c6157e16452c@openssl.org>
Message-ID: <20180319.125920.448781637919095076.levitte@openssl.org>

Ok.  I see it the same way, and indications are that others would
agree as well...

In message <a55791e9-83d8-199d-9d8b-c6157e16452c at openssl.org> on Mon, 19 Mar 2018 11:56:23 +0000, Matt Caswell <matt at openssl.org> said:

matt> This is definitely in the grey area, but I tend to think it is more
matt> towards the "fix" side than the "feature" side. Also the risk is
matt> significantly mitigated by it only impacting VMS.
matt> 
matt> Matt
matt> 
matt> 
matt> On 19/03/18 11:52, Richard Levitte wrote:
matt> > In message <7aa44215-febf-73d2-3d0f-12f99b44b8aa at openssl.org> on Mon, 19 Mar 2018 11:14:27 +0000, Matt Caswell <matt at openssl.org> said:
matt> > 
matt> > matt> 
matt> > matt> 
matt> > matt> On 19/03/18 10:58, Richard Levitte wrote:
matt> > matt> > Andy has indicated that the rather special construction to get command line C macro definitions and include paths specs collected in one place (*) is perhaps too special and could be handle by parsing CPPFLAGS and extra multiple definitions to get them collected in one spot.
matt> > matt> > 
matt> > matt> > I have some ideas on how to do that, but wonder if that would be considered a new feature with regards to the beta release (we can stop talking now in that case) or if this would be considered a fix. That will decide if it's even worth an effort.
matt> > matt> 
matt> > matt> Well what is a "fix" has always been a bit of a grey area.
matt> > matt> 
matt> > matt> Does the proposed change offer new capabilities to the user that they
matt> > matt> didn't have before?
matt> > matt> 
matt> > matt> If the answer is "yes" that tends to indicate a feature.
matt> > 
matt> > So I'll answer "yes and no", with a bit of explanation.
matt> > 
matt> > The whole thing with supporting the use of "make variables" with
matt> > Configure in GNU autoconf style is a new feature, but that's already
matt> > in, so I count that is already existing capabilities re the beta
matt> > release.
matt> > 
matt> > Being able to define macros and include directories via CPPFLAGS is
matt> > thusly already available...  except that for VMS users, we have
matt> > CPPDEFINES and CPPINCLUDES to deal with the VMS command line syntax.
matt> > 
matt> > So phrased "being able to define extra C macros and include
matt> > directories via 'make variables' when configuring", this is not a new
matt> > capability.  However, phrased "being able to define extra C macros and
matt> > include directories via CPPFLAGS in when configuring", this could be
matt> > viewed as a new capability.
matt> > 
matt> > matt> Does the proposed change fix existing capabilities so that they
matt> > matt> work as originally intended?
matt> > matt> 
matt> > matt> An answer of "yes" to that tends to indicate a fix.
matt> > 
matt> > Well, I could say "yes" if the original intent is phrased "CPPFLAGS
matt> > is used for all C preprocessor flags"...  which is the usual intent,
matt> > at least on platforms with Unix style flags, and considering CPPFLAGS
matt> > has originated on Unix as far as I know, ...
matt> > 
matt> > matt> I haven't got a good understanding of the particular change you
matt> > matt> are proposing to be able to say where in all of this that one
matt> > matt> fits.
matt> > 
matt> > The idea I have would affect Configurations/descrip.mms.tmpl more or
matt> > less entirely, and would be to parse $config{CPPFLAGS}, extract and
matt> > put aside any macro definitions and include directory specs and put
matt> > back the rest of what was parsed back in $config{CPPFLAGS}, and use
matt> > the extracted macro definitions and include directory specs further
matt> > on, in these lines:
matt> > 
matt> >     DEFINES={- our $defines1 = join('', map { ",$_" } @{$config{CPPDEFINES}}) -}
matt> >     INCLUDES={- our $includes1 = join(',', @{$config{CPPINCLUDES}}) -}
matt> > 
matt> > What happens in practice is that $config{CPPDEFINES} and
matt> > $config{CPPINCLUDES} would stop existing, and template internal
matt> > variables would take their place in those two lines.
matt> > 
matt> > And of course, all traces of CPPDEFINES and CPPINCLUDES would be
matt> > removed anywhere else...  that's mostly config and Configure.
matt> > 
matt> > Cheers,
matt> > Richard
matt> > 
matt> > matt> 
matt> > matt> Matt
matt> > matt> 
matt> > matt> > 
matt> > matt> > Note: this affects VMS only, at least re make variables.
matt> > matt> > 
matt> > matt> > Cheers
matt> > matt> > Richard
matt> > matt> > 
matt> > matt> > (*) Unix and windows handles those with -D and -I flags that can be spread out all over the command line. VMS command lines work a bit differently, and the C compiler complies with that standard, so *all* macros must be collected in *one* qualifiers (VMS terminology where the Unix guy would say "flag" or possibly "option"), like this:
matt> > matt> > 
matt> > matt> >      /DEFINE=(MACRO1, MACRO2="Foo", "Macro3=bar")
matt> > matt> > 
matt> > matt> > The same goes for include paths, similarly collected in the qualifier /INCLUDE
matt> > matt> > 
matt> > matt> > 
matt> > matt> > Matt Caswell <matt at openssl.org> skrev: (19 mars 2018 10:12:06 CET)
matt> > matt> >>
matt> > matt> >>
matt> > matt> >> On 19/03/18 08:27, Dr. Matthias St. Pierre wrote:
matt> > matt> >>> Hi,
matt> > matt> >>>
matt> > matt> >>> in view of the upcoming beta release and the release strategy (see
matt> > matt> >>> below) it is a little bit disturbing that our GitHub milestone for
matt> > matt> >> 1.1.1
matt> > matt> >>> <https://github.com/openssl/openssl/milestone/9> shows only 30%
matt> > matt> >>> completion. How are we going to deal with this?
matt> > matt> >>
matt> > matt> >> Up until now, understandably, people have been focusing on getting the
matt> > matt> >> required features in. My expectation is that, once we're past the beta
matt> > matt> >> release and new features are no longer allowed for 1.1.1, focus will
matt> > matt> >> shift to closing off as many of the open issues/PRs as possible.
matt> > matt> >>
matt> > matt> >>> Shouldn't the PR's and
matt> > matt> >>> issues be examined and categorized into bugs and features? The former
matt> > matt> >>> could still be merged during beta, but what happens to the latter?
matt> > matt> >> What
matt> > matt> >>> is with outstanding documentation (e.g. #5461, #5629), will it be
matt> > matt> >>> treated like a bugfix and be mergeable past the beta freeze?
matt> > matt> >>
matt> > matt> >> Mostly, I think what remains are bugs and not features. If there are
matt> > matt> >> features then no one cared enough about them to push them forward to
matt> > matt> >> get
matt> > matt> >> into 1.1.1 and so we should reclassify them with a post-1.1.1
matt> > matt> >> milestone.
matt> > matt> >> In some exceptional cases, if someone can make a good enough case, we
matt> > matt> >> might consider merging them during the beta - but that might take an
matt> > matt> >> omc
matt> > matt> >> vote, so the case would have to be very strong.
matt> > matt> >>
matt> > matt> >> We have always treated missing documentation as a bug so I don't see a
matt> > matt> >> problem there.
matt> > matt> >>
matt> > matt> >> Matt
matt> > matt> >>
matt> > matt> >>>
matt> > matt> >>> Regards,
matt> > matt> >>> Matthias
matt> > matt> >>>
matt> > matt> >>> --
matt> > matt> >>> We have defined the following release criteria for 1.1.1:
matt> > matt> >>>
matt> > matt> >>> All open github issues/PRs older than 2 weeks at the time of release
matt> > matt> >> to
matt> > matt> >>> be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
matt> > matt> >> milestone
matt> > matt> >>> to be closed (see below)
matt> > matt> >>> Clean builds in Travis and Appveyor for two days
matt> > matt> >>> run-checker.sh to be showing as clean 2 days before release
matt> > matt> >>> No open Coverity issues (not flagged as "False Positive" or "Ignore")
matt> > matt> >>> TLSv1.3 RFC published
matt> > matt> >>> https://www.openssl.org/policies/releasestrat.html
matt> > matt> >>>
matt> > matt> >>>
matt> > matt> >>> _______________________________________________
matt> > matt> >>> openssl-project mailing list
matt> > matt> >>> openssl-project at openssl.org
matt> > matt> >>> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > matt> >>>
matt> > matt> >> _______________________________________________
matt> > matt> >> openssl-project mailing list
matt> > matt> >> openssl-project at openssl.org
matt> > matt> >> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > matt> > 
matt> > matt> _______________________________________________
matt> > matt> openssl-project mailing list
matt> > matt> openssl-project at openssl.org
matt> > matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > matt> 
matt> > _______________________________________________
matt> > openssl-project mailing list
matt> > openssl-project at openssl.org
matt> > https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From rsalz at akamai.com  Mon Mar 19 12:27:19 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 19 Mar 2018 12:27:19 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
 <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
Message-ID: <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>

I would consider it a bug-fix FWIW.

I thought we extended the deadline so that we could review more third-party PR's.    I'm still waiting on an e_os/Microsoft cleanup, but getting community stuff in is more important.
 


From tjh at cryptsoft.com  Mon Mar 19 12:29:45 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Mon, 19 Mar 2018 22:29:45 +1000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
References: <15c91d39-bf3c-86e7-6666-756bc942dc95@ncp-e.com>
 <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
Message-ID: <CAHEJ-S5e1B8Hc9pTdf278dmMaA_OhdXzodWwTvr=6BFpG9yugw@mail.gmail.com>

I too see this in the "bug fix" area - although you can make a reasonable
counter argument (but I don't see a lot of point in doing so).
Improving the build environment is a good thing IMHO ...

Tim.


On Mon, Mar 19, 2018 at 10:27 PM, Salz, Rich <rsalz at akamai.com> wrote:

> I would consider it a bug-fix FWIW.
>
> I thought we extended the deadline so that we could review more
> third-party PR's.    I'm still waiting on an e_os/Microsoft cleanup, but
> getting community stuff in is more important.
>
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180319/f202aa70/attachment.html>

From levitte at openssl.org  Mon Mar 19 12:42:38 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 13:42:38 +0100 (CET)
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
References: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
Message-ID: <20180319.134238.88480374879959654.levitte@openssl.org>

In message <001364A7-E3C5-4E2B-8F0B-6ED1A041F973 at akamai.com> on Mon, 19 Mar 2018 12:27:19 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I would consider it a bug-fix FWIW.
rsalz> 
rsalz> I thought we extended the deadline so that we could review more
rsalz> third-party PR's.    I'm still waiting on an e_os/Microsoft
rsalz> cleanup, but getting community stuff in is more important.

I did a quick sweep last week through those that were marked with
milestone 1.1.1 or no milestone at all, and found most to be of the
category "fix"...  there were a few that I was wondering about, and I
hope I at least pinged them.

There's one I know where we need to make a judgement call.  PR 4793
"(WIP) An implementation of the Chinese SM2 ECC".  I intended to have
a look last week, but didn't.  That one's a lot for me to take in, and
ECC is most decidly not one of my fortes...

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Mon Mar 19 12:47:05 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 19 Mar 2018 12:47:05 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <20180319.134238.88480374879959654.levitte@openssl.org>
References: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
 <20180319.134238.88480374879959654.levitte@openssl.org>
Message-ID: <97CFF4A5-DE0E-4D17-8A07-242961D6FADA@akamai.com>

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. 


From matt at openssl.org  Mon Mar 19 12:57:01 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 12:57:01 +0000
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <97CFF4A5-DE0E-4D17-8A07-242961D6FADA@akamai.com>
References: <6bdcd029-d4b7-6f43-fd93-ebaa46b43abe@openssl.org>
 <32617CE7-0CE2-4681-B1F5-7DD7D4CB0604@openssl.org>
 <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
 <20180319.134238.88480374879959654.levitte@openssl.org>
 <97CFF4A5-DE0E-4D17-8A07-242961D6FADA@akamai.com>
Message-ID: <003efef4-0a68-f88b-22eb-d81829ba155a@openssl.org>



On 19/03/18 12:47, Salz, Rich wrote:
> various no-XXX builds. 

In my mind run-checker is a CI just like travis and appveyor. If
something is failing in run-checker (i.e. a no-XXX build) then its a
"must fix" asap. Otherwise these errors tend to accumulate and it
becomes harder and harder to fix them - plus you can't see when you've
introduced a new break.

Matt


From levitte at openssl.org  Mon Mar 19 13:10:47 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 14:10:47 +0100 (CET)
Subject: [openssl-project] GitHub milestone for 1.1.1
In-Reply-To: <97CFF4A5-DE0E-4D17-8A07-242961D6FADA@akamai.com>
References: <001364A7-E3C5-4E2B-8F0B-6ED1A041F973@akamai.com>
 <20180319.134238.88480374879959654.levitte@openssl.org>
 <97CFF4A5-DE0E-4D17-8A07-242961D6FADA@akamai.com>
Message-ID: <20180319.141047.713001537591505865.levitte@openssl.org>

In message <97CFF4A5-DE0E-4D17-8A07-242961D6FADA at akamai.com> on Mon, 19 Mar 2018 12:47:05 +0000, "Salz, Rich" <rsalz at akamai.com> said:

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

I just looked through the SM2 PR and apart from a need for rebase
(which is all about 'make update', so quite frankly, I think that can
fall on whoever merges...  I'm just tried, it took me 5 minutes).

I'm willing to approve it as it stands.  Everything that stung my eye
earlier has been changed to something a lot better.  The only thing
that still stings my eye is those public SM2 functions, but I would
see their removal as a fix, so...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Mar 19 16:33:57 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 16:33:57 +0000
Subject: [openssl-project] Anything else to go in before I call the freeze?
Message-ID: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>

Let me know asap...


Matt

From matt at openssl.org  Mon Mar 19 16:48:29 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 16:48:29 +0000
Subject: [openssl-project] Anything else to go in before I call the
 freeze?
In-Reply-To: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
References: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
Message-ID: <3aeb3ebd-e225-97dc-cbd7-c87e20b46e15@openssl.org>

BTW please review #5673. I'd like a clean run from run-checker for the
release tomorrow.

Matt

On 19/03/18 16:33, Matt Caswell wrote:
> Let me know asap...
> 
> 
> Matt
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Mon Mar 19 17:00:07 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 19 Mar 2018 18:00:07 +0100 (CET)
Subject: [openssl-project] Anything else to go in before I call the
 freeze?
In-Reply-To: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
References: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
Message-ID: <20180319.180007.1493989477682124971.levitte@openssl.org>

In message <1ab966c8-02d4-cf1f-504a-a54999a7ce14 at openssl.org> on Mon, 19 Mar 2018 16:33:57 +0000, Matt Caswell <matt at openssl.org> said:

matt> Let me know asap...

#5662 #5663

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Mar 19 18:25:44 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 19 Mar 2018 18:25:44 +0000
Subject: [openssl-project] Anything else to go in before I call the
 freeze?
In-Reply-To: <3aeb3ebd-e225-97dc-cbd7-c87e20b46e15@openssl.org>
References: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
 <3aeb3ebd-e225-97dc-cbd7-c87e20b46e15@openssl.org>
Message-ID: <3efe1831-1b63-8bea-9d18-931dd53b14e8@openssl.org>

Please can someone freeze the repo for me:

$ ssh openssl-git at git.openssl.org freeze openssl matt

I will still take #5677 "Fix no-sm3 (and no-sm2)" after the freeze. Also
if anyone can come up with a fix for the failing master in Travis that
would be good.

Matt


On 19/03/18 16:48, Matt Caswell wrote:
> BTW please review #5673. I'd like a clean run from run-checker for the
> release tomorrow.
> 
> Matt
> 
> On 19/03/18 16:33, Matt Caswell wrote:
>> Let me know asap...
>>
>>
>> Matt
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>

From bernd.edlinger at hotmail.de  Mon Mar 19 18:36:47 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Mon, 19 Mar 2018 18:36:47 +0000
Subject: [openssl-project] Anything else to go in before I call the
 freeze?
In-Reply-To: <3efe1831-1b63-8bea-9d18-931dd53b14e8@openssl.org>
References: <1ab966c8-02d4-cf1f-504a-a54999a7ce14@openssl.org>
 <3aeb3ebd-e225-97dc-cbd7-c87e20b46e15@openssl.org>
 <3efe1831-1b63-8bea-9d18-931dd53b14e8@openssl.org>
Message-ID: <AM5PR0701MB2657A976D2B4CCD568AB3F7EE4D40@AM5PR0701MB2657.eurprd07.prod.outlook.com>

OK, I freezed the repository for you.

On 03/19/18 19:25, Matt Caswell wrote:
> Please can someone freeze the repo for me:
> 
> $ ssh openssl-git at git.openssl.org freeze openssl matt
> 
> I will still take #5677 "Fix no-sm3 (and no-sm2)" after the freeze. Also
> if anyone can come up with a fix for the failing master in Travis that
> would be good.
> 
> Matt
> 
> 
> On 19/03/18 16:48, Matt Caswell wrote:
>> BTW please review #5673. I'd like a clean run from run-checker for the
>> release tomorrow.
>>
>> Matt
>>
>> On 19/03/18 16:33, Matt Caswell wrote:
>>> Let me know asap...
>>>
>>>
>>> Matt
>>> _______________________________________________
>>> openssl-project mailing list
>>> openssl-project at openssl.org
>>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From openssl at openssl.org  Tue Mar 20 14:09:13 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 20 Mar 2018 14:09:13 +0000
Subject: [openssl-project] OpenSSL version 1.1.1 pre release 3 published
Message-ID: <20180320140913.GA11276@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.1 pre release 3 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 3 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre3.tar.gz
      Size: 6552052
      SHA1 checksum: a9dee6b70334726420f483c496216d2b335a4510
      SHA256 checksum: b541d574d8d099b0bc74ebc8174cec1dc9f426d8901d04be7874046ad72116b0

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre3.tar.gz
    openssl sha256 openssl-1.1.1-pre3.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJasQkhAAoJENnE0m0OYESRf30H/1OxOdWi82Cw69+z4ly80TyR
IeWQRgFh60lar3li3R6/ns57eXFo7jGOAAws1iOZll3RGR9bkp70cLXCZtMvZoEP
79pLrfUZR6s6BwGrSs7X3fHac4muUZSQLaAdCJG5Y6Sgi2XBy0rRYFxle0qND1c3
tNeh1B6oXy236cvVaDAUNYKEC/31RzupWIdLdT9UYWLU5qYdgkaOztHO2x1pDRX/
Vs18qNND5mHIrsv0QfZPP40nvsZrRoz7rXBuZdaQwLA9ZJzS0hNxwlpkodJB8kHD
o29Q0fkczGnL3hw5rSi7c+qKgngXIVkB0ssisZBHgHVAA6WvvSPNG9SeGYJRgwQ=
=0UFn
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Mar 20 14:17:20 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 20 Mar 2018 14:17:20 +0000
Subject: [openssl-project] Code Repo
Message-ID: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>

The beta release is now complete.

Important:

We did *not* create the OpenSSL_1_1_1-stable branch as planned (see
https://github.com/openssl/openssl/pull/5690 for the discussion that led
to that decision). For now the release was done from the master branch
in the same way as we did for the previous alpha releases. However the
feature freeze *is* in force. Therefore no features can be pushed into
the repo until such time as the branch is created. All commits to master
must be suitable for inclusion in the 1.1.1 release.

Matt

From matt at openssl.org  Tue Mar 20 14:20:16 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 20 Mar 2018 14:20:16 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
Message-ID: <bdec4ca5-da9f-cebd-dbdd-d4dd3c525bd5@openssl.org>

Of course I should have mentioned that although the feature freeze is in
place, the code freeze is not, i.e. you can make pushes to the repo now.

Matt


On 20/03/18 14:17, Matt Caswell wrote:
> The beta release is now complete.
> 
> Important:
> 
> We did *not* create the OpenSSL_1_1_1-stable branch as planned (see
> https://github.com/openssl/openssl/pull/5690 for the discussion that led
> to that decision). For now the release was done from the master branch
> in the same way as we did for the previous alpha releases. However the
> feature freeze *is* in force. Therefore no features can be pushed into
> the repo until such time as the branch is created. All commits to master
> must be suitable for inclusion in the 1.1.1 release.
> 
> Matt
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From tjh at cryptsoft.com  Tue Mar 20 14:27:13 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Wed, 21 Mar 2018 00:27:13 +1000
Subject: [openssl-project] Code Repo
In-Reply-To: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
Message-ID: <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>

We have been holding off on post-1.1.1 feature development for a long time
now - on the grounds that TLSv1.3 was just around the corner etc and the
release was close - and then we formed a release plan which we pushed back
a week.

It is long overdue that we get to start moving those other things forward
in my view.
We had planned to start moving around a pile of stuff for FIPS related
items - and keeping master locked for API changes really works against that.

There are a large range of PRs which we pushed off as
must-wait-for-post-1.1.1 and those are things that remain stalled as long
as we keep master locked down.

The release for 1.1.1 should be pretty close to "complete" as such -
looking at the plans - as with no new features going in the work remaining
should be relatively staight forward.
Rich's suggestions I think tend to indicate more  work going into the
release that planned - and we had said we were creating this branch - and
deviating from that at the last minute isn't really how we shuold be making
decisions as a project.
Some stuff that would normally be in a banch now isn't ... as Richard noted
in the PR.

Tim.


On Wed, Mar 21, 2018 at 12:17 AM, Matt Caswell <matt at openssl.org> wrote:

> The beta release is now complete.
>
> Important:
>
> We did *not* create the OpenSSL_1_1_1-stable branch as planned (see
> https://github.com/openssl/openssl/pull/5690 for the discussion that led
> to that decision). For now the release was done from the master branch
> in the same way as we did for the previous alpha releases. However the
> feature freeze *is* in force. Therefore no features can be pushed into
> the repo until such time as the branch is created. All commits to master
> must be suitable for inclusion in the 1.1.1 release.
>
> Matt
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180321/8da83e93/attachment.html>

From rsalz at akamai.com  Tue Mar 20 14:58:11 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 20 Mar 2018 14:58:11 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
Message-ID: <C95A2B85-3097-4372-905D-74BB6D31E8FA@akamai.com>

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 should be working on is the release.

EVERYONE can do code reviews.

From: Tim Hudson <tjh at cryptsoft.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Tuesday, March 20, 2018 at 10:27 AM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: Re: [openssl-project] Code Repo

We have been holding off on post-1.1.1 feature development for a long time now - on the grounds that TLSv1.3 was just around the corner etc and the release was close - and then we formed a release plan which we pushed back a week.

It is long overdue that we get to start moving those other things forward in my view.
We had planned to start moving around a pile of stuff for FIPS related items - and keeping master locked for API changes really works against that.

There are a large range of PRs which we pushed off as must-wait-for-post-1.1.1 and those are things that remain stalled as long as we keep master locked down.

The release for 1.1.1 should be pretty close to "complete" as such - looking at the plans - as with no new features going in the work remaining should be relatively staight forward.
Rich's suggestions I think tend to indicate more  work going into the release that planned - and we had said we were creating this branch - and deviating from that at the last minute isn't really how we shuold be making decisions as a project.
Some stuff that would normally be in a banch now isn't ... as Richard noted in the PR.

Tim.


On Wed, Mar 21, 2018 at 12:17 AM, Matt Caswell <matt at openssl.org<mailto:matt at openssl.org>> wrote:
The beta release is now complete.

Important:

We did *not* create the OpenSSL_1_1_1-stable branch as planned (see
https://github.com/openssl/openssl/pull/5690<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5690&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=9Agx-vYK5V64ygDZaA-VXF-_J0Toc8LHurSEHwYFftg&s=_K1qiQSxWe1g7tN6OWnwtKdRuWDwZIPWo08A7cQTlGA&e=> for the discussion that led
to that decision). For now the release was done from the master branch
in the same way as we did for the previous alpha releases. However the
feature freeze *is* in force. Therefore no features can be pushed into
the repo until such time as the branch is created. All commits to master
must be suitable for inclusion in the 1.1.1 release.

Matt
_______________________________________________
openssl-project mailing list
openssl-project at openssl.org<mailto:openssl-project at openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=9Agx-vYK5V64ygDZaA-VXF-_J0Toc8LHurSEHwYFftg&s=wYNJwU48t3cQS2G7emoGFewD3Bc_KuMuT00Q1v_lCuM&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180320/1cd937aa/attachment-0001.html>

From matt at openssl.org  Tue Mar 20 15:06:04 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 20 Mar 2018 15:06:04 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <C95A2B85-3097-4372-905D-74BB6D31E8FA@akamai.com>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <C95A2B85-3097-4372-905D-74BB6D31E8FA@akamai.com>
Message-ID: <8335300c-981a-c326-4bb9-a826b02676cc@openssl.org>

Without stating an opinion either way - some stats:

PRs with 1.1.1 milestone: 57
Issues with 1.1.1 milestone: 160
Coverity Issues: 68

All of the above need to be resolved (possibly by deferring them), plus
any new ones that get raised in the meantime, before we can release.

Matt


On 20/03/18 14:58, Salz, Rich wrote:
> 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 should be working on is the release.
> 
> ?
> 
> EVERYONE can do code reviews.?
> 
> ?
> 
> *From: *Tim Hudson <tjh at cryptsoft.com>
> *Reply-To: *"openssl-project at openssl.org" <openssl-project at openssl.org>
> *Date: *Tuesday, March 20, 2018 at 10:27 AM
> *To: *"openssl-project at openssl.org" <openssl-project at openssl.org>
> *Subject: *Re: [openssl-project] Code Repo
> 
> ?
> 
> We have been holding off on post-1.1.1 feature development for a long
> time now - on the grounds that TLSv1.3 was just around the corner etc
> and the release was close - and then we formed a release plan which we
> pushed back a week.
> 
> ?
> 
> It is long overdue that we get to start moving those other things
> forward in my view.
> 
> We had planned to start moving around a pile of stuff for FIPS related
> items - and keeping master locked for API changes really works against that.
> 
> ?
> 
> There are a large range of PRs which we pushed off as
> must-wait-for-post-1.1.1 and those are things that remain stalled as
> long as we keep master locked down.
> 
> ?
> 
> The release for 1.1.1 should be pretty close to "complete" as such -
> looking at the plans - as with no new features going in the work
> remaining should be relatively staight forward.
> 
> Rich's suggestions I think tend to indicate more? work going into the
> release that planned - and we had said we were creating this branch -
> and deviating from that at the last minute isn't really how we shuold be
> making decisions as a project.
> 
> Some stuff that would normally be in a banch now isn't ... as Richard
> noted in the PR.?
> 
> 
> Tim.
> 
> ?
> 
> ?
> 
> On Wed, Mar 21, 2018 at 12:17 AM, Matt Caswell
> <matt at openssl.org<mailto:matt at openssl.org>> wrote:
> 
>     The beta release is now complete.
> 
>     Important:
> 
>     We did *not* create the OpenSSL_1_1_1-stable branch as planned (see
>     https://github.com/openssl/openssl/pull/5690<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5690&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=9Agx-vYK5V64ygDZaA-VXF-_J0Toc8LHurSEHwYFftg&s=_K1qiQSxWe1g7tN6OWnwtKdRuWDwZIPWo08A7cQTlGA&e=>for
>     the discussion that led
>     to that decision). For now the release was done from the master branch
>     in the same way as we did for the previous alpha releases. However the
>     feature freeze *is* in force. Therefore no features can be pushed into
>     the repo until such time as the branch is created. All commits to master
>     must be suitable for inclusion in the 1.1.1 release.
> 
>     Matt
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org<mailto:openssl-project at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-project<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dproject&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=9Agx-vYK5V64ygDZaA-VXF-_J0Toc8LHurSEHwYFftg&s=wYNJwU48t3cQS2G7emoGFewD3Bc_KuMuT00Q1v_lCuM&e=>
> 
> ?
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From Matthias.St.Pierre at ncp-e.com  Tue Mar 20 15:49:18 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 20 Mar 2018 16:49:18 +0100
Subject: [openssl-project] Code Repo
In-Reply-To: <8335300c-981a-c326-4bb9-a826b02676cc@openssl.org>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <C95A2B85-3097-4372-905D-74BB6D31E8FA@akamai.com>
 <8335300c-981a-c326-4bb9-a826b02676cc@openssl.org>
Message-ID: <bcbfd75b-7ce7-4d10-1a44-4fc37ae13aa7@ncp-e.com>


Even more statistics:  the completion rate of the milestone has
_dropped_ from 30% to 26% since yesterday:
https://github.com/openssl/openssl/milestone/9

Matthias


Am 20.03.2018 um 16:06 schrieb Matt Caswell:
> Without stating an opinion either way - some stats:
>
> PRs with 1.1.1 milestone: 57
> Issues with 1.1.1 milestone: 160
> Coverity Issues: 68
>
> All of the above need to be resolved (possibly by deferring them), plus
> any new ones that get raised in the meantime, before we can release.
>
> Matt
>

From matt at openssl.org  Tue Mar 20 16:01:22 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 20 Mar 2018 16:01:22 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <bcbfd75b-7ce7-4d10-1a44-4fc37ae13aa7@ncp-e.com>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <C95A2B85-3097-4372-905D-74BB6D31E8FA@akamai.com>
 <8335300c-981a-c326-4bb9-a826b02676cc@openssl.org>
 <bcbfd75b-7ce7-4d10-1a44-4fc37ae13aa7@ncp-e.com>
Message-ID: <d081e6ee-b82d-ab5c-c19e-f68673e26ed2@openssl.org>



On 20/03/18 15:49, Dr. Matthias St. Pierre wrote:
> 
> Even more statistics:  the completion rate of the milestone has
> _dropped_ from 30% to 26% since yesterday:
> https://github.com/openssl/openssl/milestone/9

That will be because I went through all recent PRs and issues and added
them to a milestone (quite a lot hadn't been done since I last did this
exercise).

Matt


> 
> Matthias
> 
> 
> Am 20.03.2018 um 16:06 schrieb Matt Caswell:
>> Without stating an opinion either way - some stats:
>>
>> PRs with 1.1.1 milestone: 57
>> Issues with 1.1.1 milestone: 160
>> Coverity Issues: 68
>>
>> All of the above need to be resolved (possibly by deferring them), plus
>> any new ones that get raised in the meantime, before we can release.
>>
>> Matt
>>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Tue Mar 20 17:18:32 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 20 Mar 2018 17:18:32 +0000
Subject: [openssl-project] Forthcoming OpenSSL releases
Message-ID: <d3e945a1-8ac5-e640-ea17-d2343d735cd0@openssl.org>

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.0h and 1.0.2o.

These releases will be made available on 27th March 2018 between
approximately 1300-1700 UTC.

These are security-fix releases. The highest severity issue fixed in
these releases is MODERATE.

Yours

The OpenSSL Project Team

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 480 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180320/827bd6da/attachment.sig>

From kaduk at mit.edu  Tue Mar 20 17:54:21 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 20 Mar 2018 12:54:21 -0500
Subject: [openssl-project] Code Repo
In-Reply-To: <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
Message-ID: <20180320175421.GS55745@kduck.kaduk.org>

On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
> We have been holding off on post-1.1.1 feature development for a long time
> now - on the grounds that TLSv1.3 was just around the corner etc and the
> release was close - and then we formed a release plan which we pushed back
> a week.

I expect TLS 1.3 to be sent to the RFC Editor in the next day.

-Ben

From rsalz at akamai.com  Tue Mar 20 17:57:45 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 20 Mar 2018 17:57:45 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <20180320175421.GS55745@kduck.kaduk.org>
References: <295eb611-087a-8e22-ab07-20edc0eaa003@openssl.org>
 <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <20180320175421.GS55745@kduck.kaduk.org>
Message-ID: <B9DD4505-393E-4CC9-953C-30F6D4EEA019@akamai.com>

Therefore, we could have the release done a month earlier if we wanted to open master for non-release things.


?On 3/20/18, 1:54 PM, "Benjamin Kaduk" <kaduk at mit.edu> wrote:

    On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
    > We have been holding off on post-1.1.1 feature development for a long time
    > now - on the grounds that TLSv1.3 was just around the corner etc and the
    > release was close - and then we formed a release plan which we pushed back
    > a week.
    
    I expect TLS 1.3 to be sent to the RFC Editor in the next day.
    
    -Ben
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From levitte at openssl.org  Tue Mar 20 18:03:46 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 20 Mar 2018 19:03:46 +0100 (CET)
Subject: [openssl-project] Code Repo
In-Reply-To: <B9DD4505-393E-4CC9-953C-30F6D4EEA019@akamai.com>
References: <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <20180320175421.GS55745@kduck.kaduk.org>
 <B9DD4505-393E-4CC9-953C-30F6D4EEA019@akamai.com>
Message-ID: <20180320.190346.590325587093866286.levitte@openssl.org>

Why do you want to rush it?  A month earlier than what we've currently
scheduled is in 4 weeks.  I think the added stress will do nothing
good for us, or our community.

In message <B9DD4505-393E-4CC9-953C-30F6D4EEA019 at akamai.com> on Tue, 20 Mar 2018 17:57:45 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Therefore, we could have the release done a month earlier if we
rsalz> wanted to open master for non-release things.
rsalz> 
rsalz> 
rsalz> ?On 3/20/18, 1:54 PM, "Benjamin Kaduk" <kaduk at mit.edu> wrote:
rsalz> 
rsalz>     On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
rsalz>     > We have been holding off on post-1.1.1 feature development for a long time
rsalz>     > now - on the grounds that TLSv1.3 was just around the corner etc and the
rsalz>     > release was close - and then we formed a release plan which we pushed back
rsalz>     > a week.
rsalz>     
rsalz>     I expect TLS 1.3 to be sent to the RFC Editor in the next day.
rsalz>     
rsalz>     -Ben
rsalz>     _______________________________________________
rsalz>     openssl-project mailing list
rsalz>     openssl-project at openssl.org
rsalz>     https://mta.openssl.org/mailman/listinfo/openssl-project
rsalz>     
rsalz> 
rsalz> _______________________________________________
rsalz> openssl-project mailing list
rsalz> openssl-project at openssl.org
rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project

From rsalz at akamai.com  Tue Mar 20 18:07:01 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 20 Mar 2018 18:07:01 +0000
Subject: [openssl-project] Forthcoming OpenSSL releases
In-Reply-To: <d3e945a1-8ac5-e640-ea17-d2343d735cd0@openssl.org>
References: <d3e945a1-8ac5-e640-ea17-d2343d735cd0@openssl.org>
Message-ID: <6598C048-31D7-433E-ABAF-A4117C5064ED@akamai.com>

This should include the fix to the bug Guido found.

?On 3/20/18, 1:18 PM, "Matt Caswell" <matt at openssl.org> wrote:

    Forthcoming OpenSSL releases
    ============================
    
    The OpenSSL project team would like to announce the forthcoming release
    of OpenSSL versions 1.1.0h and 1.0.2o.
    
    These releases will be made available on 27th March 2018 between
    approximately 1300-1700 UTC.
    
    These are security-fix releases. The highest severity issue fixed in
    these releases is MODERATE.
    
    Yours
    
    The OpenSSL Project Team
    
    


From rsalz at akamai.com  Tue Mar 20 18:08:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 20 Mar 2018 18:08:38 +0000
Subject: [openssl-project] Code Repo
In-Reply-To: <20180320.190346.590325587093866286.levitte@openssl.org>
References: <CAHEJ-S7dY9hQDGyYmW_+yf5DrQjePpCBM3ZEMaGqb+DejDnP4w@mail.gmail.com>
 <20180320175421.GS55745@kduck.kaduk.org>
 <B9DD4505-393E-4CC9-953C-30F6D4EEA019@akamai.com>
 <20180320.190346.590325587093866286.levitte@openssl.org>
Message-ID: <7B236F8A-A687-4EE8-87C2-260695134C0B@akamai.com>

I didn't say that I wanted to do this, I just said that we could. I very strongly believe that the team should be working on nothing else until the release is out.  If some people feel they need to get post-release stuff checked into the tree, this is one way to do it.


?On 3/20/18, 2:03 PM, "Richard Levitte" <levitte at openssl.org> wrote:

    Why do you want to rush it?  A month earlier than what we've currently
    scheduled is in 4 weeks.  I think the added stress will do nothing
    good for us, or our community.
    
    In message <B9DD4505-393E-4CC9-953C-30F6D4EEA019 at akamai.com> on Tue, 20 Mar 2018 17:57:45 +0000, "Salz, Rich" <rsalz at akamai.com> said:
    
    rsalz> Therefore, we could have the release done a month earlier if we
    rsalz> wanted to open master for non-release things.
    rsalz> 
    rsalz> 
    rsalz> On 3/20/18, 1:54 PM, "Benjamin Kaduk" <kaduk at mit.edu> wrote:
    rsalz> 
    rsalz>     On Wed, Mar 21, 2018 at 12:27:13AM +1000, Tim Hudson wrote:
    rsalz>     > We have been holding off on post-1.1.1 feature development for a long time
    rsalz>     > now - on the grounds that TLSv1.3 was just around the corner etc and the
    rsalz>     > release was close - and then we formed a release plan which we pushed back
    rsalz>     > a week.
    rsalz>     
    rsalz>     I expect TLS 1.3 to be sent to the RFC Editor in the next day.
    rsalz>     
    rsalz>     -Ben
    rsalz>     _______________________________________________
    rsalz>     openssl-project mailing list
    rsalz>     openssl-project at openssl.org
    rsalz>     https://mta.openssl.org/mailman/listinfo/openssl-project
    rsalz>     
    rsalz> 
    rsalz> _______________________________________________
    rsalz> openssl-project mailing list
    rsalz> openssl-project at openssl.org
    rsalz> https://mta.openssl.org/mailman/listinfo/openssl-project
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From rsalz at akamai.com  Wed Mar 21 11:08:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 21 Mar 2018 11:08:41 +0000
Subject: [openssl-project] Coding style changes; last  call before vote
Message-ID: <7CDB1CC3-1472-4988-BD21-252AF4B36B52@akamai.com>

Please look at https://github.com/openssl/web/pull/43

I want to have vote to incorporate that text into our coding style document on Monday.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180321/94cfac13/attachment.html>

From rsalz at akamai.com  Wed Mar 21 12:54:15 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 21 Mar 2018 12:54:15 +0000
Subject: [openssl-project] Accept PR 5702 after the feature-freeze?
Message-ID: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>

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 needed
for QUIC 1-RTT decryption support in Wireshark.

I don?t think there?s much need to discuss this.  Other TLS stacks have it, the most important debugging tool really wants it, and it?s useful for debugging a very important protocol.  I will start a vote on Monday.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180321/cd771bd3/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Wed Mar 21 20:23:19 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 21 Mar 2018 21:23:19 +0100
Subject: [openssl-project] Accept PR 5702 after the feature-freeze?
In-Reply-To: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>
References: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>
Message-ID: <df784d04-725b-7365-7d1f-1d6adf87ea51@ncp-e.com>

Not that it's my business, but IMHO it might be sensible to loosen the
freeze for TLS 1.3 related changes in general,  since that hasn't been
finalized yet. So instead of starting a vote for every pull request in
question, you could also vote about an exceptional rule like the following:

A pull request that introduces a new feature can be merged regardless of
the feature freeze, if it is related to TLS 1.3, and approved by at
least 3 OMC members (without veto, of course)

Matthias

Am 21.03.2018 um 13:54 schrieb Salz, Rich:
>
> 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 needed
>
> for QUIC 1-RTT decryption support in Wireshark.
>
>  
>
> I don?t think there?s much need to discuss this.  Other TLS stacks
> have it, the most important debugging tool really wants it, and it?s
> useful for debugging a very important protocol.  I will start a vote
> on Monday.
>
>  
>



From matt at openssl.org  Wed Mar 21 20:29:25 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 21 Mar 2018 20:29:25 +0000
Subject: [openssl-project] Accept PR 5702 after the feature-freeze?
In-Reply-To: <df784d04-725b-7365-7d1f-1d6adf87ea51@ncp-e.com>
References: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>
 <df784d04-725b-7365-7d1f-1d6adf87ea51@ncp-e.com>
Message-ID: <92c77480-f97b-0874-b283-77aa6418fabd@openssl.org>



On 21/03/18 20:23, Dr. Matthias St. Pierre wrote:
> Not that it's my business, but IMHO it might be sensible to loosen the
> freeze for TLS 1.3 related changes in general,  since that hasn't been
> finalized yet. So instead of starting a vote for every pull request in
> question, you could also vote about an exceptional rule like the following:
> 
> A pull request that introduces a new feature can be merged regardless of
> 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
> 
> Am 21.03.2018 um 13:54 schrieb Salz, Rich:
>>
>> 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 needed
>>
>> for QUIC 1-RTT decryption support in Wireshark.
>>
>>  
>>
>> I don?t think there?s much need to discuss this.  Other TLS stacks
>> have it, the most important debugging tool really wants it, and it?s
>> useful for debugging a very important protocol.  I will start a vote
>> on Monday.
>>
>>  
>>
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From rsalz at akamai.com  Wed Mar 21 20:48:02 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 21 Mar 2018 20:48:02 +0000
Subject: [openssl-project] Accept PR 5702 after the feature-freeze?
In-Reply-To: <92c77480-f97b-0874-b283-77aa6418fabd@openssl.org>
References: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>
 <df784d04-725b-7365-7d1f-1d6adf87ea51@ncp-e.com>
 <92c77480-f97b-0874-b283-77aa6418fabd@openssl.org>
Message-ID: <066DD765-12B0-412D-9DF4-A365E31119F5@akamai.com>

Yes, that is a good idea!

?On 3/21/18, 4:29 PM, "Matt Caswell" <matt at openssl.org> wrote:

    
    
    On 21/03/18 20:23, Dr. Matthias St. Pierre wrote:
    > Not that it's my business, but IMHO it might be sensible to loosen the
    > freeze for TLS 1.3 related changes in general,  since that hasn't been
    > finalized yet. So instead of starting a vote for every pull request in
    > question, you could also vote about an exceptional rule like the following:
    > 
    > A pull request that introduces a new feature can be merged regardless of
    > 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
    > 
    > Am 21.03.2018 um 13:54 schrieb Salz, Rich:
    >>
    >> 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 needed
    >>
    >> for QUIC 1-RTT decryption support in Wireshark.
    >>
    >>  
    >>
    >> I don?t think there?s much need to discuss this.  Other TLS stacks
    >> have it, the most important debugging tool really wants it, and it?s
    >> useful for debugging a very important protocol.  I will start a vote
    >> on Monday.
    >>
    >>  
    >>
    > 
    > 
    > _______________________________________________
    > openssl-project mailing list
    > openssl-project at openssl.org
    > https://mta.openssl.org/mailman/listinfo/openssl-project
    > 
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From Matthias.St.Pierre at ncp-e.com  Wed Mar 21 23:20:40 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 22 Mar 2018 00:20:40 +0100
Subject: [openssl-project] Accept PR 5702 after the feature-freeze?
In-Reply-To: <066DD765-12B0-412D-9DF4-A365E31119F5@akamai.com>
References: <46B5000F-3D78-4256-BB88-80F66EF2A201@akamai.com>
 <df784d04-725b-7365-7d1f-1d6adf87ea51@ncp-e.com>
 <92c77480-f97b-0874-b283-77aa6418fabd@openssl.org>
 <066DD765-12B0-412D-9DF4-A365E31119F5@akamai.com>
Message-ID: <1d5be0b3-ec41-f6a1-1734-b2edc094e572@ncp-e.com>

To increase transparency,  you could also add a clause which ensures
that every exceptional merge needs to be announced on openssl-project:

	A pull request that introduces a new feature can be merged regardless of
	the feature freeze, if it is related to TLS 1.3 and approved by at
	least 3 OMC members without veto. The intention to merge the pull request
	has to be announced at least 24 hours in advance on openssl-project.

Just an idea.

Matthias

Am 21.03.2018 um 21:48 schrieb Salz, Rich:
> Yes, that is a good idea!
>
> ?On 3/21/18, 4:29 PM, "Matt Caswell" <matt at openssl.org> wrote:
>
>     
>     
>     On 21/03/18 20:23, Dr. Matthias St. Pierre wrote:
>     > Not that it's my business, but IMHO it might be sensible to loosen the
>     > freeze for TLS 1.3 related changes in general,  since that hasn't been
>     > finalized yet. So instead of starting a vote for every pull request in
>     > question, you could also vote about an exceptional rule like the following:
>     > 
>     > A pull request that introduces a new feature can be merged regardless of
>     > 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
>     > 
>     > Am 21.03.2018 um 13:54 schrieb Salz, Rich:
>     >>
>     >> 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 needed
>     >>
>     >> for QUIC 1-RTT decryption support in Wireshark.
>     >>
>     >>  
>     >>
>     >> I don?t think there?s much need to discuss this.  Other TLS stacks
>     >> have it, the most important debugging tool really wants it, and it?s
>     >> useful for debugging a very important protocol.  I will start a vote
>     >> on Monday.
>     >>
>     >>  
>     >>
>     > 
>     > 
>     > _______________________________________________
>     > openssl-project mailing list
>     > openssl-project at openssl.org
>     > https://mta.openssl.org/mailman/listinfo/openssl-project
>     > 
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project



From levitte at openssl.org  Sun Mar 25 11:06:31 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 25 Mar 2018 13:06:31 +0200 (CEST)
Subject: [openssl-project] cppflags, cflags and ldflags
Message-ID: <20180325.130631.1053831569206766124.levitte@openssl.org>

Note: this mail follows the discussion on github started here:
https://github.com/openssl/openssl/pull/5742#discussion_r176919954
That discussion started as a simple side note, but I should probably
have known better...  it ends up derailing a PR that shouldn't really
be affected, so I'm bringing the discussion here.

The discussion is about the division of flags for the different parts
of building programs, shared libraries and DSOs.

So we have one side that argues for putting the majority of the flags
in the cflags variable / config attribute.  To quote from the github
discussion:

> Or to put a little bit more practical spin on it. Since we *do* pass
> cflags at *all* stages, it's only appropriate to assign multi-stage
> flags [such as -pthread] to cflags. Viewing it from another angle,
> only pure single-stage flags [such as -L ,-l, -I, -D] are
> appropriate to separate as make variables. And to variables specific
> to corresponding stage, not some other grouping. Last remark is
> reference to the fact and if one follows suggested logic [that
> presented classification imposes specific separation as make
> variables], you'd have to pass -L at pre-processor stage and -I at
> linker, because they both are listed in "Directory Options".

My spin on it goes in a different direction.  It's true that we
*currently* pass cflags to all stages.  I would argue, though, that
this is mostly because we assume that the cc command is an appropriate
frontend for everything involving building the stuff.  Enters the odd
ball that needs to use the linker (som form of ld) directly [1],
because that's what makes practical sense, or simply because that's
how things work on that platform, and suddenly, it's obviously
*inappropriate* to pass cflags on that command.  In assuming that we
can always pass cflags, we're making live difficult for those who want
to make things work on platforms that don't quite meet that assumption.

So following my spin, I would rather say that any flag that affects
preprocessing should go into cppflags, any flag that affects linking
should go into ldflags (the attribute lflags), the rest can go to
cflags.  And for compartmentalization, I'd like to see that:

- for preprocessing, only cppflags are used.  (note: this is more of a
  wishlist, not really terribly important for now...)
- for compiling (i.e. source code to object code), cppflags and cflags
  are used (I cannot see how one would make that differently).
- for linking, only ldflags should be used.  (this I think is
  important!)


[1] Just in case you wonder, there is a use case for using the linker
    directly instead of using cc as a frontend:
    https://github.com/openssl/openssl/issues/5087

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From appro at openssl.org  Sun Mar 25 13:20:54 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 25 Mar 2018 15:20:54 +0200
Subject: [openssl-project] cppflags, cflags and ldflags
In-Reply-To: <20180325.130631.1053831569206766124.levitte@openssl.org>
References: <20180325.130631.1053831569206766124.levitte@openssl.org>
Message-ID: <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>

> Note: this mail follows the discussion on github started here:
> https://github.com/openssl/openssl/pull/5742#discussion_r176919954
> That discussion started as a simple side note, but I should probably
> have known better...  it ends up derailing a PR that shouldn't really
> be affected, so I'm bringing the discussion here.
> 
> The discussion is about the division of flags for the different parts
> of building programs, shared libraries and DSOs.
> 
> So we have one side that argues for putting the majority of the flags
> in the cflags variable / config attribute.  To quote from the github
> discussion:
> 
>> Or to put a little bit more practical spin on it. Since we *do* pass
>> cflags at *all* stages, it's only appropriate to assign multi-stage
>> flags [such as -pthread] to cflags. Viewing it from another angle,
>> only pure single-stage flags [such as -L ,-l, -I, -D] are
>> appropriate to separate as make variables. And to variables specific
>> to corresponding stage, not some other grouping. Last remark is
>> reference to the fact and if one follows suggested logic [that
>> presented classification imposes specific separation as make
>> variables], you'd have to pass -L at pre-processor stage and -I at
>> linker, because they both are listed in "Directory Options".
> 
> My spin on it goes in a different direction.  It's true that we
> *currently* pass cflags to all stages.  I would argue, though, that
> this is mostly because we assume that the cc command is an appropriate
> frontend for everything involving building the stuff.

There is glue that holds it together, and it's makefile template.
Besides, question also is if there is a set of flags that we *have to*
pass at *all* stages. I.e. not just "do", but "have to". Yes, there is,
one example being -m64. One can as well say that it just so happens that
it's now called cflags. Very natural and intuitive choice. *If* we
choose to change that, I'd still argue that collecting multi-stage flags
in one variable would be totally appropriate, at least for platforms
where it works. Like Linux, Solaris, AIX, HP-UX, BSD, Mac OS X,
effectively *all* the platforms we actually directly support. So that in
a sense, this question and reference to odd-ball problem are not
actually that tightly interwoven as suggested. I mean odd-ball problem
is used as an argument *for* excessive variables fragmentation on *all*
platforms, but collecting any specific flag in one variable on vast
majority of platforms doesn't actually contradict the suggestion to
introduce a variable that would be meaningful to one [and fragmenting on
that one].

> Enters the odd
> ball that needs to use the linker (som form of ld) directly [1],
> because that's what makes practical sense, or simply because that's
> how things work on that platform, and suddenly, it's obviously
> *inappropriate* to pass cflags on that command.  In assuming that we
> can always pass cflags, we're making live difficult for those who want
> to make things work on platforms that don't quite meet that assumption.

Well, it's no news that life is not fair. Two points.

We already touched this in Windows context, one option (more suitable in
my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
cube into circular hole, just make square hole on the side. For example
*if* target has ldonly attribute, just emit link rule without CFLAGS,
but with those listed in ldonly.

Another option is wrapper. Instead of struggling with ever-increasing
amount of options to accommodate one[!!!] odd-ball platform, why can't
*they* provide a wrapper script that would omit offending options prior
calling the linker? [BTW, we do have an odd-ball platform, VMS, so why
can't this odd ball handled similarly, i.e. with own template? Too
expensive you'd say. Well, why not make *them* bare the cost? But even
if not, formally speaking ever-increasing amount of
variables/options/joints and complex relationship among them all has its
cost too. And by suggesting to solve it in this specific way you kind of
imply that cost is not an issue here. How come?]

> So following my spin, I would rather say that any flag that affects
> preprocessing should go into cppflags, any flag that affects linking
> should go into ldflags (the attribute lflags), the rest can go to
> cflags.  And for compartmentalization, I'd like to see that:
> 
> - for preprocessing, only cppflags are used.  (note: this is more of a
>   wishlist, not really terribly important for now...)

It has already been established that it doesn't work. Because there are
flags that are customarily viewed as compile-time, but that affect
pre-defined macros that we relay upon. In other words pre-processing has
to be performed with cppflags *and* cflags, just like compiling.

> - for compiling (i.e. source code to object code), cppflags and cflags
>   are used (I cannot see how one would make that differently).
> - for linking, only ldflags should be used.  (this I think is
>   important!)

As implied above, there are (and always will be) flags that are required
at *all* stages on quite a number[!] of platforms. So that one can argue
in favour of adding one to capture specifically this. "target_arch"
might be appropriate if one follows the make's lead. In such case it
would be possible to arrange it as cflags+cppflags+target_arch for
pre-processing and compiling, and as ldflags+target_arch for linking. As
it can be seen cppflags can actually be merged with cflags, so that
cflags+target_arch and ldflags+target_arch would suffice(*). However,
target_arch poses a non-trivial practical problem. Namely how do we know
which of the additional flags user passes as additional arguments to
configure belong in target_arch? With this in mind, i.e. as long as we
don't want to get into business of tracking which additional flags
should be assigned to target_arch, we would be better off passing cflags
at all stages. [And handling odd-ball platform as exception, not rule.]

(*) Obviously modulo fact that we probably want to keep CPPFLAGS,
because that's what users would expect they can affect.

From levitte at openssl.org  Sun Mar 25 15:08:01 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 25 Mar 2018 17:08:01 +0200 (CEST)
Subject: [openssl-project] cppflags, cflags and ldflags
In-Reply-To: <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
References: <20180325.130631.1053831569206766124.levitte@openssl.org>
 <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
Message-ID: <20180325.170801.749126424942246188.levitte@openssl.org>

In message <7e8cc500-3739-e32a-e036-4c3eb8f28d44 at openssl.org> on Sun, 25 Mar 2018 15:20:54 +0200, Andy Polyakov <appro at openssl.org> said:

appro> > My spin on it goes in a different direction.  It's true that we
appro> > *currently* pass cflags to all stages.  I would argue, though, that
appro> > this is mostly because we assume that the cc command is an appropriate
appro> > frontend for everything involving building the stuff.
appro> 
appro> There is glue that holds it together, and it's makefile template.
appro> Besides, question also is if there is a set of flags that we *have to*
appro> pass at *all* stages. I.e. not just "do", but "have to". Yes, there is,
appro> one example being -m64. One can as well say that it just so happens that
appro> it's now called cflags. Very natural and intuitive choice. *If* we
appro> choose to change that, I'd still argue that collecting multi-stage flags
appro> in one variable would be totally appropriate, at least for platforms
appro> where it works. Like Linux, Solaris, AIX, HP-UX, BSD, Mac OS X,
appro> effectively *all* the platforms we actually directly support. So that in
appro> a sense, this question and reference to odd-ball problem are not
appro> actually that tightly interwoven as suggested. I mean odd-ball problem
appro> is used as an argument *for* excessive variables fragmentation on *all*
appro> platforms, but collecting any specific flag in one variable on vast
appro> majority of platforms doesn't actually contradict the suggestion to
appro> introduce a variable that would be meaningful to one [and fragmenting on
appro> that one].
appro> 
appro> > Enters the odd
appro> > ball that needs to use the linker (som form of ld) directly [1],
appro> > because that's what makes practical sense, or simply because that's
appro> > how things work on that platform, and suddenly, it's obviously
appro> > *inappropriate* to pass cflags on that command.  In assuming that we
appro> > can always pass cflags, we're making live difficult for those who want
appro> > to make things work on platforms that don't quite meet that assumption.
appro> 
appro> Well, it's no news that life is not fair. Two points.
appro> 
appro> We already touched this in Windows context, one option (more suitable in
appro> my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
appro> cube into circular hole, just make square hole on the side. For example
appro> *if* target has ldonly attribute, just emit link rule without CFLAGS,
appro> but with those listed in ldonly.

So you want some kind of flag attributes in the config targets?
That's what 'ldonly' sounds like.  I don't understand how that goes
together with not wanting fragmentation, it mostly seems that you're
arguing for another kind, which results in more hackery in the
Makefile template (another type of fragmentation).

appro> Another option is wrapper. Instead of struggling with ever-increasing
appro> amount of options to accommodate one[!!!] odd-ball platform, why can't
appro> *they* provide a wrapper script that would omit offending options prior
appro> calling the linker? [BTW, we do have an odd-ball platform, VMS, so why
appro> can't this odd ball handled similarly, i.e. with own template? Too
appro> expensive you'd say. Well, why not make *them* bare the cost? But even
appro> if not, formally speaking ever-increasing amount of
appro> variables/options/joints and complex relationship among them all has its
appro> cost too. And by suggesting to solve it in this specific way you kind of
appro> imply that cost is not an issue here. How come?]

Actually, I do imply that cost is an issue.  For example, I think it's
quite costly for *them*, who do have enough of a sh like environment
for unix-Makefile.tmpl to be useful with the exception of a few lines
of changes, to have to make a copy of that template and maintain it
against whatever changes we throw in for the sake of those few lines,
and for this to be repeated by everyone who has a different enough
setup, when changing those few lines wouldn't be that hard on our end.

(VMS' descrip.mms.tmpl is quite different in that way, as it's
designed for a completely different shell (DCL), quite different
commands and a different enough make implementation (mms or mmk), so
there are very practical reason why it's a separate template.  The
same goes, btw, for windows-makefile.tmpl, which is designed for yet a
different shell (cmd), yet a different set of commands and yet another
make implementation (nmake), so same practical reasons there.
I know that you're arguing that they are also designed for specific
compilers, but that was never the intention when I designed them, so
it's more of an incidental thing that really comes down to my
laziness.  And frankly, I have *zero* desire to lock them in
permanently for specific compilers and will not work for such lock
in).

And yeah, I get that the config targets need to be reshaped for this.
That's your main argument, isn't it?  Is that so actually so costly?

Another side thing that I've been thinking of for quite a while, and I
think you may have argued for even though I feel a bit unsure, and
that's to support command line attributes as an alternative to that
increasing amount of specialised attributes, so something like this:

	link => '$(CCLD) $(LDFLAGS) -o $@ ...',

Note that I haven't really thought it through, this is really a draft
of a possible idea, and it might end up having a very different form.
But still, that might be better than the proliferation of gazillions
of little flags, and would probably also help those who want or need
to do certain things slightly differently.

Also, note that I don't think this is appropriate to introduce for
1.1.1, it's waaaaay too late for that.

appro> > So following my spin, I would rather say that any flag that affects
appro> > preprocessing should go into cppflags, any flag that affects linking
appro> > should go into ldflags (the attribute lflags), the rest can go to
appro> > cflags.  And for compartmentalization, I'd like to see that:
appro> > 
appro> > - for preprocessing, only cppflags are used.  (note: this is more of a
appro> >   wishlist, not really terribly important for now...)
appro> 
appro> It has already been established that it doesn't work. Because there are
appro> flags that are customarily viewed as compile-time, but that affect
appro> pre-defined macros that we relay upon. In other words pre-processing has
appro> to be performed with cppflags *and* cflags, just like
appro> compiling.

And do note that I said "wishlist"...  I'm not sure all agree with
you, but not important enough to fight about.

appro> > - for compiling (i.e. source code to object code), cppflags and cflags
appro> >   are used (I cannot see how one would make that differently).
appro> > - for linking, only ldflags should be used.  (this I think is
appro> >   important!)
appro> 
appro> As implied above, there are (and always will be) flags that are
appro> required at *all* stages on quite a number[!] of platforms. So
appro> that one can argue in favour of adding one to capture
appro> specifically this. "target_arch" might be appropriate if one
appro> follows the make's lead. In such case it would be possible to
appro> arrange it as cflags+cppflags+target_arch for pre-processing
appro> and compiling, and as ldflags+target_arch for linking. As it
appro> can be seen cppflags can actually be merged with cflags, so
appro> that cflags+target_arch and ldflags+target_arch would suffice(*).

(I was about to argue, but noticed the '(*)' at the last moment...)

However, you're saying it yourself:

appro> However, target_arch poses a non-trivial practical problem.
appro> Namely how do we know which of the additional flags user passes
appro> as additional arguments to configure belong in target_arch?
appro> With this in mind, i.e. as long as we don't want to get into
appro> business of tracking which additional flags should be assigned
appro> to target_arch, we would be better off passing cflags at all
appro> stages. [And handling odd-ball platform as exception, not
appro> rule.]

Newsflash: it's actually possible to repeat the same flag in more than
one variable!  And this is also something I see people do a little now
and then, so I wouldn't be at all surprised to see something like
CPPFLAGS='-m64 ...' LDFLAGS='-m64 ...' (that would cover all the
bases)...

appro> (*) Obviously modulo fact that we probably want to keep CPPFLAGS,
appro> because that's what users would expect they can affect.

Yes.

You know, while bouncing ideas, whatever we end up doing will be
post-1.1.1, so we have time to argue some more and hopefully end up
with a bunch of ideas to do things better, going forward.  That is,
after all, my desire (as well as generalization as much as possible,
that should probably be clear by now)

Going back to the 'link' attribute as an alternative to a gazillion
specialise attributes, does that seem like an idea to you?  Was that
what you have been trying to argue for some time?  Either way, this
said without locking into a particular form.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From appro at openssl.org  Sun Mar 25 15:12:12 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 25 Mar 2018 17:12:12 +0200
Subject: [openssl-project] cppflags, cflags and ldflags
In-Reply-To: <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
References: <20180325.130631.1053831569206766124.levitte@openssl.org>
 <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
Message-ID: <347858f9-3bc9-51fb-e6bd-f29080ae2cb5@openssl.org>

>> Note: this mail follows the discussion on github started here:
>> https://github.com/openssl/openssl/pull/5742#discussion_r176919954

In the light of the new evidence presented in
https://github.com/openssl/openssl/pull/5745 one can argue in favour of
splitting -pthread flag to cppflags and ldflags. Yes, but I'd still be
reluctant to formulating it like that. As implied I'm kind of arguing
against too many options/variables/joints and call rather for
simplification than increased complexity. I feel that there are more
efficient ways to cover corner/odd-ball places...

From appro at openssl.org  Sun Mar 25 16:45:40 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 25 Mar 2018 18:45:40 +0200
Subject: [openssl-project] cppflags, cflags and ldflags
In-Reply-To: <20180325.170801.749126424942246188.levitte@openssl.org>
References: <20180325.130631.1053831569206766124.levitte@openssl.org>
 <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
 <20180325.170801.749126424942246188.levitte@openssl.org>
Message-ID: <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>

> appro> We already touched this in Windows context, one option (more suitable in
> appro> my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
> appro> cube into circular hole, just make square hole on the side. For example
> appro> *if* target has ldonly attribute, just emit link rule without CFLAGS,
> appro> but with those listed in ldonly.
> 
> So you want some kind of flag attributes in the config targets?
> That's what 'ldonly' sounds like.  I don't understand how that goes
> together with not wanting fragmentation, it mostly seems that you're
> arguing for another kind, which results in more hackery in the
> Makefile template (another type of fragmentation).

Well, I didn't say I liked it, but I'd say it would be more appropriate,
because we compare complex relationships between multiple variables vs.
limited amount of "override" rule. Or in other words. Complexity of
working "override" rules is "linear" in sense that it depends on limited
amount of "override" rules, each being isolated[!] so that it doesn't
affect other platforms. While complexity of working with
one-size-supposedly-fits-all thing is "superlinear" and depends on
amount variables times platforms involved.

> appro> Another option is wrapper. Instead of struggling with ever-increasing
> appro> amount of options to accommodate one[!!!] odd-ball platform, why can't
> appro> *they* provide a wrapper script that would omit offending options prior
> appro> calling the linker? [BTW, we do have an odd-ball platform, VMS, so why
> appro> can't this odd ball handled similarly, i.e. with own template? Too
> appro> expensive you'd say. Well, why not make *them* bare the cost? But even
> appro> if not, formally speaking ever-increasing amount of
> appro> variables/options/joints and complex relationship among them all has its
> appro> cost too. And by suggesting to solve it in this specific way you kind of
> appro> imply that cost is not an issue here. How come?]
> 
> Actually, I do imply that cost is an issue.  For example, I think it's
> quite costly for *them*,

But my question was about *our* costs.

> who do have enough of a sh like environment
> for unix-Makefile.tmpl to be useful with the exception of a few lines
> of changes, to have to make a copy of that template and maintain it
> against whatever changes we throw in for the sake of those few lines,
> and for this to be repeated by everyone who has a different enough
> setup, when changing those few lines wouldn't be that hard on our end.

Keyword is "would" here. Since it's obviously not possible (otherwise we
wouldn't have this discussion), then you can only say that it *would*
cost us a little. But this happens in the parallel would-universe, not
here. Of course one can argue that it's appropriate to make this
"investment", because it would solve other problems in future. But thing
is that I do feel that build system complexity is growing beyond
reasonable proportion, and it's because that there is tendency to
consider our costs as negligible to none. Well, one can also say that
letting somebody else do things never worked, as you end up fixing it
anyway. But is it because nobody else can actually solve it, or because
you're not forcing them to work harder for *their* cause. [BTW, wouldn't
the fact that nobody else can solve it be a sign of excessive complexity?]

And once again, [in this odd-ball case] why not a wrapper script that
omits offending options?

> And yeah, I get that the config targets need to be reshaped for this.
> That's your main argument, isn't it?  Is that so actually so costly?

If we have to upon every introduction of an odd-ball community platform,
then yes.

> Another side thing that I've been thinking of for quite a while, and I
> think you may have argued for even though I feel a bit unsure, and
> that's to support command line attributes as an alternative to that
> increasing amount of specialised attributes, so something like this:
> 
> 	link => '$(CCLD) $(LDFLAGS) -o $@ ...',

You've mentioned once that it would take a special language to do that
something, and I recall myself thinking "why not just use make syntax".
I'm unsure if I actually said this, but I did think the thought. So that
I for one wouldn't actually be opposed to something like this. It's just
a way to specify "override" rule (and on per-toolchain basis:-).
However! It all depends on whether or not straight make syntax would
actually be expressive enough in the context. If it is, then it would be
totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
if-else in makefile template could turn out to be more appropriate.
(Once again, each clause in if-else is isolated and complexity is
linearly proportional to number of clauses in if-else, which is viewed
as advantage.)

> Note that I haven't really thought it through, this is really a draft
> of a possible idea, and it might end up having a very different form.
> But still, that might be better than the proliferation of gazillions
> of little flags, and would probably also help those who want or need
> to do certain things slightly differently.

You say it yourself, gazillions of little options :-) That's my whole
point :-)

> appro> As implied above, there are (and always will be) flags that are
> appro> required at *all* stages on quite a number[!] of platforms. So
> appro> that one can argue in favour of adding one to capture
> appro> specifically this. "target_arch" might be appropriate if one
> appro> follows the make's lead. In such case it would be possible to
> appro> arrange it as cflags+cppflags+target_arch for pre-processing
> appro> and compiling, and as ldflags+target_arch for linking. As it
> appro> can be seen cppflags can actually be merged with cflags, so
> appro> that cflags+target_arch and ldflags+target_arch would suffice(*).
> 
> (I was about to argue, but noticed the '(*)' at the last moment...)

Right, I was talking exclusively about non-overridables that *we* rely
upon, those we do not let user override.

> However, you're saying it yourself:
> 
> appro> However, target_arch poses a non-trivial practical problem.
> appro> Namely how do we know which of the additional flags user passes
> appro> as additional arguments to configure belong in target_arch?
> appro> With this in mind, i.e. as long as we don't want to get into
> appro> business of tracking which additional flags should be assigned
> appro> to target_arch, we would be better off passing cflags at all
> appro> stages. [And handling odd-ball platform as exception, not
> appro> rule.]

Right, it's argument for *not* doing it. Note that I opened with "*one*
can argue argue in favour of adding one to capture specifically this."
This is because *I* am *not* doing that, i.e. *not* arguing in favour.
In the essence what I'm saying is that *if* we are to introduce another
variable, then it should rather be something else.

> Newsflash: it's actually possible to repeat the same flag in more than
> one variable!  And this is also something I see people do a little now
> and then, so I wouldn't be at all surprised to see something like
> CPPFLAGS='-m64 ...' LDFLAGS='-m64 ...' (that would cover all the
> bases)...

I wouldn't be surprised if people end up doing this because there was no
*better* or more adequate solution at some point. I mean humans are
creatures of habit, so it's easy to imagine that somebody had to do
something like this at some occasion and now just keep doing everywhere.
And it can be "multiplied" thanks to Internet. Either way it shouldn't
be something we encourage, because in general case it's error-prone
practice. Just imagine cross-compiling situation...

> appro> (*) Obviously modulo fact that we probably want to keep CPPFLAGS,
> appro> because that's what users would expect they can affect.
> 
> Yes.

To recap. I'm not suggesting to remove controls that users expect to
find, but at each point consider reducing amount of variables and
dependencies that we use. [And also to not introduce controls that users
don't customarily expect to find, such as CPPDEFINES.]

> Going back to the 'link' attribute as an alternative to a gazillion
> specialise attributes, does that seem like an idea to you?  Was that
> what you have been trying to argue for some time?  Either way, this
> said without locking into a particular form.

See above.

From levitte at openssl.org  Sun Mar 25 17:21:27 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 25 Mar 2018 19:21:27 +0200 (CEST)
Subject: [openssl-project] rule-based building attributes (Re:  cppflags,
 cflags and ldflags)
In-Reply-To: <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>
References: <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
 <20180325.170801.749126424942246188.levitte@openssl.org>
 <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>
Message-ID: <20180325.192127.2148750993574074292.levitte@openssl.org>

Branching a specific thread around these ideas.

In message <f46f0fd9-3d08-ae09-42b2-308dedfa3287 at openssl.org> on Sun, 25 Mar 2018 18:45:40 +0200, Andy Polyakov <appro at openssl.org> said:

appro> > Another side thing that I've been thinking of for quite a while, and I
appro> > think you may have argued for even though I feel a bit unsure, and
appro> > that's to support command line attributes as an alternative to that
appro> > increasing amount of specialised attributes, so something like this:
appro> > 
appro> > 	link => '$(CCLD) $(LDFLAGS) -o $@ ...',
appro> 
appro> You've mentioned once that it would take a special language to do that
appro> something, and I recall myself thinking "why not just use make syntax".
appro> I'm unsure if I actually said this, but I did think the thought. So that
appro> I for one wouldn't actually be opposed to something like this. It's just
appro> a way to specify "override" rule (and on per-toolchain basis:-).
appro> However! It all depends on whether or not straight make syntax would
appro> actually be expressive enough in the context. If it is, then it would be
appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
appro> if-else in makefile template could turn out to be more appropriate.
appro> (Once again, each clause in if-else is isolated and complexity is
appro> linearly proportional to number of clauses in if-else, which is viewed
appro> as advantage.)

Straight make syntax will probably not cut it.  How would you pass a
list of object file names to something that might have a limited
command line length, for example?  With nmake, we do have a feature we
can use, the inline file text thing, but others may not be so lucky
(the nonstop case I mentioned is such a case), and one might need to
do a bit of pre-processing with perl-level variables (an idea could be
to have some well defined hooks that users can define values for, such
as function names...  again, this is a draft of an idea).  For
example, imagine that we have something that dumps object file names
into a text file and then expects that file name to appear in the
linking command line (for example, and typically in our case), how do
we pass the text file name to the command line, and where in the
command line?

So no, a straight makefile rule for a config attribute value isn't
going to be good enough.


Coming back to costs, I would think that this direction might actually
reduce it for us as it avoids all those gazillion specialized
attributes (I've grown to dislike them too, FYI), and at the same time
become general enough to help users who want to use our stuff for
their own oddball platform to do so, with our blessing...  and I hope
that it helps us as well.

But, this line of ideas is a major change in the how the config
targets work (although I can see a smooth transition from one to the
other, so it's not like we *have* to wait until OpenSSL 1.2 to
implement it), and it is some work to get through with it.  I see
enough benefits to want to, though, and am currently in the mood of
bouncing ideas as time permits (*).

Cheers,
Richard

(*) no, I haven't forgotten that we have a primary focus in fixing
    stuff that needs fixing before the final 1.1.1 release.  But it's
    Sunday right now, tomorrow will be more focused.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From tjh at cryptsoft.com  Sun Mar 25 22:36:17 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Mon, 26 Mar 2018 08:36:17 +1000
Subject: [openssl-project] constification on already released branches
Message-ID: <CAHEJ-S5q+2ccG7EGFrVVh2gw4-Ri4t5fVosXqnJbBj2jRaotww@mail.gmail.com>

https://github.com/openssl/openssl/pull/2181
and
https://github.com/openssl/openssl/pull/1603#issuecomment-248649700

One thing that should be noted is that if you are building with -Wall
-Werror (which many projects do) and you are using OpenSSL and things
change from a const perspective builds break - and that then ends up people
having to change code on released versions.

Adding or removing const changes the API. It doesn't technically change the
ABI - although it can impact things as compilers can and do warn for simple
const violations in some circumstances. The straight forward "fix" of a
cast on call actually doesn't achieve anything useful - in that it simply
masks the underlying issue where const was added for a reason.

We should have a clear policy on doing this sort of thing in released code
- either it is okay to do and we should accept patches - or it should never
actually be done. I don't see this as a case-by-case basis for
determination at all - basically it is a single type of API change we
either should be allowing or disallowing.

There is a similar type of API change which is adding typedefs in for
callbacks - which technically also don't change the ABI - and if we allow
any form of API change that also could be considered.

We should discuss this separate from any specific PR and vote to set a
policy one way or the other in my view.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180326/da9c5d1b/attachment.html>

From levitte at openssl.org  Mon Mar 26 03:27:19 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 26 Mar 2018 05:27:19 +0200 (CEST)
Subject: [openssl-project] constification on already released branches
In-Reply-To: <CAHEJ-S5q+2ccG7EGFrVVh2gw4-Ri4t5fVosXqnJbBj2jRaotww@mail.gmail.com>
References: <CAHEJ-S5q+2ccG7EGFrVVh2gw4-Ri4t5fVosXqnJbBj2jRaotww@mail.gmail.com>
Message-ID: <20180326.052719.901985958226524603.levitte@openssl.org>

In message <CAHEJ-S5q+2ccG7EGFrVVh2gw4-Ri4t5fVosXqnJbBj2jRaotww at mail.gmail.com> on Mon, 26 Mar 2018 08:36:17 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> https://github.com/openssl/openssl/pull/2181
tjh> and
tjh> https://github.com/openssl/openssl/pull/1603#issuecomment-248649700
tjh> 
tjh> One thing that should be noted is that if you are building with
tjh> -Wall -Werror (which many projects do) and you are using OpenSSL
tjh> and things change from a const perspective builds break - and
tjh> that then ends up people having to change code on released
tjh> versions.
tjh> 
tjh> Adding or removing const changes the API.

I would like to point out that we're looking at two different const
changes, and the distinction *is* important.

One constification is changing the constness of a function's input
parameter.
Another constification is changing a function's return type.

The impact of these two types of constification is very different (I
would say "obviously", but I might be wrong, it might not be obvious
to everyone), and they should be regarded different, not piled
together in one "we do / do not allow constification in released
branches".  I'm going to argue that even though there are cases where
one type of constification affects the other (such as constifying an
input parameter might force a constification of the return type), they
can still be looked at individually, and policy can be made on them
individually.

tjh> We should have a clear policy on doing this sort of thing in
tjh> released code - either it is okay to do and we should accept
tjh> patches - or it should never actually be done. I don't see this
tjh> as a case-by-case basis for determination at all - basically it
tjh> is a single type of API change we either should be allowing or
tjh> disallowing.

(a reminder: we're talking about *two* types of API changes that both
involve 'const', not a single API change).

I agree.  We currently have a kinda sorta policy that's quite vaguely
formulated in the FAQ (https://www.openssl.org/docs/faq.html#MISC7),
and we do have something formulated in the release strategy
(https://www.openssl.org/policies/releasestrat.html) as well.  I'll
note that none of them says "the API must not change".  As a matter of
fact, the release strategy only mentions binary compatibility (i.e.
talks exclusively about ABI compatibility).  The FAQ does mention
source (i.e. API) compatibility, formulated as an implication:

   Changes to the middle number are considered major releases and
   neither source nor binary compatibility is guaranteed.

This implies that we do guarantee source and binary compatibility.
What that means exactly is left for us to discuss and decide upon.
I would like to suggest that there should be a document where we
collect what we think "compatibility" means, i.e. what we allow and
disallow ourselves to do.  Kind of a declaration of intention, if you
will.  This should be a document that can be edited over time (but
with great care), and such changes should be voted on, of course.

tjh> There is a similar type of API change which is adding typedefs in
tjh> for callbacks - which technically also don't change the ABI - and
tjh> if we allow any form of API change that also could be
tjh> considered.
tjh> 
tjh> We should discuss this separate from any specific PR and vote to
tjh> set a policy one way or the other in my view.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Mar 26 12:14:40 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 26 Mar 2018 13:14:40 +0100
Subject: [openssl-project] Repo freeze later today
Message-ID: <4450f12f-f34e-55a6-c8ac-910610bdc1ef@openssl.org>

Just a reminder that I will be freezing the repo later today in advance
of the 1.1.0/1.0.2 releases tomorrow.

Matt

From appro at openssl.org  Mon Mar 26 12:15:24 2018
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 26 Mar 2018 14:15:24 +0200
Subject: [openssl-project] rule-based building attributes (Re: cppflags,
 cflags and ldflags)
In-Reply-To: <20180325.192127.2148750993574074292.levitte@openssl.org>
References: <7e8cc500-3739-e32a-e036-4c3eb8f28d44@openssl.org>
 <20180325.170801.749126424942246188.levitte@openssl.org>
 <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>
 <20180325.192127.2148750993574074292.levitte@openssl.org>
Message-ID: <072aaeb6-59b9-0e8a-f33e-35572350c8e0@openssl.org>

> appro> > Another side thing that I've been thinking of for quite a while, and I
> appro> > think you may have argued for even though I feel a bit unsure, and
> appro> > that's to support command line attributes as an alternative to that
> appro> > increasing amount of specialised attributes, so something like this:
> appro> > 
> appro> > 	link => '$(CCLD) $(LDFLAGS) -o $@ ...',
> appro> 
> appro> You've mentioned once that it would take a special language to do that
> appro> something, and I recall myself thinking "why not just use make syntax".
> appro> I'm unsure if I actually said this, but I did think the thought. So that
> appro> I for one wouldn't actually be opposed to something like this. It's just
> appro> a way to specify "override" rule (and on per-toolchain basis:-).
> appro> However! It all depends on whether or not straight make syntax would
> appro> actually be expressive enough in the context. If it is, then it would be
> appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
> appro> if-else in makefile template could turn out to be more appropriate.
> appro> (Once again, each clause in if-else is isolated and complexity is
> appro> linearly proportional to number of clauses in if-else, which is viewed
> appro> as advantage.)
> 
> Straight make syntax will probably not cut it.  How would you pass a
> list of object file names to something that might have a limited
> command line length, for example?

These are actually two different problems, aren't they? I mean a) how do
you pass, and b) what if there is some limitation. As for former. Even
though it spells "use make syntax", it would still be rather
"make-*like* syntax". In other words it doesn't mean that you will be
able to just copy referred line into makefile, it would still have to be
processed somehow first. Well, in case at hand it might be possible to
drop a rule with $+ if you know you'll use GNU make, but others don't
understand it, so $+ would have to be processed. (And even in GNU make
case to keep things unified.) So you end up using mostly-make-like
syntax to formulate an override rule, but you do some replacements
before emitting actual rule into makefile. Naturally one might have to
make up more internally recognized make-looking idioms, in addition to
$+ that is...

> With nmake, we do have a feature we
> can use, the inline file text thing, but others may not be so lucky
> (the nonstop case I mentioned is such a case), and one might need to
> do a bit of pre-processing with perl-level variables (an idea could be
> to have some well defined hooks that users can define values for, such
> as function names...  again, this is a draft of an idea).  For
> example, imagine that we have something that dumps object file names
> into a text file and then expects that file name to appear in the
> linking command line (for example, and typically in our case), how do
> we pass the text file name to the command line, and where in the
> command line?

Do you mean that you have like 'libcrypto.so: all-the-object-files' and
want a rule that would put all-the-object-files into text file and
invoke linker with that file name as argument? And putting them into
text file may not exceed a length limit either, so that you can't say
for example 'echo $+ > o-files.$$.' either...

> So no, a straight makefile rule for a config attribute value isn't
> going to be good enough.

How about this. We have touched this when discussing windows-makefile. I
mean when I called it VC-specific, you disagreed, and I said that
embedding manifest effectively makes it VC-specific. In the context I
also suggested post-link stage, a command one could *add* to rule. Or
let's rephrase this and say that you can simply specify multiple
commands in an override rule. So with this in mind.

link => [ 'script-that-composes-list-of-objects $@.$$',
          'link -o $@ -list $@.$$' ]

Well, in this particular case you'd probably be more interested to
specify multi-line command instead of multiple commands. As '(trap "rm
-f $@.* INT 0; script ... && link ...)', because you might want to clean
up temporary file even if make is interrupted. But multi-line can be
useful if different lines reside in different templates. I mean base
template can say "link" and target can add a post-link command.

Of course I'm not suggesting to take this for immediate implementation,
these are just ideas to ponder about. They might turn unusable (or give
a spark for some other idea :-)

From levitte at openssl.org  Mon Mar 26 14:37:19 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 26 Mar 2018 16:37:19 +0200 (CEST)
Subject: [openssl-project] rule-based building attributes
In-Reply-To: <072aaeb6-59b9-0e8a-f33e-35572350c8e0@openssl.org>
References: <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>
 <20180325.192127.2148750993574074292.levitte@openssl.org>
 <072aaeb6-59b9-0e8a-f33e-35572350c8e0@openssl.org>
Message-ID: <20180326.163719.50335231160279597.levitte@openssl.org>

In message <072aaeb6-59b9-0e8a-f33e-35572350c8e0 at openssl.org> on Mon, 26 Mar 2018 14:15:24 +0200, Andy Polyakov <appro at openssl.org> said:

appro> > So no, a straight makefile rule for a config attribute value isn't
appro> > going to be good enough.
appro> 
appro> How about this. We have touched this when discussing windows-makefile. I
appro> mean when I called it VC-specific, you disagreed, and I said that
appro> embedding manifest effectively makes it VC-specific. In the context I
appro> also suggested post-link stage, a command one could *add* to rule. Or
appro> let's rephrase this and say that you can simply specify multiple
appro> commands in an override rule. So with this in mind.
appro> 
appro> link => [ 'script-that-composes-list-of-objects $@.$$',
appro>           'link -o $@ -list $@.$$' ]

So zooming in on this particular idea, I was concerned about how those
object file names would be passed to the script...  but then you
mention manifests, and it dawns on me that there's *nothing* stopping
us from generating a file with the list of object files when building
the Makefile.  That does make some kind of sense to me.

Or were you thinking something different?  It would of course be
possible to have the script you suggest pull data from configdata.pm,
right?  But considering we're talking about third parties building
their own, that raises another concern, that we suddenly give the
whole %unified_info structure public exposure that I'm not entirely
sure were ready for.  Most of it is pretty straight forward (at least
to me, but that's no big surprise), but I have the nagging suspition
that there may be details that will get people stumped, and that will
hit us back.  It's possible, though, that I'm more concerned than
necessary...

(quite frankly, I was hoping we could avoid the proliferation of a
gazillion little scripts, but perhaps that's too much to hope for.
C'est la vie)

appro> Of course I'm not suggesting to take this for immediate
appro> implementation, these are just ideas to ponder about. They
appro> might turn unusable (or give a spark for some other idea :-)

Agreed, and I have the same intention.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From yang.yang at baishancloud.com  Thu Mar 22 06:48:07 2018
From: yang.yang at baishancloud.com (Paul Yang)
Date: Thu, 22 Mar 2018 14:48:07 +0800
Subject: [openssl-project] Presentation of OpenSSL in China
Message-ID: <09FC4F53-F132-448D-AE56-1C2588F6490F@baishancloud.com>

Hi OpenSSL,

I would like to drop this email as a note for you guys (and other people who cares about this project) to know:

Yesterday I was invited to an ?open source and cloud computing? conference in Beijing to give a speech on OpenSSL. The topic of the presentation was ?Post-Heartbleed Era of OpenSSL?, which focused on important events happened in the project from 2014 to 2018. I started the speech with a very quick look-back on Heartbleed and then moved to talk about what happened in the project chronologically, including important release (1.0.2, 1.1.0, 1.1.1), important improvements in those releases (code reformat, old code delete, removal of weak ciphers and protocols...), important features (TLSv1.3, new DRBG, SHA-3, ASYNC, STORE?), important policies and community development (license changing, moving to utilize Github, attitudes to crypto algos, last China tour?), and at last I introduced the openssl-book project.

The result was great.

Tech guys in the audience were excited about the nowadays OpenSSL and they believed the project is becoming better. And even a Chinese local book publisher asked me if it?s possible to publish the Chinese edition of the openssl-book as paper copy in China, and after discussing with some OMC members, we found it?s possible to do so. Of course, that would happen after the book is really finished someday in the future. And I hope some amount of the profit made by selling the book could be returned back to OpenSSL foundation, as a way of helping the project.

As far as I know this was the first time that the big picture of OpenSSL was reviewed and discussed in a major, high level China tech conference, in Chinese language.

I think there will be videos available online and also articles reporting this presentation in a few days, but since they are all in Chinese, I don?t know if it?s helpful to share them to this list when they are ready.

Regards,

Paul Yang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180322/ced9a7ee/attachment.sig>

From tjh at cryptsoft.com  Mon Mar 26 23:01:09 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Tue, 27 Mar 2018 09:01:09 +1000
Subject: [openssl-project] wiki info for pre-1.0.2
Message-ID: <CAHEJ-S6uJbw2rS9QxWBJELHvOwXT=piGu7dp6QjJAeW6ytWCeg@mail.gmail.com>

Seeing "This was the original information, might still be valid for < 1.0.2
openssl versions :" at
https://wiki.openssl.org/index.php/Hostname_validation raises the question
as to whether or not the wiki should contain information for versions of
OpenSSL that are no longer supported.

Thoughts?

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180327/3f43428a/attachment.html>

From paul.dale at oracle.com  Mon Mar 26 23:34:33 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 26 Mar 2018 16:34:33 -0700 (PDT)
Subject: [openssl-project] wiki info for pre-1.0.2
In-Reply-To: <CAHEJ-S6uJbw2rS9QxWBJELHvOwXT=piGu7dp6QjJAeW6ytWCeg@mail.gmail.com>
References: <CAHEJ-S6uJbw2rS9QxWBJELHvOwXT=piGu7dp6QjJAeW6ytWCeg@mail.gmail.com>
Message-ID: <060fc0f2-8005-45b6-a38c-2f4216bebacc@default>

My view is to keep a note at the top saying versions prior to 1.0.2 didn?t check but remove the long bottom section about doing it.

It will be in the page history forever and people using unsupported versions could reasonably be expected to check there.

?

?

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

?

From: Tim Hudson [mailto:tjh at cryptsoft.com] 
Sent: Tuesday, 27 March 2018 9:01 AM
To: openssl-project at openssl.org
Subject: [openssl-project] wiki info for pre-1.0.2

?

Seeing "This was the original information, might still be valid for < 1.0.2 openssl versions?:" at?https://wiki.openssl.org/index.php/Hostname_validation raises the question as to whether or not the wiki should contain information for versions of OpenSSL that are no longer supported.

?

Thoughts?

?

Tim.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180326/f1d7e042/attachment-0001.html>

From matt at openssl.org  Tue Mar 27 09:08:51 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 27 Mar 2018 10:08:51 +0100
Subject: [openssl-project] Repo frozen
Message-ID: <f3796d70-5b02-786e-c774-e7a416863ea9@openssl.org>

In case anyone was wondering the repo is currently frozen.

Matt

From rsalz at akamai.com  Tue Mar 27 13:00:56 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 27 Mar 2018 13:00:56 +0000
Subject: [openssl-project] About PR 5702, etc.
Message-ID: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>

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 up and drive toward a vote?  If not, in early April I will start discussion and vote to approve 5702 for the release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180327/a9d9a896/attachment.html>

From openssl at openssl.org  Tue Mar 27 14:10:40 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 27 Mar 2018 14:10:40 +0000
Subject: [openssl-project] OpenSSL version 1.0.2o published
Message-ID: <20180327141040.GA30651@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2o released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2o of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2o is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2o.tar.gz
      Size: 5329472
      SHA1 checksum: a47faaca57b47a0d9d5fb085545857cc92062691
      SHA256 checksum: ec3f5c9714ba0fd45cb4e087301eb1336c317e0d20b575a125050470e8089e4d

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2o.tar.gz
    openssl sha256 openssl-1.0.2o.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJauk1PAAoJENnE0m0OYESR3XoH/jgf9DJxh7Ig/hMSEYKsPAns
yA2gh5tLf20qhaDMDK82iOdJejz0E3MhffFh+5FbnSnHcz2RD2Yk/PQ/9wZQka2+
nRsa1sLJ8jHfByPuIBsoUlYFkB0sjOzjNM/cUtZyJi5oLexv6VmFNGFIfWZAxdJZ
zuiGNwf6k6ll3YP8WW1WzKcSWSQkaYVzgUHGylh0KJwJOMnGpDedEqdmvl6qn0Zz
XOYQJ7+zadNw9bRTER/pl/zF1nI8dHi9G0bZWZeBRC5ObAQkE4vQ+e1qClydyFii
7B8IdlOB8aLxmWoip160q0wY0XjFjymbQ87EEUMqCIgxLihuXGU0FLWwYOqZIcc=
=wl+z
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue Mar 27 14:11:00 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 27 Mar 2018 14:11:00 +0000
Subject: [openssl-project] OpenSSL version 1.1.0h published
Message-ID: <20180327141100.GA30676@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.0h released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0h of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0h is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0h.tar.gz
      Size: 5422717
      SHA1 checksum: 0fc39f6aa91b6e7f4d05018f7c5e991e1d2491fd
      SHA256 checksum: 5835626cde9e99656585fc7aaa2302a73a7e1340bf8c14fd635a62c66802a517

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0h.tar.gz
    openssl sha256 openssl-1.1.0h.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaukw0AAoJENnE0m0OYESRqTEH+wYF71XM5PtoMUlSPksCg7uW
HZK83MrdKZTbZpvB9Sh/5MuW+Qet9rAL8u4tJ4jhwrs/bGtoHXWXgvq1inHgPXUM
mf7hPUbLqf6wf39EmsIshbXK4xGD8amUL7lwzKL5go8hc1kS+dhD8lrVEWdwD869
32BZ9ODqCrC+/Jevrr1WSIc3NBGzQksI9dwGKM+In1QDpGwARlDz/Hq0NlLLxerf
Y6cILXvmPigJLpevH8fBRXiM7SJziFCtsTzCrlXHtUIWFzthmGtaTcoUwU2BHGxP
zLPr8DoB5TqFo50uG5frOWVNgK7RFDkx/coco3Xs6OOdh+VTk7RG20E9z+Tkrhk=
=LIxK
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue Mar 27 14:14:38 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 27 Mar 2018 14:14:38 +0000
Subject: [openssl-project] OpenSSL Security Advisory
Message-ID: <20180327141438.GA31106@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [27 Mar 2018]
========================================

Constructed ASN.1 types with a recursive definition could exceed the stack (CVE-2018-0739)
==========================================================================================

Severity: Moderate

Constructed ASN.1 types with a recursive definition (such as can be found in
PKCS7) could eventually exceed the stack given malicious input with
excessive recursion. This could result in a Denial Of Service attack. There are
no such structures used within SSL/TLS that come from untrusted sources so this
is considered safe.

OpenSSL 1.1.0 users should upgrade to 1.1.0h
OpenSSL 1.0.2 users should upgrade to 1.0.2o

This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz project.
The fix was developed by Matt Caswell of the OpenSSL development team.

Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733)
========================================================

Severity: Moderate

Because of an implementation bug the PA-RISC CRYPTO_memcmp function is
effectively reduced to only comparing the least significant bit of each byte.
This allows an attacker to forge messages that would be considered as
authenticated in an amount of tries lower than that guaranteed by the security
claims of the scheme. The module can only be compiled by the HP-UX assembler, so
that only HP-UX PA-RISC targets are affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0h

This issue was reported to OpenSSL on 2nd March 2018 by Peter Waltenberg (IBM).
The fix was developed by Andy Polyakov of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================

Severity: Low

This issue has been reported in a previous OpenSSL security advisory and a fix
was provided for OpenSSL 1.0.2. Due to the low severity no fix was released at
that time for OpenSSL 1.1.0. The fix is now available in OpenSSL 1.1.0h.

There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect
would be very difficult to perform and are not believed likely. Attacks
against DH1024 are considered just feasible, because most of the work
necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share
the DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.

This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).

Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.

OpenSSL 1.1.0 users should upgrade to 1.1.0h
OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180327.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaulEjAAoJENnE0m0OYESRc2oH/2E5ya4GF745SK7VB7ZjCWu6
tN5q3CNr1gUiZKcsvK4nl/OdP5h+KToHYQR1RBy0tusk1cFHYRuztsZhtb/mm0DD
Z3adXvnz8VFeCyNC/aptwOO0OoPbUHgqhf1L5deNaXMZJDqEjz/6WlVfFQezSeVf
h0Sy72SmX2h+Jt1Zh+VYjfX/xMTnX6CWrbyC78KKZ88s4dSYbMsYdJuJSqpar/C1
zQpgCD6Stk0L9J4DB4DYr3MAInMJXRIMyFOZlrOm4oTbZqSdcFxIglCMVPlXpES2
Ke1Gse5bab+O0sr+Ue4Vk0zsi3wv7zaUk8d7YchMpUlqJWKeY3N3i40jnacx1fU=
=ATWc
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Mar 27 14:22:40 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 27 Mar 2018 15:22:40 +0100
Subject: [openssl-project] Repo frozen
In-Reply-To: <f3796d70-5b02-786e-c774-e7a416863ea9@openssl.org>
References: <f3796d70-5b02-786e-c774-e7a416863ea9@openssl.org>
Message-ID: <c39490e6-2a06-b78d-e4f2-275c4ca68e73@openssl.org>

The release is complete and the repo is unfrozen.

Thanks to Richard yet again for all your help.

Matt


On 27/03/18 10:08, Matt Caswell wrote:
> In case anyone was wondering the repo is currently frozen.
> 
> Matt
> 

From matt at openssl.org  Tue Mar 27 16:07:13 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 27 Mar 2018 17:07:13 +0100
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
Message-ID: <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>



On 27/03/18 14:00, Salz, Rich wrote:
> 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 think that is ok and doesn't stray too far from what we said in the
release strategy:

    A beta release means:

    Feature complete/Feature freeze (but may include a non-final
    implementation of the TLSv1.3 specification)
    Bug fixes only

We are all still learning about what it will take to have a good TLSv1.3
implementation so it is not surprising that there are still some things
we want to do.

That said, I don't think we should open the flood gates and let large
amounts of changes through so I think an increased review requirement
for these types of changes sounds like a good idea. There was a
suggestion that 3 OMC members would be required to get such a change
through - and I think that sounds like a good idea.


> 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 up and drive toward a vote?

That depends on how controversial the OMC think this is. If it's
controversial then we can just vote on an case-by-case basis. If there
are no real objections then I don't mind raising a vote on this.

Matt



>? If not, in
> early April I will start discussion and vote to approve 5702 for the
> release.
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Tue Mar 27 19:28:45 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 27 Mar 2018 21:28:45 +0200 (CEST)
Subject: [openssl-project] Speeding up the fuzz test...
Message-ID: <20180327.212845.1110342329063563290.levitte@openssl.org>

Hey,

Matt and I talked a bit about the fuzz test recipe and how
*incredibly* slow it is, especially on all things Windows.  We
realised fairly quickly that this is caused by a gazillion program
invokations (once for every corpora file, that's more than 15000 of
them), and then we started thinking about archiving the corpora
somehow.

After having a look through diverse format, I kinda fell for the cpio
formats.  They're very simple, putting together a reader was fairly
easy, and well, the result of running a modified test_fuzz.t that uses
the cpio files instead of the corpora files directly was quite a
dramatic change!

Running with the raw corpora files:

    : ; make test TESTS=test_fuzz
    ...
    All tests successful.
    Files=1, Tests=11, 457 wallclock secs ( 3.54 usr  0.28 sys + 330.48 cusr 189.06 csys = 523.36 CPU)
    Result: PASS

And the cpio variant:

    : ; make test TESTS=test_fuzz_new
    ...
    All tests successful.
    Files=1, Tests=11, 35 wallclock secs ( 0.01 usr  0.00 sys + 35.17 cusr  0.11 csys = 35.29 CPU)
    Result: PASS

And this was a Linux, which is substantially faster than my Windows 10
box, where I can wait for quite a while (we're talking half an hour,
maybe more).  I just wonder what kind of results I'll see there.

Now, I wonder how that will impact on Kurt, who sometimes produce
these files, and on Google's oss-fuzz project, who do use this.
My desire is to replace the current corpora with the corresponding
cpio files, one for each test program (i.e. fuzz/corpora/asn1/* gets
archived into fuzz/corpora/asn1.cpio, and so on and so forth).

I've changed fuzz/test-corpus.c so it can take a flag '-cpio' to tell
it to read the files as cpio archives, otherwise it read the file raw,
as before.

Thoughts?  Comments?  (Kurt?)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Tue Mar 27 19:31:36 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 27 Mar 2018 19:31:36 +0000
Subject: [openssl-project] Speeding up the fuzz test...
In-Reply-To: <20180327.212845.1110342329063563290.levitte@openssl.org>
References: <20180327.212845.1110342329063563290.levitte@openssl.org>
Message-ID: <A55AA493-CCA1-464A-9A6B-97D5F3D539C1@akamai.com>

Neat.

What does CPIO have over TAR?  Is it better enough that it is a compelling reason to introduce yet another file format?



From openssl-users at dukhovni.org  Tue Mar 27 19:32:41 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 27 Mar 2018 15:32:41 -0400
Subject: [openssl-project] Speeding up the fuzz test...
In-Reply-To: <20180327.212845.1110342329063563290.levitte@openssl.org>
References: <20180327.212845.1110342329063563290.levitte@openssl.org>
Message-ID: <030AEC46-83A2-4235-8449-D8B5FD3DE590@dukhovni.org>



> On Mar 27, 2018, at 3:28 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> Now, I wonder how that will impact on Kurt, who sometimes produce
> these files, and on Google's oss-fuzz project, who do use this.
> My desire is to replace the current corpora with the corresponding
> cpio files, one for each test program (i.e. fuzz/corpora/asn1/* gets
> archived into fuzz/corpora/asn1.cpio, and so on and so forth).
> 
> I've changed fuzz/test-corpus.c so it can take a flag '-cpio' to tell
> it to read the files as cpio archives, otherwise it read the file raw,
> as before.
> 
> Thoughts?  Comments?  (Kurt?)

Na?ve question:

Why a cpio (or any kind of) archive, and not a directory full of files?
Surely a program that reads a cpio archive can also traverse the files
in a directory?

-- 
	Viktor.


From rsalz at akamai.com  Tue Mar 27 20:24:33 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 27 Mar 2018 20:24:33 +0000
Subject: [openssl-project] FW: [openssl/openssl] Free allow null (#5761)
In-Reply-To: <openssl/openssl/pull/5761/c376657320@github.com>
References: <openssl/openssl/pull/5761@github.com>
 <openssl/openssl/pull/5761/c376657320@github.com>
Message-ID: <86E62B7F-9575-4BDA-9F59-F981BBA66E23@akamai.com>

Someone want to make the PR ?


From: Andy Polyakov <notifications at github.com>
Reply-To: openssl/openssl <reply+006fe2941848d35b2f5b7667a22cb9097fb66aadfadf1bcd92cf0000000116d2665e92a169ce126b7889 at reply.github.com>
Date: Tuesday, March 27, 2018 at 4:07 PM
To: openssl/openssl <openssl at noreply.github.com>
Cc: Rich Salz <rsalz at akamai.com>, State change <state_change at noreply.github.com>
Subject: Re: [openssl/openssl] Free allow null (#5761)


Mac OS X back log is off charts, it might be time to drop it from build matrix again...

?
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5761-23issuecomment-2D376657320&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=yx6sRPuTctm0G1-xMVCd0q_TPA4iEJX2LYQ5AN4PelM&s=r4fIeRp7VOCFxlnhMLFjGzceI9nOtwuW4obJb11RqSA&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilEq-2DAOrrrvYc6slQ-5F9pWs9PguVomks5tipvegaJpZM4S9MyD&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=yx6sRPuTctm0G1-xMVCd0q_TPA4iEJX2LYQ5AN4PelM&s=dGyv0VSVRtwNLOQ0NEz_gKkHT6wFmQ4JVwoqgT4CR-I&e=>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180327/a5fc2536/attachment.html>

From appro at openssl.org  Tue Mar 27 21:11:08 2018
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 27 Mar 2018 23:11:08 +0200
Subject: [openssl-project] rule-based building attributes
In-Reply-To: <20180326.163719.50335231160279597.levitte@openssl.org>
References: <f46f0fd9-3d08-ae09-42b2-308dedfa3287@openssl.org>
 <20180325.192127.2148750993574074292.levitte@openssl.org>
 <072aaeb6-59b9-0e8a-f33e-35572350c8e0@openssl.org>
 <20180326.163719.50335231160279597.levitte@openssl.org>
Message-ID: <393d0a88-cc24-6ca7-653e-50b8717eb21b@openssl.org>

> appro> How about this. We have touched this when discussing windows-makefile. I
> appro> mean when I called it VC-specific, you disagreed, and I said that
> appro> embedding manifest effectively makes it VC-specific. In the context I
> appro> also suggested post-link stage, a command one could *add* to rule. Or
> appro> let's rephrase this and say that you can simply specify multiple
> appro> commands in an override rule. So with this in mind.
> appro> 
> appro> link => [ 'script-that-composes-list-of-objects $@.$$',
> appro>           'link -o $@ -list $@.$$' ]
> 
> So zooming in on this particular idea, I was concerned about how those
> object file names would be passed to the script...  but then you
> mention manifests, and it dawns on me that there's *nothing* stopping
> us from generating a file with the list of object files when building
> the Makefile.  That does make some kind of sense to me.
> 
> Or were you thinking something different?

Well, when I said "manifest embedding" I meant specifically $(MT) step
of the link rule. But if you want to call $@.$$ output from
'script-that-composes-list-of-objects' for manifest, sure you can do that.

> It would of course be
> possible to have the script you suggest pull data from configdata.pm,
> right?

Or from Makefile, whichever simplest.

> But considering we're talking about third parties building
> their own, that raises another concern, that we suddenly give the
> whole %unified_info structure public exposure that I'm not entirely
> sure were ready for.

You mean not ready to commit to not changing it as our discretion? Well,
then maybe grep-ing Makefile for libcrypto.a: would be more appropriate...

From rsalz at akamai.com  Wed Mar 28 15:53:45 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 28 Mar 2018 15:53:45 +0000
Subject: [openssl-project] Apache update
Message-ID: <77B8DFA3-89B1-4670-80F4-6A393109F71D@akamai.com>

Apache trunk now supports OpenSSL?s TLS 1.3  Woo hoo!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180328/6836de59/attachment-0001.html>

From matt at openssl.org  Thu Mar 29 10:06:46 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 29 Mar 2018 11:06:46 +0100
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
 <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
Message-ID: <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>



On 27/03/18 17:07, Matt Caswell wrote:
> 
> 
> On 27/03/18 14:00, Salz, Rich wrote:
>> 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 think that is ok and doesn't stray too far from what we said in the
> release strategy:
> 
>     A beta release means:
> 
>     Feature complete/Feature freeze (but may include a non-final
>     implementation of the TLSv1.3 specification)
>     Bug fixes only
> 
> We are all still learning about what it will take to have a good TLSv1.3
> implementation so it is not surprising that there are still some things
> we want to do.
> 
> That said, I don't think we should open the flood gates and let large
> amounts of changes through so I think an increased review requirement
> for these types of changes sounds like a good idea. There was a
> suggestion that 3 OMC members would be required to get such a change
> through - and I think that sounds like a good idea.
> 
> 
>> 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 up and drive toward a vote?
> 
> That depends on how controversial the OMC think this is. If it's
> controversial then we can just vote on an case-by-case basis. If there
> are no real objections then I don't mind raising a vote on this.

No comment on this so I'm assuming no major objections to the principle.
How about this for the vote text:

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

Matt



> 
> Matt
> 
> 
> 
>> ? If not, in
>> early April I will start discussion and vote to approve 5702 for the
>> release.
>>
>>
>>
>> _______________________________________________
>> openssl-project mailing list
>> openssl-project at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-project
>>

From levitte at openssl.org  Thu Mar 29 10:15:39 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 29 Mar 2018 12:15:39 +0200 (CEST)
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
 <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
 <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
Message-ID: <20180329.121539.713479555799977172.levitte@openssl.org>

In message <4e32b364-3ed3-9101-158c-09338f96e756 at openssl.org> on Thu, 29 Mar 2018 11:06:46 +0100, Matt Caswell <matt at openssl.org> said:

matt> How about this for the vote text:
matt> 
matt> "Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed
matt> during the beta as long as at least 3 OMC members approve the change"

I can get behind that.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Thu Mar 29 12:49:26 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 29 Mar 2018 12:49:26 +0000
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
 <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
 <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
Message-ID: <1ED83F72-00AA-42D7-BD15-ED022606C7E1@akamai.com>

>    "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.


From rsalz at akamai.com  Thu Mar 29 13:00:47 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 29 Mar 2018 13:00:47 +0000
Subject: [openssl-project] Is making tests faster a bugfix?
Message-ID: <81AA2B72-4D36-4A52-94F3-FE18C3F54E1B@akamai.com>

Please see https://github.com/openssl/openssl/pull/5788

I don?t think it is, but I?d like to know what others think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180329/79a6505a/attachment.html>

From matt at openssl.org  Thu Mar 29 13:03:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 29 Mar 2018 14:03:06 +0100
Subject: [openssl-project] Is making tests faster a bugfix?
In-Reply-To: <81AA2B72-4D36-4A52-94F3-FE18C3F54E1B@akamai.com>
References: <81AA2B72-4D36-4A52-94F3-FE18C3F54E1B@akamai.com>
Message-ID: <e32db73b-b91d-d3c2-274b-6e13e969af34@openssl.org>



On 29/03/18 14:00, Salz, Rich wrote:
> Please see https://github.com/openssl/openssl/pull/5788
> 
> I don?t think it is, but I?d like to know what others think.

I do think this should be applied. The tests in question are not just
slow but *really* slow to the point that I often exit them before they
have completed. This removes the benefits of having the tests in the
first place. From that perspective I view this as a bug fix.

Matt


From levitte at openssl.org  Thu Mar 29 13:45:47 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 29 Mar 2018 15:45:47 +0200 (CEST)
Subject: [openssl-project] Is making tests faster a bugfix?
In-Reply-To: <e32db73b-b91d-d3c2-274b-6e13e969af34@openssl.org>
References: <81AA2B72-4D36-4A52-94F3-FE18C3F54E1B@akamai.com>
 <e32db73b-b91d-d3c2-274b-6e13e969af34@openssl.org>
Message-ID: <20180329.154547.1331200808758077324.levitte@openssl.org>

In message <e32db73b-b91d-d3c2-274b-6e13e969af34 at openssl.org> on Thu, 29 Mar 2018 14:03:06 +0100, Matt Caswell <matt at openssl.org> said:

matt> 
matt> 
matt> On 29/03/18 14:00, Salz, Rich wrote:
matt> > Please see https://github.com/openssl/openssl/pull/5788
matt> > 
matt> > I don?t think it is, but I?d like to know what others think.
matt> 
matt> I do think this should be applied. The tests in question are not just
matt> slow but *really* slow to the point that I often exit them before they
matt> have completed. This removes the benefits of having the tests in the
matt> first place. From that perspective I view this as a bug fix.

Something to remember is that no user will ever complain about this,
because we don't deliver the contents of fuzz/corpora in our tarballs.

In other words, this is a developer only change of our current tests,
and you will only hear from developers who do engage in fuzz testing,
i.e. those who do these tests as part of a release, just to pick a
very recent example.

Also, you may note that this test re-engages fuzz testing as part of
our normal tests that are run for every PR, which means that we will
catch errors that the fuzzers can detect much earlier.  Because the
fuzz testing took so long time, we had them only engaged with
[extended tests], something that's almost never used.

So I would argue that faster fuzz testing means more fuzz testing, and
hopefully better testing of stuff that's harder to catch otherwise.

Cheers,
Richard ( plus, from a very personal point of view, it's *my* time,
	  and Matt's, and whoever else's who tests for releases, that
	  gets substantially less wasted! )

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From tjh at cryptsoft.com  Thu Mar 29 13:55:26 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Thu, 29 Mar 2018 23:55:26 +1000
Subject: [openssl-project] Is making tests faster a bugfix?
In-Reply-To: <20180329.154547.1331200808758077324.levitte@openssl.org>
References: <81AA2B72-4D36-4A52-94F3-FE18C3F54E1B@akamai.com>
 <e32db73b-b91d-d3c2-274b-6e13e969af34@openssl.org>
 <20180329.154547.1331200808758077324.levitte@openssl.org>
Message-ID: <CAHEJ-S71nQtN5gUpLTtfB7JX0PB0F67Ae0Hf_vShLk8omy4EUw@mail.gmail.com>

Improved testing to me is something that is a good thing - and a value
judgement.
It doesn't change libcrypto or libssl - and that to me is the way I think
of it.
Fixing tests and apps and Makefiles to me are different from adding
features to libcrypto or libssl.

On this one - the fuzz testing has been sufficiently slow to reduce its
usefulness - and this is a step in the right direction.

It is however also a bit outside of our current policy on such things - so
perhaps we need to update that.

Tim.


On Thu, Mar 29, 2018 at 11:45 PM, Richard Levitte <levitte at openssl.org>
wrote:

> In message <e32db73b-b91d-d3c2-274b-6e13e969af34 at openssl.org> on Thu, 29
> Mar 2018 14:03:06 +0100, Matt Caswell <matt at openssl.org> said:
>
> matt>
> matt>
> matt> On 29/03/18 14:00, Salz, Rich wrote:
> matt> > Please see https://github.com/openssl/openssl/pull/5788
> matt> >
> matt> > I don?t think it is, but I?d like to know what others think.
> matt>
> matt> I do think this should be applied. The tests in question are not just
> matt> slow but *really* slow to the point that I often exit them before
> they
> matt> have completed. This removes the benefits of having the tests in the
> matt> first place. From that perspective I view this as a bug fix.
>
> Something to remember is that no user will ever complain about this,
> because we don't deliver the contents of fuzz/corpora in our tarballs.
>
> In other words, this is a developer only change of our current tests,
> and you will only hear from developers who do engage in fuzz testing,
> i.e. those who do these tests as part of a release, just to pick a
> very recent example.
>
> Also, you may note that this test re-engages fuzz testing as part of
> our normal tests that are run for every PR, which means that we will
> catch errors that the fuzzers can detect much earlier.  Because the
> fuzz testing took so long time, we had them only engaged with
> [extended tests], something that's almost never used.
>
> So I would argue that faster fuzz testing means more fuzz testing, and
> hopefully better testing of stuff that's harder to catch otherwise.
>
> Cheers,
> Richard ( plus, from a very personal point of view, it's *my* time,
>           and Matt's, and whoever else's who tests for releases, that
>           gets substantially less wasted! )
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180329/d91f5cd3/attachment-0001.html>

From appro at openssl.org  Thu Mar 29 14:07:43 2018
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 29 Mar 2018 16:07:43 +0200
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <AM5PR0701MB26579B27806AF68A1BB5968CE4DE0@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
 <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>
 <AM5PR0701MB26579B27806AF68A1BB5968CE4DE0@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <b6ad8883-9959-97ed-2873-a8d34623885f@openssl.org>

On 03/09/18 17:13, Bernd Edlinger wrote:
> On 03/08/18 12:06, Andy Polyakov wrote:
>>
>>> Andy pointed out that my last e-mail was probably not clear enough.
>>>
>>> I want to drop the current partially overlapping checks
>>> on the WRAP mode ciphers (which were ineffective anyways).
>>>
>>> And allow the following additional use case for any cipher
>>>
>>> unsigned char *in = buf + sizeof(buf) - X, *out = buf;
>>> EVP_EncryptUpdate(ctx, out, &outl, &head, sizeof(head));
>>> out += outl;
>>> EVP_EncryptUpdate(ctx, out, &outl, in, X);
>>> out += outl;
>>> EVP_EncryptUpdate(ctx, out, &outl, &tail, sizeof(tail));
>>> out += outl;
>>>
>>> with X > 75% sizeof(buf)
>>> sizeof(head), sizeof(tail) not necessary multiple of block size
>>>
>>> And make the definition of allowed in-place partially overlapping
>>> effectively be driven by the implementation requirements.
>>
>> Nobody? OK. *Formal* objection to this is that you are making assumption
>> that underlying implementation processes data in specific order. Note
>> that it's not actually unreasonable assumption(*), yet in most general
>> sense it's an assumption, and question rather is if you are in position
>> to **formally** make it(**). One can argue that all our underlying
>> implementations do that, process data in expected order that is, but it
>> doesn't lift the question. One can even argue that suggested code worked
>> in 1.0.1, yet it doesn't lift the question. So instead one simply aims
>> for not making the assumption [or making least amount of assumptions].
>> Yes, you can sense contradiction, because in-place processing also rests
>> on an assumption. Yeah, world is not ideal and life is full of
>> compromises. I mean there are pros and cons, and in-place is considered
>> to bring more pros.
>>
>> (*) And in some cases it's even 100% justified, most notably in CBC
>> encrypt case, when each block is dependent on previous.
>>
>> (**) Note that you can avoid the question by processing data strictly on
>> per-block basis, so that you'll be in control of accessing data in
>> specific order, not underlying implementation. But that's not what is
>> suggested, right?
> 
> No.  The intention is to make the partially overlapping check follow
> the underlying cipher's implementation needs, not the other way round.

I don't follow. What does "underlying cipher's implementation needs"
mean? Or aren't you making quite specific assumption about
implementation the moment you recognize its "needs"? Assumption that it
does in fact processes data in specific order? Does it need to do that?
As *hypothetic* extreme example, consider ECB mode. What prevents
implementation to process blocks in arbitrary order? And if nothing,
what effect would reverse order have for suggested approach? Once again,
I'm not saying that any of our ECB implementation do that, only that
it's *formally* inappropriate to make that kind of assumption. To
summarize, if one wants to permit partially overlapping buffers, then
the only appropriate thing to do would be to perform operations in
chunks on non-overlapping sections. However, I'm not saying that we
should do that, I'd say that it would be unjustified complication of the
code. https://github.com/openssl/openssl/pull/5427#discussion_r172441266
is sufficient.

From kaduk at mit.edu  Thu Mar 29 15:01:12 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Thu, 29 Mar 2018 10:01:12 -0500
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <20180329.121539.713479555799977172.levitte@openssl.org>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
 <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
 <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
 <20180329.121539.713479555799977172.levitte@openssl.org>
Message-ID: <20180329150112.GF77617@kduck.kaduk.org>

On Thu, Mar 29, 2018 at 12:15:39PM +0200, Richard Levitte wrote:
> In message <4e32b364-3ed3-9101-158c-09338f96e756 at openssl.org> on Thu, 29 Mar 2018 11:06:46 +0100, Matt Caswell <matt at openssl.org> said:
> 
> matt> How about this for the vote text:
> matt> 
> matt> "Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed
> matt> during the beta as long as at least 3 OMC members approve the change"
> 
> I can get behind that.

Yup, that sounds good to me as well.

-Ben

From matt at openssl.org  Thu Mar 29 16:45:54 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 29 Mar 2018 17:45:54 +0100
Subject: [openssl-project] About PR 5702, etc.
In-Reply-To: <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
References: <5D4A80A7-D04C-481D-A09E-CEA039A9763F@akamai.com>
 <b73ab5bd-e8c6-5c5d-e5cc-bd674b929ab8@openssl.org>
 <4e32b364-3ed3-9101-158c-09338f96e756@openssl.org>
Message-ID: <16ed52db-4940-3f93-6fee-bc2b8f53f297@openssl.org>



On 29/03/18 11:06, Matt Caswell wrote:
> "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"

I started a vote with this text, and will report back here when I have
the results.

Matt


From bernd.edlinger at hotmail.de  Fri Mar 30 08:42:39 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Fri, 30 Mar 2018 08:42:39 +0000
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <b6ad8883-9959-97ed-2873-a8d34623885f@openssl.org>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
 <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>
 <AM5PR0701MB26579B27806AF68A1BB5968CE4DE0@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <b6ad8883-9959-97ed-2873-a8d34623885f@openssl.org>
Message-ID: <DB6PR0701MB2664281ECBEAA1E117A2480CE4A10@DB6PR0701MB2664.eurprd07.prod.outlook.com>

On 03/29/18 16:07, Andy Polyakov wrote:
> On 03/09/18 17:13, Bernd Edlinger wrote:
>>
>> No.  The intention is to make the partially overlapping check follow
>> the underlying cipher's implementation needs, not the other way round.
> 
> I don't follow. What does "underlying cipher's implementation needs"
> mean? Or aren't you making quite specific assumption about
> implementation the moment you recognize its "needs"? Assumption that it
> does in fact processes data in specific order? Does it need to do that?
> As *hypothetic* extreme example, consider ECB mode. What prevents
> implementation to process blocks in arbitrary order? And if nothing,
> what effect would reverse order have for suggested approach? Once again,
> I'm not saying that any of our ECB implementation do that, only that
> it's *formally* inappropriate to make that kind of assumption. To
> summarize, if one wants to permit partially overlapping buffers, then
> the only appropriate thing to do would be to perform operations in
> chunks on non-overlapping sections. However, I'm not saying that we
> should do that, I'd say that it would be unjustified complication of the
> code. https://github.com/openssl/openssl/pull/5427#discussion_r172441266
> is sufficient.


Once again:
- This PR *recognizes* the fact that special cases do in fact *exist*.
- The EVP layer has to be more aware of special cases anyhow.
- The test coverage of error cases is not perfect, but I try to
   improve that.
- I don't see why we can't relax a check in cases that are known to
   work, especially when test cases are added at the same time.


From appro at openssl.org  Fri Mar 30 15:12:20 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 30 Mar 2018 17:12:20 +0200
Subject: [openssl-project] to fully overlap or not to
In-Reply-To: <DB6PR0701MB2664281ECBEAA1E117A2480CE4A10@DB6PR0701MB2664.eurprd07.prod.outlook.com>
References: <7e68c58f-96ab-4618-9f0e-62198be204c2@openssl.org>
 <1F19D58A-E1F6-488A-9D06-67879A413931@dukhovni.org>
 <AM5PR0701MB26571591F3E84514A27F0055E4C70@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <3a86c3a1-adfb-a4a1-b87e-2d669b86e3a0@openssl.org>
 <4832ac1a-f959-1419-e7a1-b0ceffb64e33@hotmail.de>
 <AM5PR0701MB26577508025E21AF3DEEDDB5E4D90@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <55260508-70d0-44f9-4cc5-2c8aef8bb8ff@openssl.org>
 <AM5PR0701MB26579B27806AF68A1BB5968CE4DE0@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <b6ad8883-9959-97ed-2873-a8d34623885f@openssl.org>
 <DB6PR0701MB2664281ECBEAA1E117A2480CE4A10@DB6PR0701MB2664.eurprd07.prod.outlook.com>
Message-ID: <5ea10e31-bfda-2a87-90e0-6915c5a76297@openssl.org>

> Once again:
> - This PR *recognizes* the fact that special cases do in fact *exist*.

??? Is there application that heavily relies on some specific overlap
percentage?

> - The EVP layer has to be more aware of special cases anyhow.

Where does it come from? Why does it *have to* be more aware of special
cases? There is one special case that we support, fully overlapping
buffer, and that's it, it doesn't *have to* be more than that. Besides,
EVP is *generalized* layer and is not supposed to make overly specific
assumptions. While in order to support suggested cases and the suggested
way, you'll be forced to make an assumption about underlying cipher.
Specifically that it processes blocks in ascending memory order, i.e.
from lower to higher addresses. Once again, all our implementations do
that, but *generalized* EVP layer is not the right spot to assume that
they actually do.

> - The test coverage of error cases is not perfect, but I try to
>    improve that.
> - I don't see why we can't relax a check in cases that are known to
>    work, especially when test cases are added at the same time.

Because we don't have to. Because goal is not to provide maximum
flexibility, but maximum *robustness*. Well, it's not entirely true,
because robustness is not the only goal, but it's not inappropriate to
say that complexity has to be justified by something beside sheer why-not.

From rsalz at akamai.com  Mon Mar 26 15:20:49 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 26 Mar 2018 15:20:49 +0000
Subject: [openssl-project] VOTE on coding style changes
Message-ID: <80F3468E-96D1-4E03-86E4-22CE119D3954@akamai.com>

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 the text of https://github.com/openssl/web/pull/43
into the coding style policy.
Proposed by Rich
Public: yes
opened: 2016-03-26
closed: yyyy-mm-dd

  Matt       [  ]
  Mark       [  ]
  Viktor     [  ]
  Tim        [  ]
  Emilia     [  ]
  Richard    [  ]
  Kurt       [  ]
  Rich       [+1]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180326/d81f30ba/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: changes.txt
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180326/d81f30ba/attachment.txt>