>> I personally see no harm if these RNG objects are made available to >> applications that need/use them > > But decisions like this live forever. It is therefore VERY important to > spend time thinking about what > becomes part of the public API and what remains hidden so that we can change > things later when we > have a better understanding. No argument here, especially since I can’t claim to understand all the implications of exposing RNG (yet ;). But it is clear that at least some applications need to work with an RNG more closely than others, and would want more control over its behavior.
> This concept is new to OpenSSL :) :-) :-) > But we just put out a 1.1.0 release that made things opaque, so it’s more > fresh in the minds of at > least some of the dev team. In general, making things opaque is a good idea, RNG included. But: > Personally, since DRBG is new in 1.1.1 I would be quite happy if we didn’t > expose anything public > until the release after that. Even opaque objects usually have some public interface. I think exposing RAND_add_ex() would be a good idea for 1.1..1, and it’s likely to serve as an acceptable “live forever” API.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev