[zeromq-dev] Relicensing completion and feature removal, need clean-room reimplementations of zmq_proxy_steerable() and ZMQ_RECONNECT_IVL_MAX

Luca Boccassi bluca at debian.org
Sun Jul 23 21:44:31 CEST 2023


On Wed, 7 Jun 2023 at 01:46, Luca Boccassi <bluca at debian.org> wrote:
>
> On Mon, 5 Jun 2023 at 12:49, Luca Boccassi <bluca at debian.org> wrote:
> >
> > Hi,
> >
> > As you might or might not be aware, we have been working hard for years
> > to complete the libzmq relicensing effort that Pieter started long ago,
> > from LGPL3+exceptions to standard MPL2:
> >
> > https://github.com/zeromq/libzmq/issues/2376
> >
> > After a lot of work, we are down to only 3 grants missing, covering the
> > following:
> >
> > - tweetnacl integration as alternative to libsodium (relicensing
> > NACKed)
> > - zmq_proxy_steerable() (no answer)
> > - ZMQ_RECONNECT_IVL_MAX (no answer)
> >
> > We have been waiting for years, with many requests without responses
> > for the latter two, and it doesn't make sense to wait anymore.
> >
> > So with this PR the above functionality will simply be removed:
> >
> > https://github.com/zeromq/libzmq/pull/4554
> >
> > I will merge it later today.
> >
> > Tweetnacl is really not a problem, it was always intended as a local-
> > only thing to facilitate zmq_curve development, which is long done. The
> > only supported production encryption implementation is libsodium, which
> > is available everywhere, so I do not intend to put tweetnacl
> > integration back. If anybody was using curve+tweetnacl in a production
> > setting, they were doing something _very_ wrong and need to stop asap
> > anyway. It's a footgun and it's best to be rid of it.
> >
> > The other two are more problematic, as they are public APIs. The PR
> > changes them to be empty stubs that return EOPNOTSUPP (so that ABI
> > doesn't change). But I will make at least an attempt to get a
> > reimplementation so:
> >
> > If you are able to, and you have NEVER LOOKED AT THE PREVIOUS
> > IMPLEMENTATIONS (I will require you to state this explicitly in the
> > commit messages), please consider helping out and reimplementing these
> > two APIs, based solely on the public documentation:
> >
> > http://api.zeromq.org/4-3:zmq-proxy-steerable
> > http://api.zeromq.org/4-3:zmq-setsockopt#:~:text=connection%2Doriented%20transports-,ZMQ_RECONNECT_IVL_MAX,-%3A%20Set%20maximum%20reconnection
> >
> > I cannot stress this enough, it must be a clean-room reimplementation
> > so no prior knowledge of the previous implementation details nor
> > looking at the previos implementation is allowed (hence why I cannot do
> > it myself).
> >
> > If you are able to help, please speak up. These are not difficult to
> > add, especially the socket option should be very straightforward. I
> > will of course be able to review and provide guidance.
> >
> > After merging the above PR I will complete the relicensing shortly
> > after, taking advantage of the switch to also use the standard SPDX
> > format in source files. The relicense grants will be moved to:
> > https://github.com/rlenferink/libzmq-relicense
> > for archival.
>
> ZMQ_RECONNECT_IVL_MAX has been contributed back by Stéphane Valès
> (thanks!). Any takers for zmq_proxy_steerable() ?

Reminder that zmq_proxy_steerable() is stil a stub and needs somebody
to contribute an independent reimplementation.


More information about the zeromq-dev mailing list