Sure, I'll take a look at curl, according it's document curl supports several TLS libraries, but the curl's license is different with libzmq.
On Tue, 25 Dec 2018, 03:31 Jeff Shanab <[email protected] wrote: > Do not tie yourself to OpenSSL. There are export restrictions! Please take > a look at how culr abstracts the TLS implementationa nd allows us to swap > in mbedtls for example. > > On Mon, Dec 24, 2018 at 6:53 PM 林宝龙 <[email protected]> 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. >> >> 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? >> >> >> 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 >> > _______________________________________________ > 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
