A common workaround is to dynamically pull in OpenSSL at runtime. Have a context option that specifies the OpenSSL “.so” or “.dll” path and cache the required API inside a struct or similar.
— Steve-o On Tue, Dec 25, 2018 at 6:30 Luca Boccassi <[email protected]> wrote: > On Tue, 2018-12-25 at 00:53 +0100, 林宝龙 wrote: > > The problem of first option we met is that OpenSSL provides a lot > > configurable things, for example, trust group, external verification > > callback, etc. We must add more options to sockopt to have such > > things > > configurable. For the callback functions, if we continue using > > setsockopt, > > we need to cast function pointer to void pointer and vice versa, > > looks not > > good. > > As mentioned, there is really no alternative to continue supporting > bindings. Also, exposing a third party API/ABI again would mean that > the users would need to start worrying about OpenSSL's API/ABI changes, > and keep them in sync with the internal usage of the library. That > would not be maintainable. > > So it looks like there are both legal and implementation problems. So > let's take a step back: why is the current encryption/authentication > support via CURVE and GSSAPI not sufficient? What is lacking that you > need in your application? > > > About the licence issue, I'm not familiar with those licenses, and I > > have > > asked someone inside my company, got the answer that I can use > > OpenSSL in > > libzmq with an exception, I don't know how. He said that we will > > share the > > code out in the end, but can't contribute back to libzmq directly. > > Does it > > same as what you concern? Do you have more information that we must > > stop > > using OpenSSL inside libzmq? > > Yes an exception is needed as I said, but not just from you: from every > single copyright holder of libzmq, of which there are many. That's > because adding an exception to the license is a change in license, and > cannot legally be done unilaterally. > > Note that this is not only a problem for contributing code back, but > also for your application. You cannot distribute those changes to > anybody without a license change, which means you cannot give your > application to anybody without breaching the terms of the license, and > thus copyright law. > > > On Mon, 24 Dec 2018, 23:42 Luca Boccassi <[email protected] > > wrote: > > > > > On Mon, 24 Dec 2018, 23:03 林宝龙 <[email protected] wrote: > > > > > > > Hi, > > > > > > > > We are adding TLS support for ZeroMQ(based on 4.2.5). Product > > > > reason, we > > > > choosed OpenSSL as TLS library. > > > > > > > > Ask community for suggestions, which solution below is better? > > > > 1. Use TLS public certification, private key, etc as socket > > > > option (set > > > > through setsockopt), ZeroMQ manages the OpenSSL context, > > > > one OpenSSL > > > > context per socket_base_t object. > > > > 2. Use OpenSSL context as socket option(set through setsockopt), > > > > external > > > > application should provide the OpenSSL context, with public > > > > certification, > > > > private key, etc. set in context level, all ssl connections share > > > > the same > > > > configuration as the input OpenSSL context. > > > > > > > > At beginning we choosed the first solution, like curve, use > > > > public > > > > certification, private key as the socket option. But later on, we > > > > found the > > > > second solution that use external OpenSSL context can make the > > > > ZeroMQ code > > > > simpler, and more flexible, external application can configure > > > > the OpenSSL > > > > context without change the ZeroMQ socket options. > > > > > > > > Welcome your comments. > > > > > > > > Best regards, > > > > Baolong > > > > > > > > > > The first option would be better, exposing third party API and ABI > > > would > > > be a nightmare, especially for bindings. O > > > > > > But the most important issue is that the Openssl license is not > > > compatible > > > with libzmq, which is licensed under the lgpl3, so I'm afraid such > > > combination will not be legally distributable. At least not without > > > a > > > relicensing effort to add an exception - we are already trying that > > > to > > > change to mpl2 and are nowhere near done unfortunately. > > > > > > > _______________________________________________ > > > > > > zeromq-dev mailing list > > > [email protected] > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- > Kind regards, > Luca Boccassi_______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
