And this is a very good answer. Perhaps this guidance deserves being documented
somewhere besides this mailing list? Something along the lines of
It is documented in the RAND_add manpage.
➢ I’m not sure I agree here. What effort are you talking about? In order to
select an order in which available sources are queried, the developers had to
think (hopefully :). Those thought could be documented in a few lines of text.
And what would be the point? Why should someone trust the documentation, which
can get out of date, more than the source?
➢ So while the team clearly has the right to make changes (especially
before the interface became public ;), but I’d rather that such changes are
guided by an informed consent from the public (such as yours truly ;).
We aren’t cutting off any avenues of participation. Email discussion and pull
requests are always welcome. But yes, the barrier to useful participation is
that someone has to first read and understand the source.
➢ I think it is *imperative* for a user to be able to RAND_add() to the DRBG
that gnerates private keys. I cannot emphasize enough how critical this is.
I am curious to know your justification for this. It seems to me that if
you accept the DRBG document, which we do, then the way we do the seeding is
fine. If you don’t accept the document, then modify the source.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
