In a lot of cases (mbtls) just don't link statically and the license issue is moot. But linking dynamically is preferred for more issues than license.
I think there are a few things here to consider, and forgive me if I get the jargon wrong. There are other people here that are the experts. If you can use the OS implementation you can use their store, be ensured that the most recent security updates have been applied and a well optimized solution. (ok some of that may be up for debate, they have security updates becasue they are most attacked.) In some countries, even on windows, you just cannot legally use OpenSSL. So ability to swap it out is really good. Some devices do not play nice and you really need to talk to them with an implementation they can work with (ie axis cameras vs ACTi cameras) If we write code into ZMQ that depends on a particular TLS implementation, we have done it wrong! On Wed, Dec 26, 2018 at 10:11 AM Luca Boccassi <luca.bocca...@gmail.com> wrote: > There's also NSS from Mozilla which is under MPL and thus compatible, > and does not introduce any restriction on third party code. > > There are then other less-known alternatives like wolfssl, mbed ssl or > matrixssl which are all gpl2+ so cannot be used by proprietary products > or static builds. But they all have commercial licenses available, so > it can be used by your company for their product if they buy the > license. > > On Tue, 2018-12-25 at 23:35 +0100, Luca Boccassi 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 <luca.bocca...@gmail.com > > 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 <luca.bocca...@gmail.com > > > > 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 <luca.boccassi@gmail > > > > > > .com > > > > > > wrote: > > > > > > > > > > > > > On Mon, 24 Dec 2018, 23:03 林宝龙 <lbl52...@gmail.com 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 > > > > > > > zeromq-dev@lists.zeromq.org > > > > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > zeromq-dev mailing list > > > > > > zeromq-dev@lists.zeromq.org > > > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > -- > > > > > Kind regards, > > > > > Luca Boccassi_______________________________________________ > > > > > zeromq-dev mailing list > > > > > zeromq-dev@lists.zeromq.org > > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > > > > _______________________________________________ > > > > zeromq-dev mailing list > > > > zeromq-dev@lists.zeromq.org > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > -- > > > Kind regards, > > > Luca Boccassi > > -- > Kind regards, > Luca Boccassi_______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
