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
