Please update to the latest version. Among other things, it adds a new CMake file that is necessary for packages I wish to build. It doesn't look like anitya is filing any bugs about this, since this package is mapped to zeromq41 [1], but looking at zeromq [2] there are several releases of the 4.2 line that have been made. Since upstream claims 4.2 is ABI compatible with 4.1, I'm not really sure why zeromq41 monitoring even exists. [1] https://release-monitoring.org/project/5681/ [2] https://release-monitoring.org/project/16245/
It may be necessary to split this into libzmq and cppzmq now.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
TLDR: ZeroMQ 4.2.3 fixes an important security vulnerability in client authentication. I'd like to register my concurrence with the need to upgrade to at least version 4.2.3. ZeroMQ 4.2.3 adds support for requiring access to a ZAP authentication server in order to allow communication to new connecting clients. Authentication is basically worthless in versions earlier than 4.2.3 because it effectively defaults to allowing unauthenticated users if the authentication server is not available at any point in the client connection process. I really need this update for a project that requires authentication, so I'm willing to help this process along in any way I can be helpful.
In my case, I need 4.2.3 in RHEL and CentOS 7.
(In reply to Elliott Sales de Andrade from comment #0) > Please update to the latest version. Among other things, it adds a new CMake > file that is necessary for packages I wish to build. Does this mean that it needs to be build with CMake now to properly install it as well? I don't seem to get it build properly with CMake over here... :/ (In reply to Elliott Sales de Andrade from comment #1) > It may be necessary to split this into libzmq and cppzmq now. I agree as cppzmq seems to have releases now: https://github.com/zeromq/cppzmq/releases Not sure when I find time for adding this as a new package though. Any help here is appreciated.
I'm not sure about that. Over upstream, they have some weird preconception that distro packages must be built with autotools [1] and they need CMake for Windows, so they don't want to deprecate either one. Their OBS-built RPMs are indeed built by autotools. Over on conda-forge [2], they cheat and build autotools, then prepare some kind of frankenbuild for CMake and only grab the .cmake files. [1] https://github.com/zeromq/libzmq/issues/2887 [2] https://github.com/conda-forge/zeromq-feedstock/blob/master/recipe/build.sh
See also conda-forge discussion: https://github.com/conda-forge/zeromq-feedstock/issues/25
<upstream maintainer hat on> Hi, if you update to a 4.2.0+ version, please either go straight to 4.3.1 or pick a patch to fix the following remote execution vulnerability: https://github.com/zeromq/libzmq/issues/3351 You can find backports for various intermediate versions at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919098 https://bugs.launchpad.net/suse/+source/zeromq/+bug/1811531 https://bugzilla.opensuse.org/show_bug.cgi?id=1121717 (In reply to Thomas Spura from comment #5) > (In reply to Elliott Sales de Andrade from comment #0) > > Please update to the latest version. Among other things, it adds a new CMake > > file that is necessary for packages I wish to build. > > Does this mean that it needs to be build with CMake now to properly install > it as well? I don't seem to get it build properly with CMake over here... :/ Please note that on *nix the pkg-config file should be all that any reverse dependency needs to build against zeromq, nothing else. So it should not be necessary to change to CMake, although everyone is of course welcome to pick the build system they prefer. ABI version management, which used to be in a bad shape with CMake, should be fine with the latest versions of zeromq. > (In reply to Elliott Sales de Andrade from comment #1) > > It may be necessary to split this into libzmq and cppzmq now. > > I agree as cppzmq seems to have releases now: > https://github.com/zeromq/cppzmq/releases > > Not sure when I find time for adding this as a new package though. Any help > here is appreciated. Note that Debian/Ubuntu still keeps that C++ header in the same package. Although it's been having releases tagged and a CMake system added, it's really mostly for the benefit of Windows users, and it's still a simple header that maintains backward compatibility (and no strict relation to specific zeromq versions). So simply chucking it into /usr/include will keep working as before. Again up to individuals and maintainers for what they prefer, just adding additional information in case it can be useful. Thanks everybody for the work for zeromq on Fedora!
Thanks for the heads up; I see no reason not to go straight to the latest version. A scratch build seems to have gone without a hitch: https://koji.fedoraproject.org/koji/taskinfo?taskID=32178997 I will probably have to check other packages a little bit. I think the downstream packages I'm interested in now use pkg-config if available, so hacking on a CMake file is probably not required anymore.
Oh, but it appears they still use the CMake file for cppzmq. I don't really want to put the full build in here, so I'll try to work on a separate package.
Note that cppzmq is just 2 headers, it doesn't need any building or any flag. In Debian and Ubuntu we just drop them in use/include as part of the libzmq devel PKG. Up to you of course. Thanks!
Yea, but downstream projects like QuantStack/xeus look for the CMake file, so we still need to provide it.
I've created a PR for the update and disabling of cppzmq-devel [1], and a review request for the split-out cppzmq at bug 1668271. I've also opened a PR to update czmq [2]. I made a copr [3] and rebuilt everything that requires these packages. All but two packages rebuild fine (though they shouldn't even need to since ABI shouldn't have changed). zeromq-ada is broken on 32-bit build due to missing dependencies, and the czmq failure appears to be something wrong with copr. It doesn't fail on koji with current zeromq, and it doesn't fail in mock with an updated zeromq. (Note, ignition-transport requires a fix in openpgm as well [4] if you want to rebuild it). [1] https://src.fedoraproject.org/rpms/zeromq/pull-request/2 [2] https://src.fedoraproject.org/rpms/czmq/pull-request/1 [3] https://copr.fedorainfracloud.org/coprs/qulogic/zeromq/monitor/ [4] https://src.fedoraproject.org/rpms/openpgm/pull-request/2
So, does anyone want to review bug 1668271? My PRs were merged before the mass rebuild, so technically there's no builder of cppzmq in Rawhide now.
As it turns out, there appeared to be a random failure of tests/test_inproc_connect on x86_64 [1], so it never was updated. Unfortunately, there is no backtrace printed out or in the test-suite.log. I've submitted another build and hopefully it will be fine this time. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=32852518