[openssl-project] Policy update

Salz, Rich rsalz at akamai.com
Wed Jan 3 19:57:21 UTC 2018


I am less concerned about adding datatypes than I am about adding algorithms and protocols.  It is hard for a user to make themselves less secure by configuring a datatype.

Do you have substantive issues with the decisions? I  agree the wording can be improved.

There is an action item (assigned to me, anyone should feel free to pick it up) to turn the policy declarations into a strawman mission statement.


On 12/22/17, 9:29 AM, "Kurt Roeckx" <kurt at roeckx.be> wrote:

    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
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project



More information about the openssl-project mailing list