I'm ok with option 1 (but it will require a vote). I think the percentage of our user base that are using the existing API is sufficiently close to zero that we're not breaking our compatibility promises.
Matt On 27/07/2020 02:08, Dr Paul Dale wrote: > The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit > badly with the move to provider based infrastructure. > They are definitely being deprecated in master but without more, the > extra layer of indirection and additional complexity generating random > numbers will remain. > > The option I see are: > > 1. Remove, rather than deprecate, RAND_DRBG in 3.0. This is a breaking > change. > 2. Bypass RAND_DRBG and live with a breaking change (refer: > https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828) > 3. Leave things as they currently are in master. > > The first two are breaking changes and will require an OMC vote. > > > Some pertinent points: > > 1. RAND_bytes will continue to work as is — this API is perfect for > almost everyone. > 2. The RAND_METHOD functionality remains — this allows wholesale > replacement of OpenSSL’s RNGs if desired. > 3. The name EVP_RAND is the working name and might change — this is not > relevant to this discussion. > 4. The RAND_DRBG APIs are unlikely to be widely used — they were > introduced in 1.1.1. The two users I know of (Akamai and NCP) are both > fine with them being removed. > > > Thoughts anyone? > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia >
