From matt at openssl.org  Wed Dec  5 16:50:27 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 5 Dec 2018 16:50:27 +0000
Subject: [openssl-project] To deprecate OpenSSL_version() or not
Message-ID: <a7641599-7710-156f-eee6-410bf7d52fa6@openssl.org>

Richard and I are discussing whether OpenSSL_version() should be deprecated or
not in favour of a new function OPENSSL_info() which does more or less the same
thing. See:

https://github.com/openssl/openssl/pull/7724#discussion_r239067887

Richard's motivation for doing so is that he finds the old name "strongly
misleading". I disagree and prefer not to deprecate functions like this just
because we don't like the name (which eventually will lead to breakage when we
remove the deprecated functions in some future major version (not 3.0.0))

I'd appreciate more input on the discussion.

Matt

From tjh at openssl.org  Wed Dec  5 18:27:32 2018
From: tjh at openssl.org (Tim Hudson)
Date: Wed, 5 Dec 2018 19:27:32 +0100
Subject: [openssl-project] To deprecate OpenSSL_version() or not
In-Reply-To: <a7641599-7710-156f-eee6-410bf7d52fa6@openssl.org>
References: <a7641599-7710-156f-eee6-410bf7d52fa6@openssl.org>
Message-ID: <CAHEJ-S6Ch8mfn4AbycVQ0jeOKNsdq1mg0RNxTtNCz=bvVFpb+A@mail.gmail.com>

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
the same argument would equally apply.

However I do not think we should rename a function and deprecate a function
that is very widely used.

And the function should also cover everything that the current "version"
application covers (like seeding source etc). The ifdefs there are not
something we should expect applications to repeat.

Tim.

On Wed, 5 Dec. 2018, 5:50 pm Matt Caswell <matt at openssl.org wrote:

> Richard and I are discussing whether OpenSSL_version() should be
> deprecated or
> not in favour of a new function OPENSSL_info() which does more or less the
> same
> thing. See:
>
> https://github.com/openssl/openssl/pull/7724#discussion_r239067887
>
> Richard's motivation for doing so is that he finds the old name "strongly
> misleading". I disagree and prefer not to deprecate functions like this
> just
> because we don't like the name (which eventually will lead to breakage
> when we
> remove the deprecated functions in some future major version (not 3.0.0))
>
> I'd appreciate more input on the discussion.
>
> 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/20181205/86439420/attachment.html>

From levitte at openssl.org  Wed Dec  5 18:37:45 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 05 Dec 2018 19:37:45 +0100 (CET)
Subject: [openssl-project] To deprecate OpenSSL_version() or not
In-Reply-To: <CAHEJ-S6Ch8mfn4AbycVQ0jeOKNsdq1mg0RNxTtNCz=bvVFpb+A@mail.gmail.com>
References: <a7641599-7710-156f-eee6-410bf7d52fa6@openssl.org>
 <CAHEJ-S6Ch8mfn4AbycVQ0jeOKNsdq1mg0RNxTtNCz=bvVFpb+A@mail.gmail.com>
Message-ID: <20181205.193745.727377329844068926.levitte@openssl.org>

In message <CAHEJ-S6Ch8mfn4AbycVQ0jeOKNsdq1mg0RNxTtNCz=bvVFpb+A at mail.gmail.com> on Wed, 5 Dec 2018 19:27:32 +0100, Tim Hudson <tjh at openssl.org> said:

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

