[openssl-dev] Feedback on BIO API changes in 1.1

[Timothy B. Terriberry]

I recently attempted to convert libopusfile to the new 1.1 API changes 
(in response to this Debian bug report: 
<https://bugs.debian.org/828480>, if you want to see what broke).

I realize that this late in the release cycle, people are unlikely to 
want to make additional backwards-incompatible changes, but you may find 
some of this useful, nonetheless. Feel free to disregard it, also, as it 
is just one developer's opinion.

1) There is no accessor for the "num" field in the BIO struct.

This is typically used to store a file descriptor or similar value. As 
can be seen by its explicit access in BIO_dup_chain(), there may be 
legitimate reasons to get at its value, even if you are not writing your 
own new BIO implementation.

2) The API documentation for BIO_meth_new() says that "type" should be a 
unique integer, but provides no way to ensure this is true.

Particularly, when using this from a library, I have no way to ensure 
that some number I choose here does not conflict with that chosen by 
some other library in the same application, or with the application 
itself. Furthermore, the values used by OpenSSL for its own internal BIO 
implementations appear to have some structure which the code relies on, 
but which is not documented. Not really having any way to do what the 
documentation asks for, I've simply chosen to pass in BIO_TYPE_NULL, and 
live with the fact that anything that relies on this being unique (not 
much, that I can tell) will not work correctly.

3) I'm not sure the conversion of BIO_METHOD to an opaque struct is 
really a good idea. In prior versions of the library, anyone wanting to 
make their own BIO implementation would typically have a static table 
(which could not be const because the API did not take const pointers). 
OpenSSL itself does this for all of its BIO implementations (which are 
now fortunately const), and any difficulties you might see there in 
converting to use the new API apply equally well to external 
implementations.

If extensibility is really needed here, I think a better approach than 
arbitrarily changing the contents of this structure would be to simply 
define a new structure, BIO_METHOD2, or similar, and have new APIs to 
construct BIOs with these methods (or, for APIs which must handle any 
version, to have a "version" parameter to tell you which variety you 
have). This approach seems to make it much simpler to reason about what 
must be supported to ensure both backwards and forwards compatibility.