[openssl-project] [openssl-dev] Blog post; changing in email, crypto policy, etc

[Andy Polyakov]

> ➢     Let me rephrase. "It's another thing to *purposefully* introduce options
>     known to be insecure by the time of introduction."
> 
> Yes run-time and compile-time is something to keep in mind.
> 
> We do not plan to introduce any insecure options that are enabled by default.  Option refers to compile-time and build-time both.  But I’ve been in this field for a long time, and I don’t think we can guarantee that it will not happen.  For example, the extra-entropy extension, the DualEC DRBG, etc.
> 
> Ok?

Sorry, but no, not OK. "Do not *plan*"? Doesn't it imply "plans can
change"? So it *is* open question. Really? It should be "we shall
*refuse* to *implement* an insecure option(*)". Period. As for things
that can happen. Yes, there is no guarantee that something like DualEC
can't happen in future, *but* then it may not be *intentional* on our
side. I mean we may fail to recognize new option as insecure, but it's
not OK to implement one that is already recognized as insecure. Allow me
to add this. If the said plans, specifically in respect to implementing
options already recognized as insecure, change and get realized, I'll
have to refuse to participate in the endeavour.

(*) As already mentioned, in the context "option" is rather "code" than
just "config-time flag". And once again, *legacy* cases are different,
because the *choice* is between *removal* of existing code, and making
compilation conditional. Different from *adding* code that is.