[openssl-project] Policy update
Kurt Roeckx
kurt at roeckx.be
Fri Dec 22 14:28:50 UTC 2017
Hi,
During our face 2 face meeting last week we talked about the
direction we want to move in, and the policy we'll use to get
there. This are the current proposals:
- Insecure configuration options shall not be enabled by default;
they must be enabled by a compile-time switch. This applies to all
new contributions and existing code should be addressed at the
next major (1.2.0) release.
- All new algorithms must be disableable at compile-time. With the
exception of known not-to-work when disabled RSA SHA1 MD5 AES,
existing code should be addressed at the next major (1.2.0)
release. (PR’s to fix those welcome).
- All algorithms and protocols should be recognized by a national or
international standards body. This applies to all new
contributions and existing code should be addressed at the next
major (1.2.0) release.
- The EVP interface should be the primary interface for calling
crypto operations. All new contributions should only export this
API and existing code should be addressed at the next major
(1.2.0) release, and might include a compatibility layer.
I think at least the wording could be improved. For instance, it
says "All [new] algorithms and protocols must be disableable". I
assume it means cryptographic algorithms, like AES, SHA2, HMAC, ...
Does something like CMS and X509 fall under that? It doesn't sound
like an algorithm to me, and protocol also doesn't seem like the
correct word. The same goes for the "All algorithms and protocols
should be [standardised]".
On a related topic, I think there has been a suggestion that we
should work on not exposing such compile time options in the
public headers but that applications should do runtime detection
of the available features instead.
Kurt
More information about the openssl-project
mailing list