[openssl-project] OpenSSL 3.0 and FIPS Update

[Benjamin Kaduk]

On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote:
> 
> Matt Caswell <matt at openssl.org> wrote:
>     > Please see my blog post for an OpenSSL 3.0 and FIPS Update:
> 
>     > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
> 
> Thank you, it is very useful to have these plans made up front.
> I think your posts should probably explain what happened to 2.x, and if this
> represents a move towards semantic versioning. (I think it does...?)
> 
> In the various things linked, in particular:
>    https://www.openssl.org/docs/OpenSSL300Design.html
> 
> I think that there is a missing box.  Specifically, the PERL API wrappers

Later on you seem to clarify that by "PERL API" you mean "Net::SSLeay" but
I just want to double-check.

> that are used in the test bench.  I believe that the "applications" are
> a serious problem as there are (in 1.1.1) still many things that are very
> difficult (sometimes, it seems, impossible) to do programmatically, and which
> the test cases actually simply shell out to the application to do.
> An example of this is adding certain extensions to a certificate when
> generating it, which is only really possible by loading pieces of
> configuration file in.

It might we worth raising github issues to point out these omissions.

> So what I'd like to see is to remove many of the applications from the core
> of OpenSSL, put them into a seperate package using better-documented API
> calls.  Let them evolve according their own time-scale, probably taking
> patches faster without disrupting the underlying libraries.

In the vein of your later comment about "20 years of twisty code", I'm
actually somewhat inclined to clave off the applications and leave them
alone, so that people needing bug-for-bug compatibility can keep it.  Then
we could rewrite the functionality in question with a more maintainable
structure in a way that would also function as examplar API usage.

> My observation is that the Perl testing system is used to drive the tests,
> but the tests do not actually use the Perl API wrapper for OpenSSL, but
> rather rely on the vast number of .c files in test/*.
> In other (more purely agile) projects, the test cases often serve as
> documentation as to how to use the API.  In OpenSSL, the test cases
> rely too much on the openssl "applications", and the API is hidden.

So, when I write new code that requires tests (which is basically all new
code, try as I may to convince myself otherwise), the first thing I try to
do is put in an API-only test that's a "standalone" executable (ignore
sslapitest.c which is not standalone but functionally is so) to exercise
narrowly the functionality in question.  Only if it's a big hassle,
requires additional (certificate) input and/or configuration files, etc.,
do I fail over to using the "application" as the testbed.  There's a
tradeoff, and while the current playing field often biases that tradeoff in
a direction I'd rather not go, changing the playing field is more work than
I have time to take on while a sitting IETF AD.

> This would involve adopting some or all of Net::SSLeay.
> While there would be some initial duplication of effort, I think that over
> time it would sort itself out.  Perl is no longer as cool as it used to be (I
> still like it) and maybe someone would argue for Python3 or something, and
> frankly I don't care which.

I don't think that OpenSSL itself should adopt Net::SSLeay, even though we
do seem to have one of the higher perl usage fractions of the open-source
projects I interact with.  We have enough on our hands with the core C
libraries to modernize.

> What I care about is that the test cases actually test the API, rather than
> depend upon 20 years of twisty code in the "applications".
> And that the applications are permitted to grow/change/adapt to people's
> needs, rather than living in a hard spot between developer needs and end
> user needs, pissing off both groups.

I agree that mixing user needs and developer needs is a recipe for sadness.
I'm not sure that actually tearing them apart from the current "apps" is
something that we can realistically do while preserving our goal of
cross-release stability.

-Ben