Stunnel is not a community project, does it mean that commercial use and new requirement must contact the owner of the stunnel?
Best regards, Baolong On Sat, 29 Dec 2018, 00:55 Mark Botner <[email protected] wrote: > I can confirm that ZeroMQ + Stunnel works extremely well. Stunnel is very > robust - I'm using it to transfer many gigabytes / day over a 0MQ pub/sub > connection and have been doing so now for almost 2 years continuously. > > > Mark > > On Fri, Dec 28, 2018 at 2:50 PM Trevor Bernard <[email protected]> > wrote: > >> Why not just use stunnel as a TLS wrapper and avoid having to modify >> the zeromq code base? You are free to use OpenSSL, you don't need >> another key management system that can handle the Curve25519 elliptic >> curve. Configuration is likely easier than adding TLS support in >> ZeroMQ. >> >> On Wed, Dec 26, 2018 at 5:36 PM Jeff Shanab <[email protected]> wrote: >> > >> > 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 <[email protected]> >> 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 <[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 <luca.boccassi@gmail >> >> > > > > > .com >> >> > > > > > 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 >> >> >> >> -- >> >> 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 >> _______________________________________________ >> 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
