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

2019-07-17 Thread Tim Hudson
My view point (which has been stated elsewhere) is that OpenSSL-3.0 is about internal restructuring to allow for the various things noted in the design documents. It is not about changing the feature set (in a feature reduction sense). In future releases we will make the mixture of providers

Re: punycode licensing

2019-07-10 Thread Tim Hudson
On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky wrote: > Dear Tim, > > Formally I am a contributor with a signed CLA. > I took a code definitely permitting any usage without any feedback, > slightly modified it (at least by openssl-format-source and splitting > between header and source), and

Re: punycode licensing

2019-07-10 Thread Tim Hudson
Previous assertions that if the license was compatible that we don't need a CLA in order to accept a contribution were incorrect. You are now questioning the entire purpose of contributor agreements and effectively arguing they are superfluous and that our policy should be different. You are (of

Re: punycode licensing

2019-07-09 Thread Tim Hudson
On Wed, Jul 10, 2019 at 1:58 AM Salz, Rich wrote: > Thank you for the update. This brings to mind a few additional questions: > > 1. Does other code which is copyright/licensed under the Apache 2 license also require CLAs? See points 1-3 of previous email. CLAs are required for anything

Re: punycode licensing

2019-07-09 Thread Tim Hudson
sed on the license terms of a contribution Thanks, Tim. On Fri, Jun 21, 2019 at 4:24 PM Tim Hudson wrote: > Unfortunately, the issue isn't the compatibility of the license - they do > indeed look relatively compatible to me - and the discussion on this thread > has so far been about tha

Re: punycode licensing

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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Tim Hudson
On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich wrote: > The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > CODES.* No. This is a path to a rather unacceptable outcome. Taking your example and running forward with it, having an out-of-memory separate error code for every

Re: proposed change to committers policy

2019-05-24 Thread Tim Hudson
On Fri, May 24, 2019 at 7:34 PM Matt Caswell wrote: > On 24/05/2019 10:28, SHANE LONTIS wrote: > > It doesn’t stop us both reviewing a PR. That doesn’t mean we both need > to approve. > > Right...but in Matthias's version if you raise a PR, and then Pauli > approves it, > then you only then need

proposed change to committers policy

2019-05-24 Thread Tim Hudson
As part of various discussions, I've drafted a proposed (not yet put to a formal vote) change to the committers policy to address the perception of a potential conflict-of-interest situation. I don't believe that we have actually encountered a conflict of interest in our current policy, but

Re: No two reviewers from same company

2019-05-23 Thread Tim Hudson
We have discussed this at numerous OMC meetings in terms of how to managed potential *perceived *conflicts of interest that might arise if people outside of the fellows come from the same company and hence can effectively turn the OMC review control mechanism into a single control rather than a

Re: Thoughts on OSSL_ALGORITHM

2019-03-22 Thread Tim Hudson
"handle" is the wrong name for this - if you want to have private const data then do that rather than something which might be abused for instance specific information. It could just be an int even or a short. It doesn't have to be a pointer. That would reduce the likely of it being used to hold

function and typedef naming thoughts

2019-03-05 Thread Tim Hudson
Looking at PR#8287 I think we need to get some naming schemes written down and documented and followed consistently. The naming used in this PR seems to be somewhat inconsistent. For me, I think the naming convention most often used is return_type SOMETHING_whatever(SOMETHING *,...) as a

Fwd: openssl-announce post from hong...@gmail.com requires approval

2019-02-26 Thread Tim Hudson
Add a -r to your diff command so you recursively compare ... then you will see the actual code changes. Without the -r you are only comparing files in the top-level directory of each tree. diff *-r* -dup openssl-1.0.2q openssl-1.0.2r Tim. -- Forwarded message -- From: Hong Cho

Re: Thoughts about library contexts

2019-02-18 Thread Tim Hudson
On Mon, Feb 18, 2019 at 8:36 PM Matt Caswell wrote: > > > On 18/02/2019 10:28, Tim Hudson wrote: > > It should remain completely opaque. > > As a general rule, I've never seen a context where someone regretted > making a > > structure opaque over time

