[openssl-project] Policy update

[Richard Levitte]

In message <20171222142850.GA23195 at roeckx.be> on Fri, 22 Dec 2017 15:28:50 +0100, Kurt Roeckx <kurt at roeckx.be> said:

kurt> Hi,
kurt> 
kurt> During our face 2 face meeting last week we talked about the
kurt> direction we want to move in, and the policy we'll use to get
kurt> there. This are the current proposals:
kurt> - Insecure configuration options shall not be enabled by default;
kurt>   they must be enabled by a compile-time switch. This applies to all
kurt>   new contributions and existing code should be addressed at the
kurt>   next major (1.2.0) release.
kurt> - All new algorithms must be disableable at compile-time. With the
kurt>   exception of known not-to-work when disabled RSA SHA1 MD5 AES,
kurt>   existing code should be addressed at the next major (1.2.0)
kurt>   release. (PR’s to fix those welcome).
kurt> - All algorithms and protocols should be recognized by a national or
kurt>   international standards body. This applies to all new
kurt>   contributions and existing code should be addressed at the next
kurt>   major (1.2.0) release.
kurt> - The EVP interface should be the primary interface for calling
kurt>   crypto operations. All new contributions should only export this
kurt>   API and existing code should be addressed at the next major
kurt>   (1.2.0) release, and might include a compatibility layer.
kurt> 
kurt> I think at least the wording could be improved. For instance, it
kurt> says "All [new] algorithms and protocols must be disableable". I
kurt> assume it means cryptographic algorithms, like AES, SHA2, HMAC, ...
kurt> Does something like CMS and X509 fall under that? It doesn't sound
kurt> like an algorithm to me, and protocol also doesn't seem like the
kurt> correct word. The same goes for the "All algorithms and protocols
kurt> should be [standardised]".

I would expect CMS and X509 to fall under the categories "formats" and
"protocols", not "algorithms".  It *is* unfortunate that crypto/ is
such a hodge podge of different things, it really does confuse
matters, and I hope we can do some work to separate those things for
1.2.0, at least in different top directories (not necessarely in
different libraries, though)...

kurt> On a related topic, I think there has been a suggestion that we
kurt> should work on not exposing such compile time options in the
kurt> public headers but that applications should do runtime detection
kurt> of the available features instead.

I've a dream (long standing, I think I expressed it as early as 2003)
of having all algos as plugins, so the presence of an algo would be
defined as the presence of that DSO rather than the present of a
macro.  That would also make it much easier for the local admin to
tune algo availability more dynamically instead of having to rebuild.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/