Re: stable branch release cadence

2020-09-15 Thread Tim Hudson
Thanks Matt - cut-n-paste fumble on my part from the previous vote summary.
The tally should always equal the number of OMC members.

For: 6, against: 0, abstained 0, not voted: 1

Tim.


On Wed, Sep 16, 2020 at 8:11 AM Matt Caswell  wrote:

>
>
> On 15/09/2020 23:10, Tim Hudson wrote:
> > The OMC voted to:
> >
> > /Release stable branch on the second last Tuesday of the last month in
> > each quarter as a regular cadence./
> >
> > The vote passed.
> > For: 6, against: 9, abstained 0, not voted: 1
>
> That should say against: 0
>
> ;-)
>
> Matt
>
> >
> > Thanks,
> > Tim.
> >
>


Re: stable branch release cadence

2020-09-15 Thread Matt Caswell



On 15/09/2020 23:10, Tim Hudson wrote:
> The OMC voted to:
> 
> /Release stable branch on the second last Tuesday of the last month in
> each quarter as a regular cadence./
> 
> The vote passed.
> For: 6, against: 9, abstained 0, not voted: 1

That should say against: 0

;-)

Matt

> 
> Thanks,
> Tim.
> 


stable branch release cadence

2020-09-15 Thread Tim Hudson
The OMC voted to:

*Release stable branch on the second last Tuesday of the last month in each
quarter as a regular cadence.*

The vote passed.
For: 6, against: 9, abstained 0, not voted: 1

Thanks,
Tim.


Forthcoming OpenSSL Release

2020-09-15 Thread Matt Caswell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1h.

This release will be made available on Tuesday 22nd September 2020
between 1300-1700 UTC.

OpenSSL 1.1.h is a bug-fix release. There are no CVEs addressed in this
release.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl9hObYACgkQ2cTSbQ5g
RJGmDAf+IPnGTpXB6XpHpuvlWWE6v0aTEOHntLgeYbqp9v3/5ay4i0qwFZk2M4Sn
9J5C/057OqqLVMq0UyXXAwhyS52KIR6VfcJKTCc/2NkgPHhee+/W5Q8SgGpXMnOP
60EIrHD5cfkestIO9fvrCHZ19RFFWlFQJnPmc64nLYyhQJ83a/AKGoug459oaxm7
lj90Rd+U4oQvEJyltsA5Urv/IAjQV24EYej1pCLb4zqerW4rLYnoATBrurclWVOa
5AXZgzuhNvtMV3/nVB7aFpfQIsg2FUaTnRW3ok+7e72oiXHndgxYW6TP0GxGOMdu
RDB1ZlWWwt7LzYz8BlWTex+s23SNZA==
=wNcz
-END PGP SIGNATURE-


Re: Reordering new API's that have a libctx, propq

2020-09-15 Thread Matt Caswell



On 14/09/2020 11:30, Matt Caswell wrote:
> In order to try and move this discussion forward I have made a concrete
> proposal for how we should formulate the various ideas in this thread
> into an actual style. Please see here:
> 
> https://github.com/openssl/web/pull/194

I've updated this PR with some of the feedback received so far. Please
take another look.

I plan to start two OTC votes on this tomorrow with the following wording:

"Adopt the coding style policy on function arguments as shown in chapter
6.1 of web PR 194 (commit 7b45b46d71f)"

"Adopt the coding style policy on extending existing functions as shown
in chapter 6.2 of web PR 194 (commit 7b45b46d71f)"

In the event that one vote passes but the other vote does not I will
remove the section of text that did not pass from the PR and adjust
chapter numbers accordingly.

Matt

> 
> Since we're not yet fully in agreement some compromises will have to be
> made. I hope I've come up with something which isn't too abhorrent to
> anyone.
> 
> Please take a look.
> 
> Matt
> 
> 
> On 05/09/2020 04:48, SHANE LONTIS wrote:
>>
>>   PR #12778 reorders all the API’s of the form:
>>
>>
>>   EVP_XX_fetch(libctx, algname, propq) 
>>
>>
>>   So that the algorithm name appears first.. 
>>
>>
>>   e.g: EVP_MD_fetch(digestname, libctx, propq);
>>
>> This now logically reads as 'search for this algorithm using these
>> parameters’.
>>
>> The libctx, propq should always appear together as a pair of parameters.
>> There are only a few places where only the libctx is needed, which means
>> that if there is no propq it is likely to cause a bug in a fetch at some
>> point. 
>>
>> This keeps the API’s more consistent with other existing XXX_with_libctx
>> API’s that put the libctx, propq at the end of the parameter list..
>> The exception to this rule is that callback(s) and their arguments occur
>> after the libctx, propq..
>>
>> e.g:
>> typedef OSSL_STORE_LOADER_CTX *(*OSSL_STORE_open_with_libctx_fn)
>>     (const OSSL_STORE_LOADER *loader,
>>      const char *uri, OPENSSL_CTX *libctx, const char *propq,
>>      const UI_METHOD *ui_method, void *ui_data);
>>
>> An otc_hold was put on this.. Do we need to have a formal vote?
>> This really needs to be sorted out soon so the API’s can be locked down
>> for beta.
>>
>> 
>> Also discussed in a weekly meeting and numerous PR discussions was the
>> removal of the long winded API’s ending with ‘with_libctx’
>> e.g CMS_data_create_with_libctx
>> The proposed renaming for this was to continue with the _ex notation..
>> If there is an existing _ex name then it becomes _ex2, etc.
>> There will most likely be additional parameters in the future for some
>> API’s, so this notation would be more consistent with current API’s.
>> Does this also need a vote?
>>
>> Regards,
>> Shane
>>
>>