Re: Thoughts about library contexts

2019-02-18 Thread Tim Hudson
It should remain completely opaque. As a general rule, I've never seen a context where someone regretted making a structure opaque over time, but the converse is not true. This is opaque and should remain opaque. We need the flexibility to adjust the implementation at will over time. For anything

[openssl-project] inline functions

2019-01-27 Thread Tim Hudson
>From https://github.com/openssl/openssl/pull/7721 Tim - I think inline functions in public header files simply shouldn't be present. Matt - I agree Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made static inline expressly to get better C type safety, and

Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-24 Thread Tim Hudson
On Thu, Jan 24, 2019 at 9:45 PM Matt Caswell wrote: > > This notion of "handshake" is not supported by RFC 8446 uses the terms > "the > > handshake", "a handshake", and "post-handshake". "Post-handshake", in > > particular, implies KeyUpdate are after the handshake, not part of it. > > I just

Re: [openssl-project] To deprecate OpenSSL_version() or not

2018-12-05 Thread Tim Hudson
The function has been there for a long time (since then beginning) and it is all about version related information - so both names aren't exactly clearly descriptive. OpenSSL_version_information() would be a better name. It would also argue that the "version" program should be renamed "info" as

Re: [openssl-project] Minimum C version

2018-10-07 Thread Tim Hudson
I don't see a *substantial benefit* from going to C99 and I've worked on numerous embedded platforms where it is highly unlikely that C99 support will ever be available. Kurt - do you have a specific list of features you think would be beneficial - or is it just a general sense to move forward?

Re: [openssl-project] Release strategy updates & other policies