Considering most of the information is build data, I have a hard time
understanding how it's related to the version per se, except in a
fairly abstract manner (like Matt said, "the info related to this
version")...  Ah well.

> It would also argue that the "version" program should be renamed
> "info" as the same argument would equally apply.

Yeah, except its default response is to give the version string.

> However I do not think we should rename a function and deprecate a
> function that is very widely used.

... ok
> 
> And the function should also cover everything that the current
> "version" application covers (like seeding source etc). The ifdefs
> there are not something we should expect applications to repeat.

THAT I agree on...  but that should probably be in a different PR,
this one is already plenty as it is.

> Tim.
> 
> On Wed, 5 Dec. 2018, 5:50 pm Matt Caswell <matt at openssl.org wrote:
> 
>  Richard and I are discussing whether OpenSSL_version() should be deprecated or
>  not in favour of a new function OPENSSL_info() which does more or less the same
>  thing. See:
> 
>  https://github.com/openssl/openssl/pull/7724#discussion_r239067887
> 
>  Richard's motivation for doing so is that he finds the old name "strongly
>  misleading". I disagree and prefer not to deprecate functions like this just
>  because we don't like the name (which eventually will lead to breakage when we
>  remove the deprecated functions in some future major version (not 3.0.0))
> 
>  I'd appreciate more input on the discussion.
> 
>  Matt
>  _______________________________________________
>  openssl-project mailing list
>  openssl-project at openssl.org
>  https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Thu Dec  6 11:13:01 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 6 Dec 2018 11:13:01 +0000
Subject: [openssl-project] Monthly Status Report (November)
Message-ID: <6ee72cd8-5f77-291e-72ac-5f992280af98@openssl.org>

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

- Significant review work on the Kernel TLS Socket API PR (5253)
- Significant work on the FIPS Strategy and Design documents
- Significnat review work on the SRP docs PR (7522)
- Managed and performed the release of 1.1.1a/1.1.0j/1.0.2q
- Added a missing SSLfatal call that could result in an assertion failure
- Worked on PR 7442 (Don't negotiated TLSv1.3 if our EC cert isn't TLSv1.3 capable)
- Worked on PR 7503 (Separate ca_names handling for client and server)
- Produced and published advisory for CVE-2018-5407
- Fixed no-ec and no-tls1_2
- Fixed uninit read in siphash_internal_test
- Created PR to add option to avoid atexit, and to avoid pinning of the
libraries in memory (7647)
- Fixed a failure in errtest affecting a number of platforms
- Reviewed the BN_div constant time change (7589)
- Investigated and advised on fix for 7660 (tls_construct_server_key_exchange
internal error)
- Investigated and created fix for Ed25519 signature maleability issue (PR 7697)
- Attended the OpenSSL OMC face-2-face in Edinburgh
- Attended the OpenSSL FIPS meeting in Edinburgh

Matt

From kurt at roeckx.be  Thu Dec  6 21:32:09 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 6 Dec 2018 22:32:09 +0100
Subject: [openssl-project] Vote to update the security policy
In-Reply-To: <CABU6YOadhrhagf0UcrTxo4r7daDHx2LSBWHDiwZD+NkqhdVoDg@mail.gmail.com>
References: <CABU6YOadhrhagf0UcrTxo4r7daDHx2LSBWHDiwZD+NkqhdVoDg@mail.gmail.com>
Message-ID: <20181206213208.GA29462@roeckx.be>

On Thu, Nov 29, 2018 at 03:34:29PM +0000, Mark J Cox wrote:
> Changes to policies require an OMC vote which I've called to approve an
> update to the security policy.  This was as discussed at the face to face
> and the details and diff are at https://github.com/openssl/web/pull/96
> 
> ----------------
> topic: Update security policy as per https://github.com/openssl/web/pull/96

This vote failed with 4 votes against and 3 people not voting.

The intend of voting against is to work on the wording and then
call a new vote.


Kurt


From levitte at openssl.org  Fri Dec  7 09:52:04 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 07 Dec 2018 10:52:04 +0100 (CET)
Subject: [openssl-project] Monthly Status Report (November)
Message-ID: <20181207.105204.1366229682530992274.levitte@openssl.org>

Apart from normal business, such as normal reviews, OMC business,
normal system administration tasks, etc., key activities this month:

Development:

- Supported and reviewed the 1.1.1a/1.1.0j/1.0.2q releases
- Worked on making the /dev/crypto engine a bit more efficient and to
  provide digest copy functionality (PR 7506)
- Added the possibility to assign C macros on per object or end
  product files (PR 7553)
- Added the possibility to specify sub-directories in build.info files
  (PR 7558)
- Allowed parallell install, and made install targets depend more
  closely on build targets (PR 7583)
- Added issue templates and user support page on Github (PR 7623 and 7632)
- Fixed an rpath related issue in our tests (PR 7626)
- Made the internal collection of system error messages smarter (PRs
  7681 and 7701)
- Changed our tarball creating procedure to use the script
  util/mktar.sh (PR 7692 and 7696)
