crypto: export externals to internal structs

[indutny]

Export External getters for a internal structs: SSL, SSL_CTX.

cc @tjfontaine , as discussed on nodeconf.

[indutny]

cc @trevnorris ;)

[indutny]

For those, who just came over it. I'm going to export some External wrapped pointers to internal fields, to make it easier for addon authors to interact with internal structs like SSL and SSL_CTX.

If you guys do need some other pointers - please comment here.

[bnoordhuis]

Why the indirect approach? There is no reference counting going on which is asking for use-after-free bugs. If the goal is to expose internals to native add-ons, then why not expose them directly through node.h?

[indutny]

@bnoordhuis because it is very easy? :)

On a more serious note: there are some classes like Connection and TLSWrap that share the base class, so the SSL couldn't really be extracted out of them without knowing the exact class that is being used.

Anyway, I'm open to suggestions and please paste some example methods if you a better idea ;)

[bnoordhuis]

Is the idea to expose the SSL and SSL_CTX pointers with TLSCallbacks::Wrap()-wrapped JS objects as the input? What about lifetimes? Is the caller allowed to borrow the references for longer periods of time? I think I'd start out conservative with something like:

Local<Object> js_tls_object = /* ... */;
{
  node::Borrow<SSL> ssl(js_tls_object);
  CHECK_NE(*ssl, NULL);
  do_something_with(*ssl);
}

It's not perfect but it makes it clear that the lifetime of the SSL* is tied to the lifetime of the Borrow object.

[indutny]

Hm... in such context - object will be alive anyway, even without on-stack guard, right?

Let's be honest about SSL, SSL_CTX. What I was thinking about - is providing some SSL_xxx methods in addons, that are currently not exposed in node_crypto.cc. All of them, do not really need the SSL to be retained. So, at least, with OpenSSL's handles - it is not a big deal to just assume that _external will be used immediately, and the people who will not want it to happen could always retain the object by keeping the reference manually.

Anyway, this is not a documented feature, and is mostly a way for some people to write useful addons without caring much about stable version API/ABI.

[trevnorris]

info.Holder().

[indutny]

Landed in 6e08bb9, ignoring most of the feedback. Thank you :)