> There is absolutely a place for an API like this -- but that place is not as a replacement for OpenSSL. I disagree. I think it is exactly the place for an Op

> There is absolutely a place for an API like this -- but that place is not as a replacement for OpenSSL. I disagree. I think it is exactly the place for an OpenSSL API replacement. As is alluded to in this link (thanks cremno) [1], they want a critical mass of users before it makes sense to deprecate the libssl API. Deprecation seems necessary in order to perform the serious cleanup/reimplementation under the hood that they would like to do. While new projects may have an easier time, they admit that adoption by existing projects is significant work. However, so many and large projects already exist that it seems that many of them need to be won over in order for a deprecation to be practical. Many existing projects (see other comments in this post) use this transport layer flexibility in the OpenSSL API, and not offering it with the new API may slow adoption. Yes, like you say another API layer could be added, and it is a deeply subjective matter so let's agree to disagree... But composability is so important and only becomes more so as we tire of wheel reinventions leading to unnecessary bugs. Enabling modularity and reuse needs 1st class API attention. Being able to easily plug this new API as a source/sink onto the myriad of existing (and yet to be created) I/O frameworks would be a major win. This is my $.02 and humble appeal to the people doing the fantastic work on this lib. My thanks to all of you! [1] https://marc.info/?l=openbsd-tech&m=141524972826918&w=2 https://marc.info/?l=openbsd-tech&m=141524972826918&w=2