[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