Matt Caswell <m...@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
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.

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.

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.

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.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     m...@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [





Attachment: signature.asc
Description: PGP signature

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

Reply via email to