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
