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

[David von Oheimb]

On 07.07.22 23:02, Tim Hudson wrote:

> I do not think this makes sense at this stage at all.
> One of the key elements people are looking for when contributing code 
> is the distribution vector of getting including in default OS 
> distributions and standard builds.

I fully agree.

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.

Expected benefits:

  * improve clarity of the software component structure
  * slightly alleviate development and maintenance
  * reduce binary code footprint in case just the crypto core or just
    TLS (including crypto) is needed

Expected drawbacks:

  * any re-structuring requires more or less work
  * some so far internal crypto interfaces that are used by the more
    application-level code need to be exported
  * applications that also require the more high-level capabilities will
    need to link with more libraries

We may also consider splitting the existing libcrypto just virtually, 
e.g., into two code directories (say, crypto/ and crypto/apps/, which 
includes CMS, CMP, OCSP, HTTP, TS, etc.)
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.

> This is something we could look at tackling in a future major release 
> - but even then it faces challenges to be workable for the desired 
> outcome (broad distribution of capability).
With just re-arranging the code into three (or more, rather than so far 
two) OpenSSL libraries, there will be no issue with capability because 
nothing is lost for OpenSSL users.
In particular, as Tomas wrote, the openssl app will continue to provide 
everything that it did before.

     David


> On Thu, 7 July 2022, 18:48 Tomas Mraz, <tomas at openssl.org> wrote:
>
>     OpenSSL Project list should be used instead of the committers list for
>     such discussions.
>
>     I do not think it would be good idea to do any such splitting before a
>     major release development is being started (i.e., 4.0).
>
>     The openssl application could depend on that application library(ies).
>
>     Tomas
>
>     On Wed, 2022-07-06 at 09:32 +0200, David von Oheimb wrote:
>>     Yes, there are number of components that should better be moved
>>     out of the core crypto library into a more application-level one.
>>     As I wrote three days ago, though my email got stuck in mailing
>>     list moderation:
>>
>>     -------- Forwarded Message --------
>>     Subject:     Re: CMP is a subproject?
>>     Date:     Sun, 3 Jul 2022 22:50:06 +0200
>>     From:     David von Oheimb <David.von.Oheimb at siemens.com>
>>     To:     Dmitry Belyavsky <beldmit at gmail.com>, List of openssl
>>     committers <openssl-committers at openssl.org>
>>
>>     Dear all,
>>
>>     thanks Dmitry for sharing this thought.
>>     In a sense it is an instance of a more general suggestion I gave
>>
>>       * back in 2017: Introducing an application-level library for
>>         the CLI and OpenSSL-based applications #4992
>>         <https://github.com/openssl/openssl/pull/4992>
>>       * and in 2020: Improve overall OpenSSL library structure #13440
>>         <https://github.com/openssl/openssl/issues/13440>
>>
>>     which pertains also to CMS, HTTP, OCSP, TS, and maybe further
>>     more application-level component(s) of libcrypto like CT.
>>
>>     The CMP implementation does not rely on libssl, but it does
>>     heavily rely on libcrypto and relies on some of its internals.
>>     The same holds for HTTP, and likely this also holds for CMS,
>>     OCSP, TS, and CT.
>>
>>         David
>>
>>     On 06.07.22 07:25, Dr Paul Dale wrote:
>>     I'd support such a change.  Our stability policy won't without an exception.
>>
>>     There are a lot more things that could be moved out IMO.
>>
>>
>>     Pauli
>>
>>
>>     On 6/7/22 15:22, Benjamin Kaduk wrote:
>>>     On Sun, Jul 03, 2022 at 09:51:23PM +0200, Dmitry Belyavsky wrote:
>>>>     Dear colleagues,
>>>>
>>>>     With all respect to David's efforts - isn't it worth turning CMP into a
>>>>     separate library in OpenSSL (and probably into a separate repo)? I remember
>>>>     there was a separate PR in this direction.
>>>     I think I foundhttps://github.com/openssl/openssl/issues/16358  just now,
>>>     but maybe there are others.
>>>
>>>>     It looks like CMP heavily relies on libcrypto/libssl, but I'm not sure it
>>>>     requires an integration - and, last but not least, has its own life cycle.
>>>>     Several years ago this seemed a good rationale both to me and to the
>>>>     OpenSSL team to separate a GOST engine.
>>>     It looks like there was some discussion in
>>>     https://github.com/openssl/openssl/pull/6811  that suggests that having
>>>     apps/cmp.c functionality was a key motivation for pulling in everything to
>>>     libcrypto itself, but I'm not sure how far the conversation of in-OpenSSL
>>>     vs standalond project really went at that time.  I don't think I have
>>>     anything to add to that discussion other than what you say above.
>>>
>>>     -Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20220708/0b73a233/attachment-0001.htm>