<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 07.07.22 23:02, Tim Hudson wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CAHEJ-S6F7nUVAVZGU=2AbgEQzswNQg75sTY4UQ-meg+jSG1EAg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>I do not think this makes sense at this stage at all. <br>
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.</div>
</div>
</blockquote>
<p>I fully agree.</p>
<p>To avoid any misunderstandings on what I wrote before:<br>
My proposal (possibly in difference to Dmitry's) was and still is
<b>not</b> to move any functionality out of the OpenSSL main
repository,<br>
but to re-arrange the library structure (likely by splitting <font
face="Courier New, Courier, monospace">libcrypto</font> into two
or more libraries) to better reflect the code layering.</p>
<p>Expected benefits:<br>
</p>
<ul>
<li>improve clarity of the software component structure</li>
<li>slightly alleviate development and maintenance</li>
<li>reduce binary code footprint in case just the crypto core or
just TLS (including crypto) is needed</li>
</ul>
<p>Expected drawbacks:</p>
<ul>
<li>any re-structuring requires more or less work<br>
</li>
<li>some so far internal crypto interfaces that are used by the
more application-level code need to be exported</li>
<li>applications that also require the more high-level
capabilities will need to link with more libraries</li>
</ul>
<p>We may also consider splitting the existing <font face="Courier
New, Courier, monospace">libcrypto</font> just virtually, e.g.,
into two code directories (say, <font face="Courier New, Courier,
monospace">crypto/</font> and <font face="Courier New, Courier,
monospace">crypto/apps/</font>, which includes CMS, CMP, OCSP,
HTTP, TS, etc.)<br>
plus an actual library (say, <font face="Courier New, Courier,
monospace">libapps</font>) 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) <font face="Courier
New, Courier, monospace">apps/lib/</font>.<br>
This likely would provide a better pros/cons ratio than actually
splitting up <font face="Courier New, Courier, monospace">libcrypto</font>.<br>
<br>
</p>
<blockquote type="cite"
cite="mid:CAHEJ-S6F7nUVAVZGU=2AbgEQzswNQg75sTY4UQ-meg+jSG1EAg@mail.gmail.com">
<div dir="auto">
<div>
<div dir="auto">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).<br>
</div>
</div>
</div>
</blockquote>
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.<br>
In particular, as Tomas wrote, the <font face="Courier New,
Courier, monospace">openssl</font> app will continue to provide
everything that it did before.<br>
<br>
<p> David</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAHEJ-S6F7nUVAVZGU=2AbgEQzswNQg75sTY4UQ-meg+jSG1EAg@mail.gmail.com">
<div dir="auto">
<div>On Thu, 7 July 2022, 18:48 Tomas Mraz, <<a
href="mailto:tomas@openssl.org" moz-do-not-send="true"
class="moz-txt-link-freetext">tomas@openssl.org</a>>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">OpenSSL
Project list should be used instead of the committers list
for<br>
such discussions.<br>
<br>
I do not think it would be good idea to do any such
splitting before a<br>
major release development is being started (i.e., 4.0).<br>
<br>
The openssl application could depend on that application
library(ies).<br>
<br>
Tomas<br>
<br>
On Wed, 2022-07-06 at 09:32 +0200, David von Oheimb wrote:<br>
<blockquote type="cite">Yes, there are number of
components that should better be moved out of the core
crypto library into a more application-level one.<br>
As I wrote three days ago, though my email got stuck in
mailing list moderation:<br>
<br>
-------- Forwarded Message --------<br>
Subject: Re: CMP is a subproject?<br>
Date: Sun, 3 Jul 2022 22:50:06 +0200<br>
From: David von Oheimb
<a class="moz-txt-link-rfc2396E" href="mailto:David.von.Oheimb@siemens.com"><David.von.Oheimb@siemens.com></a><br>
To: Dmitry Belyavsky <a class="moz-txt-link-rfc2396E" href="mailto:beldmit@gmail.com"><beldmit@gmail.com></a>, List
of openssl committers
<a class="moz-txt-link-rfc2396E" href="mailto:openssl-committers@openssl.org"><openssl-committers@openssl.org></a><br>
<br>
Dear all,
<p>thanks Dmitry for sharing this thought.<br>
In a sense it is an instance of a more general
suggestion I gave<br>
</p>
<ul>
<li>back in 2017: <a
href="https://github.com/openssl/openssl/pull/4992">Introducing
an application-level library for the CLI and
OpenSSL-based applications #4992 </a></li>
<li>and in 2020: <a
href="https://github.com/openssl/openssl/issues/13440">Improve
overall OpenSSL library structure #13440</a> <br>
</li>
</ul>
<p>which pertains also to CMS, HTTP, OCSP, TS, and maybe
further more application-level component(s) of
libcrypto like CT.<br>
</p>
<p>The CMP implementation does not rely on libssl, but
it does heavily rely on libcrypto and relies on some
of its internals.<br>
The same holds for HTTP, and likely this also holds
for CMS, OCSP, TS, and CT.<br>
</p>
David</blockquote>
<blockquote type="cite">
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 06.07.22 07:25, Dr Paul
Dale wrote:<br>
</div>
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Sun, Jul 03, 2022 at 09:51:23PM +0200, Dmitry Belyavsky wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think I found <a class="moz-txt-link-freetext" href="https://github.com/openssl/openssl/issues/16358">https://github.com/openssl/openssl/issues/16358</a> just now,
but maybe there are others.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">It looks like there was some discussion in
<a class="moz-txt-link-freetext" href="https://github.com/openssl/openssl/pull/6811">https://github.com/openssl/openssl/pull/6811</a> 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
</pre>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>