[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