Similar reason as curve, the product environment doesn't have gnutls installed, new security library need to be installed if choose gnutls.
Best regards, Baolong On Tue, 25 Dec 2018, 23:37 Luca Boccassi <[email protected] wrote: > Note that as an alternative to openssl there's gnutls which is lgpl2+ and > thus is compatible - but only for dynamic linking, proprietary applications > statically linking to libzmq thanks to it's exception will not be able to > statically link to gnutls. > > On Tue, 25 Dec 2018, 21:13 Luca Boccassi <[email protected] wrote: > >> On Tue, 2018-12-25 at 21:05 +0100, 林宝龙 wrote: >> > I suggested to use curve directly, but as a hole system, they didn't >> > want >> > to have two key management system, TLS was there which was used by >> > other >> > node. And another reason they gave to me is the curve was not been >> > used so >> > much by big companies compare to TLS, even it's simple than TLS. >> > Further >> > more the running environment has already had OpenSSL installed, use >> > openssl >> > can lower the security libraries maintenance. >> >> First of all curve was created by expert cryptographers, and it's >> extensively used, so it's not really a problem. The crypto primitives >> are provides by libsodium, which again is a very high quality library >> and used by many, many applications and libraries, and will most likely >> be already installed everywhere. >> >> Regarding key management, are you aware that there's the ZAP protocol? >> You can use it to implement the key management scheme you prefer, >> programmatically. For example, you could map 1:1 from SSL keys to curve >> keys internally. >> >> > About the license problem, as you explained to me, it is a big >> > problem, I >> > saw there is an issue which was registered 2 years ago to change the >> > libzmq's license, but it is not coming to end. I'll check with my >> > colleagues how to make the license issue gone? Come back to you when >> > I >> > have more information. >> >> Again - you *cannot* make the license issue go away. We have been >> trying to relicense to MPL2 for years, it will take years to finish, if >> ever. This is not something that can be worked around or "hacked". It's >> a legal issue. >> >> > Best regards, >> > Baolong >> > >> > On Tue, 25 Dec 2018, 12:31 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 >> >> -- >> 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