Re: SM2 asymmetric encryption

2020-09-15 Thread Matt Caswell
I have started this vote and will report back when I have an answer.

Matt

On 14/09/2020 09:18, Matt Caswell wrote:
> Currently, 1.1.1  supports SM2 asymmetric encryption. Real world use of
> this is currently believed to be low (IIUC it is mainly useful for SM2
> in TLS, which we don't current support). A discussion in PR #12536 is
> proposing to drop this feature from 3.0 (possibly to re-introduce it in
> some later release). This was mentioned on this list by me in this post:
> 
> https://mta.openssl.org/pipermail/openssl-project/2020-August/002138.html
> 
> No feedback has been received on that point. It was also discussed at
> the recent OMC f2f (although no vote was held on the issue). Since
> dropping this support is a breaking change it requires an OMC vote to
> approve it. I'm proposing this vote wording:
> 
> "Support for SM2 asymmetric encryption should be dropped from OpenSSL 3.0"
> 
> Please let me know any thoughts on the vote wording (or any other
> thoughts on the topic). Otherwise I plan to start this vote soon.
> 
> Matt
> 


Re: New GitHub label for release blockers

2020-09-15 Thread Richard Levitte
On Tue, 15 Sep 2020 09:46:53 +0200,
Dr. Matthias St. Pierre wrote:
> > If we make them the same, what's the reason to have both?
> 
> I completely agree. According to my understanding,  it would have
> made more sense if we had created an "OpenSSL 3.0" project for
> managing all what needs to go into this major release and three
> milestones '3.0.0 alpha',  '3.0.0 beta', '3.0.0' associated with the
> major events.

And that, exactly that, would create a project that fulfill the exact
same functionality as the 3.0.0 milestone.  Why would that be
necessary?  Just use the milestones.

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


Re: New GitHub label for release blockers

2020-09-15 Thread David von Oheimb
Concerning PR #4930:

Originally that PR was about extending support for PKCS#12 input in
apps, which meanwhile has been superseded mostly by OSSL_STORE.
I meanwhile carved out the most interesting remaining pieces of the PR 
and contributed them separately.
I've just rebased and cleaned up the various remaining commits.

What is still left are fixes for several corner cases in PKCS#12 input
and its error handling.
There are also some rather unrelated fixes to several apps and their
documentation, which I could separate if requested.
I don't think any of this is critical before the beta release; in
particular there are no feature or API changes any more.

    David

On 14.09.20 19:32, Richard Levitte wrote:
> On Sun, 13 Sep 2020 22:41:23 +0200,
> Dr. Matthias St. Pierre wrote:
>> Conversely, there were also pull requests associated with the '3.0.0' or 
>> '3.0.0 beta1' milestone,
>> without  being associated to the  '3.0 New Core + FIPS' project. This has 
>> been fixed now.
> I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1
> with the '3.0 New Core + FIPS' project.  If we make them the same,
> what's the reason to have both?
>
> I just looked in the project, and these are issues and PRs the
> presence of which I think is questionable:
>
> #10612
> #4930
> #12860
> #11311
>
> Maybe there's a misunderstand of what "3.0 New Core" means.  Please
> note the lack of comma.  But if that doesn't help, how about the
> project description?
>
> I've seen a bit too much of wanting to pile *everything* into that
> project.  That was never the intention.
>
> Cheers,
> Richard
>


RE: New GitHub label for release blockers

2020-09-15 Thread Dr. Matthias St. Pierre
> I fail to see why the milestones '3.0.0' / '3.0.0 beta1' must be 1:1
> with the '3.0 New Core + FIPS' project.  

Sorry for the misunderstanding, Richard. I did not intend to mess around with 
your project organization.
Since it was the only active GitHub project, I misinterpreted it as the "3.0.0" 
project and did not read
the fine print.

All I intended to do is to obtain an accurate overwiew of what remains to be 
done.
Because listing them on the otc mailing list is not very maintainable, and the 
google spreadsheet is not viewable by the public.

> If we make them the same, what's the reason to have both?

I completely agree. According to my understanding,  it would have made more 
sense if we had created
an "OpenSSL 3.0" project for managing all what needs to go into this major 
release and three milestones
'3.0.0 alpha',  '3.0.0 beta', '3.0.0' associated with the major events.

Regards,
Matthias