2018-09-28 Thread Tim Hudson
On Fri, Sep 28, 2018 at 4:55 PM Matt Caswell wrote: > Either we go with semver and totally commit to it - or we stick with what > we've already got. No > half-way, "well we're kind of doing semver, but not really". > +1 I see no point in changing what we are doing *without* getting the benefit

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
On Tue, Sep 25, 2018 at 11:02 PM Matt Caswell wrote: > You're right on this one. I misread the diff. > Not a problem - you are doing the look-at-what-we-did and how it would be impacted - and that is certainly what we should be doing - working through what impact this would have had. Semantic

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
On Tue, Sep 25, 2018 at 10:37 PM Matt Caswell wrote: > - Added some new macros: > https://github.com/openssl/openssl/pull/6037 No we didn't change our public API for this one - we changed *internals*. The change to include/openssl/crypto.h was entirely changing *comments* to document that the

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
On Tue, Sep 25, 2018 at 9:22 PM Matt Caswell wrote: > Lets imagine we release version 5.0.0. We create a branch for it and > declare a support period. Its an LTS release. This is a *stable* > release, so we shouldn't de-stabilise it by adding new features. > > Later we do some work on some new

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell wrote: > On 25/09/18 10:58, Tim Hudson wrote: > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte > <mailto:levi...@openssl.org>> wrote: > > > > So what you suggest (and what I'm leaning toward) means that

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte wrote: > So what you suggest (and what I'm leaning toward) means that we will > change our habits. > Adoption of semantic versioning will indeed require us to change our habits in a number of areas - that is the point of having a single clear

Re: [openssl-project] Release strategy updates & other policies

2018-09-25 Thread Tim Hudson
A fairly common approach that is used is that you can only remove something that has been marked for deprecation at a MAJOR release version boundary. That is entirely independent of the semantic versioning view of things - which also happens to say the same thing (that adding a deprecation

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 3:12 PM Viktor Dukhovni wrote: > The proposal to move the minor version into nibbles 2 and 3 breaks this > OpenSSH function. > No it doesn't - because I'm not talking about moving *anything* in the current encoding for major and minor - see earlier post. The positions

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
If you accept that we have a MAJOR.MINOR.FIX.PATCH encoding currently documented and in place and that the encoding in OPENSSL_VERSION_NUMBER is documented then the semantic versioning is an easy change. We do not need to change our encoding of MAJOR.MINOR - that is documented and fixed. We just

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 11:55 AM Viktor Dukhovni wrote: > this is an ad-hoc encoding with monitonicity as the > the only constraint. > If you start from the position that the encoding of OPENSSL_VERSION_NUMBER is free to change so long as the resulting value is larger than what we have been

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, 22 Sep. 2018, 3:24 am Viktor Dukhovni, wrote: > > On Sep 21, 2018, at 12:50 PM, Tim Hudson wrote: > > If that is the case then our current practice of allowing ABI breakage > with > > minor release changes (the middle number we document as the minor > release n

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, 22 Sep. 2018, 2:29 am Viktor Dukhovni, wrote: > > > > On Sep 21, 2018, at 12:14 PM, Matt Caswell wrote: > > > > I support Richard's proposal with an epoch of 1. > > Grudgingly I would accept an epoch in the 3-8 range. > > I would oppose an epoch of 2. > > I can live with that, though it

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 1:39 AM Viktor Dukhovni wrote: > The only change needed is a minor one in applications that actually > parse the nibbles What I was suggesting is that we don't need to break the current encoding at all. We have a major.minor.fix version encoded and documented in the

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 1:34 AM Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > > On 21.09.2018 17:27, Tim Hudson wrote: > > > > We cannot remove the current major version number - as that concept > exists and we have used it all along. > > We

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 1:16 AM Viktor Dukhovni wrote: > > > > On Sep 21, 2018, at 11:00 AM, Tim Hudson wrote: > > > > If you repeat that in semantic versioning concepts just using the labels > for mapping you get: > > - what is the major version number - the

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Sat, Sep 22, 2018 at 12:32 AM Viktor Dukhovni wrote: > > On Sep 21, 2018, at 10:07 AM, Tim Hudson wrote: > > > > And the output you get: > > > > 0x10102000 > > The trouble is that existing software expects to potential ABI changes > resulting

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
SSL_VERSION_MINOR,OPENSSL_VERSION_PATCH); printf("%s\n",OPENSSL_VERSION_TEXT); } And the output you get: 0x10102000 1.1.2 1.1.2-beta1+21Sep2018.optbuild.arm Tim. On Fri, Sep 21, 2018 at 11:36 PM Richard Levitte wrote: > In message w2o_njr8bfoor...@mail.gmail.com> on Fri, 21 Sep 20

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
Now I get the conceptual issue that Richard and Matt are differing on - and it is about actually replacing OpenSSL's versioning concept with semantic versioning compared to adopting semantic versioning principles without actually being precisely a semantic version approach. The whole concept of

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
Semantic versioning is about a consistent concept of version handling. And that concept of consistency should be in a forms of the version - be it text string or numberic. That you see them as two somewhat independent concepts isn't something I support or thing makes sense at all. Our users

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
So as a concrete example - taking master and the current OPENSSL_VERSION_TEXT value. "OpenSSL 1.1.2-dev xx XXX " would become "1.1.2-dev+xx.XXX." That is what I understand is the point of semantic versioning. You know how to pull apart the version string. -dev indicates a pre-release

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Fri, Sep 21, 2018 at 9:02 PM Matt Caswell wrote: > I think this is an incorrect interpretation of Richard's proposal. The > OPENSSL_VERSION_NUMBER value is an *integer* value. It does not and > cannot ever conform to semantic versioning because, because version > numbers in that scheme are

Re: [openssl-project] A proposal for an updated OpenSSL version scheme (v2)

2018-09-21 Thread Tim Hudson
On Fri, Sep 21, 2018 at 7:58 PM Richard Levitte wrote: > Our FAQ says that such changes *may* be part of a major > release (we don't guarantee that breaking changes won't happen), while > semantic versioning says that major releases *do* incur backward > incompatible API changes. > I think you

Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-10 Thread Tim Hudson
On Mon, Sep 10, 2018 at 8:44 AM, Matt Caswell wrote: > As far as the release criteria go we only count the ones shown in the > Coverity tool. That's not to say we shouldn't fix issues in the tests as > well (and actually I'd suggest we stop filtering out problems in the > tests if anyone knows

Re: [openssl-project] Please freeze the repo

2018-09-09 Thread Tim Hudson
Done. Tim. On Sun, Sep 9, 2018 at 8:34 PM, Matt Caswell wrote: > Please can someone freeze the repo: > > ssh openssl-...@git.openssl.org freeze openssl matt > > > Thanks > > Matt > ___ > openssl-project mailing list > openssl-project@openssl.org >

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Tim Hudson
All PRs except #7145 now reviewed and marked ready. Tim On Fri, Sep 7, 2018 at 8:41 AM, Matt Caswell wrote: > We currently have 8 1.1.1 PRs that are open. 3 of which are in the > "ready" state. There are 2 which are alternative implementations of the > same thing - so there are really on 4

Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Tim Hudson
We need to get this release out and available - there are a lot of people waiting on the "production"release - and who won't go forward on a beta (simple fact of life there). I don't see the outstanding items as release blockers - and they will be wrapped up in time. Having the release date as a

Re: [openssl-project] Release Criteria Update

2018-09-05 Thread Tim Hudson
On Thu, Sep 6, 2018 at 8:59 AM, Matt Caswell wrote: > #7113 An alternative to address the SM2 ID issues > (an alternative to the older PR, #6757) > > Updates made following earlier review. Awaiting another round of reviews. > Owner: Paul Yang All the previous comments have been addressed. I

[openssl-project] New OMC Member and New Committers

2018-08-22 Thread Tim Hudson
Welcome to Paul Dale (OMC) , Paul Yang and Nicola Tuveri (Commiters). See the blog post at https://www.openssl.org/blog/blog/2018/08/22/updates/ Thanks, Tim. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Removal of NULL checks

2018-08-08 Thread Tim Hudson
We don't have a formal policy of no NULL checks - we just have a few members that think we should have such a policy but it has never been voted on as we had sufficiently varying views for a consensus approach to not be possible. Personally I'm in favour of high-level APIs having NULL checks as

Re: [openssl-project] Current votes FYI

2018-05-23 Thread Tim Hudson
No that vote does not pass. All votes require participation by a majority of active members. Failure to have a majority participation causes a vote to fail. With only three out of eight members voting this vote simply did not pass. Tim. On Thu, 24 May 2018, 12:59 am Salz, Rich,

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

2018-04-15 Thread Tim Hudson
Where we are stating that ABI compatibility is in place we should be testing it. i.e. the older release binaries should be run against the current release libraries - and that should be put into CI in my view. Going the other direction isn't something I have thought we have ever guaranteed (i.e.

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-03 Thread Tim Hudson
else) > > In message <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8C > w...@mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +, Tim Hudson < > t...@cryptsoft.com> said: > > tjh> And it should have a test - which has nothing to do with ASM and > everything to d

Re: [openssl-project] Is making tests faster a bugfix?

2018-03-29 Thread Tim Hudson
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

[openssl-project] constification on already released branches

2018-03-25 Thread Tim Hudson
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

Re: [openssl-project] Code Repo

2018-03-20 Thread Tim Hudson
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

Re: [openssl-project] GitHub milestone for 1.1.1

2018-03-19 Thread Tim Hudson
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 wrote: > I would consider it a

[openssl-project] OpenSSL FIPS Wiki Update

2018-03-14 Thread Tim Hudson
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

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

2018-03-13 Thread Tim Hudson
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

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

2018-03-13 Thread Tim Hudson
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,

Re: [openssl-project] External contributors and the next release

2018-03-06 Thread Tim Hudson
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

Re: [openssl-project] VOTE on travel reimbursement policy

2018-02-14 Thread Tim Hudson
[kurt] > So I think we should either all vote in public, or nobody should vote in public. You make a good point there - I agree. Tim. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] VOTE on travel reimbursement policy

2018-02-14 Thread Tim Hudson
> Now, the initial posting went to both the OMC and the project list, > and some chose to vote with a simple "Reply All" without editing the > recipients. If that was on purpose or because attention wasn't payed > to that detail, I cannot say. For my part, it was just a reply-all - but if I had

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

2018-02-10 Thread Tim Hudson
Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We