- Fixed a few VMS build issues for assembler (PR 7700 and 7703)
- Reviewed a few EVP_MAC ports (PRs 7548, 7459, 7597)
- Reviewed assembler fixups (PR 7643)
- Reviewed interactive read of pkeyopts (PR 5697)
- Reviewed constant-time RSA fixes
- Attended the OpenSSL OMC face-2-face in Edinburgh
- Attended the OpenSSL FIPS meeting in Edinburgh
- Updating work on building docs at build time (PR 6236)
- Reworking building to become more dynamic (PR 7473 and yet
  unsubmitted branches)
- Fixing a BIO_s_connect crash on NULL issue (PR 7630)
- Adding attributes to product files in build.info (PR 7581)
- Reviewing the EVP_KDF work (PR 6674)
- Reviewing the mac application (PR 7661)
- Reviewing further /dev/crypto engine development (PR 7585)

Admin:

- Working on an update of Buildbot

Others:

- Fixed addrev / gitaddrev casing issues
- Added progress spinner to copyright checker release script

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

From levitte at openssl.org  Tue Dec 11 16:09:15 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 11 Dec 2018 17:09:15 +0100 (CET)
Subject: [openssl-project] Engaging the community
Message-ID: <20181211.170915.1382379711082763288.levitte@openssl.org>

I noticed a while ago that github proposed a couple of lables to help
potential first-time contributors find their way in our pile of issues
and PRs.

The lables are:

    'good first issue'
    'help wanted'

So, I just added those lables to our repo.  It would be good if we
could remember to use them when appropriate.

So what is appropriate?  I think that's very much a judgement call,
but it should certainly be about bite size issues, i.e. something
relatively easy for the newcommer to get started somewhere.

For example, I just labled issue #7872, 'cause that seems to be a fine
and very easy entry level task.

Cheers,
Richard

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

From openssl-users at dukhovni.org  Mon Dec 31 03:52:08 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 30 Dec 2018 22:52:08 -0500
Subject: [openssl-project] Sanity check understanding of automatic module
	initialization?
Message-ID: <20181231035208.GQ79754@straasha.imrryr.org>

With automatic library initialization in OpenSSL 1.1.0 and later,
settings from the system-wide "openssl.cnf" file are automatically
loaded and may in turn cause various "modules" to be initialized.

For example, with:

  openssl.conf:
    openssl_conf            = system-wide-modules
    #
    [system-wide-modules]
    ssl_conf                = system-wide-ssl
    #
    [system-wide-ssl]
    system_default          = ssl-defaults
    #
    [ssl-defaults]
    MinProtocol = TLSv1.2
    ...

the settings in the "ssl-defaults" section will be loaded into memory,
and will be applied to every SSL_CTX() via:

    SSL_CTX_new() ->
    ssl_ctx_system_config() ->
    ssl_do_config() ->
    conf_ssl_get() ... SSL_CONF_cmd()

Any settings loaded via SSL_CTX_config() are in addition to the
above, possibly not necessarily overriding some of the implicit
defaults.

Looking at the code, it seems that the only way to make sure that
the application is not affected by unexpected system-wide settings,
is to load an alternative configuration file, via:

    CONF_modules_load_file()

making sure that the file contains at least one profile in the
"ssl_conf" module section, whose section (to avoid errors) requires
at least one setting (empty sections should IMHO be tolerated, but
currently raise errors).  For example, it seems that the below will
suffice to avoid inherting any settings from the default system-wide
openssl.cnf file:

  openssl.conf:
    myapp		    = myapp-modules
    #
    [myapp-modules]
    ssl_conf                = myapp-ssl-module
    #
    [myapp-ssl-module]
    bogus-profile           = bogus-ssl-settings
    #
    [bogus-ssl-settings]
    MinProtocol = TLSv1.0

If the above is wrong or missing key details, please let me know.

Beyond the sanity check, it seems to me that some of the "big picture"
is missing from the documentation.  We have descriptions of pieces
of the API, but discussion of the interaction with automatic
initialization and how all the pieces fit together seems to be
missing.  The docs seem to date back to 1.0.2, and the changes in
1.1.0 are not generally properly reflected.

This would be good to address.

-- 
	Viktor.