Re-arrange the library structure - Re: CMP is a subproject?

[Michael Richardson]

David von Oheimb <dev at ddvo.net> wrote:
    > To avoid any misunderstandings on what I wrote before:
    > My proposal (possibly in difference to Dmitry's) was and still is *not* to
    > move any functionality out of the OpenSSL main repository,
    > but to re-arrange the library structure (likely by splitting libcrypto into
    > two or more libraries) to better reflect the code layering.

What I observe is that the "openssl" *app* is not the best example code out
there.   There are a number of things, particularly those involving
certificate creation, where the only obivous[%] way to get some things done is
to use an openssl.conf fragment.

[%]- sometimes there are non-obvious ways, but the only example code is the
apps/*.c, so people wind up emulating it.

There are also some things (no, I don't have a list handy) that are done by
the apps code, which ought to be a library function.  People wind up copy and
pasting, then of course, it becomes non-obvious how to update their code.

    > Expected benefits:

    > * reduce binary code footprint in case just the crypto core or just
    > TLS (including crypto) is needed

This last part is probably a red herring.
If you link against the .a files, then you get only what you need.
If you link against the .so, then in theory you pay only once for all users.

    > * some so far internal crypto interfaces that are used by the more
    > application-level code need to be exported

We need to make a list of these.
I think that they are more on the "poorly documented" rather than internal.

    > plus an actual library (say, libapps) that is more application-level and
    > includes everything that requires both TLS any crypto features, such as
    > HTTPS and part of (or even all of) apps/lib/.
    > This likely would provide a better pros/cons ratio than actually splitting up
    > libcrypto.

I agree with you.
I also also agree that restructuring should occur first, and I think that
introducing a libapps could in the 3.x stream, but that many other things
would be a 4.0

    > In particular, as Tomas wrote, the openssl app will continue to provide
    > everything that it did before.

I have advocated in the past splitting the "openssl" app into a new repo
which could evolve at a different rate,  and with a different level of
scrutiny to the core library.

--
Michael Richardson <mcr+IETF at sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 515 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20220708/13fe6650/attachment.sig>