CMP is a subproject?

[Tim Hudson]

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.

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

Tim.


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
> >  * and in 2020:  Improve overall OpenSSL library structure #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 found https://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
> > > >
>
> --
> Tomáš Mráz, OpenSSL
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20220708/ce59cbf3/attachment.htm>