The April 2017 Oracle CPU includes security issues in MySQL Workbench: http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html#AppendixMSQL The issues are fixed upstream in 6.3.9. Mageia 5 is likely also affected.
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
fixed in cauldron
CC: (none) => mageiaStatus: NEW => RESOLVEDResolution: (none) => FIXEDCVE: (none) => CVE-2016-2176, CVE-2017-3469, and CVE-2016-6303
Build failed in Cauldron. Are you sure Mageia 5 isn't affected?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
new version pushed in updates_testing src.rpm: mysql-workbench-6.3.9-1.mga5
Version: Cauldron => 5Assignee: pkg-bugs => qa-bugs
when it will build :)
Assignee: qa-bugs => mageia
Hopefully this will also fix bug 17192 . . but I am not holding my breath :(
CC: (none) => vbcoen
Build error: http://pkgsubmit.mageia.org/uploads/failure/5/core/updates_testing/20171229232127.luigiwalser.duvel.34556/log/mysql-workbench-6.3.9-1.mga5/build.0.20171229232213.log In file included from /home/iurt/rpmbuild/BUILD/mysql-workbench-community-6.3.9-src/library/base/boost_fix.cpp:21:0: /usr/include/boost/system/error_code.hpp:516:54: fatal error: boost/../libs/system/src/error_code.cpp: No such file or directory # include <boost/../libs/system/src/error_code.cpp> So it looks like it needs to be patched to build against the old boost in mga5.
Looking at: https://kea.isc.org/ticket/4009?cversion=0&cnum_hist=15 it sounds like this issue is with Boost 1.55 (which we have in Mageia 5) but Boost 1.56 fixed it.
I attempted to build Boost 1.56 on my mga5 machine just to see if mysql-workbench would build afterward but Boost itself won't build due to the following error. I don't know how to go about fixing this. It looks like there are a lot of things which use Boost so I don't know if this was a good idea anyway but I thought it would be useful to know if it fixed mysql-workbench. The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /home/mrambo/mageia_dev/dev5/boost/BUILD/boost_1_56_0 The following directory should be added to linker library paths: /home/mrambo/mageia_dev/dev5/boost/BUILD/boost_1_56_0/stage/lib + echo ============================= build Boost.Build ================== ============================= build Boost.Build ================== + cd tools/build/v2 + ./bootstrap.sh --with-toolset=gcc /home/mrambo/mageia_dev/dev5/boost/BUILDROOT/rpm-tmp.t7ynWE: line 46: ./bootstrap.sh: No such file or directory error: Bad exit status from /home/mrambo/mageia_dev/dev5/boost/BUILDROOT/rpm-tmp.t7ynWE (%build) RPM build errors: Bad exit status from /home/mrambo/mageia_dev/dev5/boost/BUILDROOT/rpm-tmp.t7ynWE (%build) error: failed!
CC: (none) => mrambo
We wouldn't be able to update boost, but it would be interesting to confirm that it builds against 1.56. It's too bad we skipped that version in Cauldron (probably due to the mga5 freeze cycle). Maybe the changes made to the SPEC for 1.58 would help you get it to build? http://svnweb.mageia.org/packages?view=revision&revision=858953 As for mysql-workbench, I wonder if there's some way to make sure it builds with BOOST_ERROR_CODE_HEADER_ONLY undefined.
IIRC the reason for skipping boost 1.56 was because of known issues with it, so it would have caused us more grief than gain...
CC: (none) => tmb
Looks like BOOST_ERROR_CODE_HEADER_ONLY is already undefined (commented out) in .../library/base/boost_fix.cpp. But it also doesn't look like it matters much because there is a BR for mysql-connector-c++-devel >= 1.1.8 which isn't available for mga5 anyway. Looks like neoclust tried to build it some months back but it isn't on any of the mirrors I checked. There is a src.rpm in updates_testing but no binary package. I'm surprised the -workbench build didn't fail on the missing dependency before it ever got to boost. Looks to me like this is not fixable for 5.
Are you sure? # is not a comment in C/C++, it's a macro. Anyway, yeah probably not fixable.
Status: REOPENED => RESOLVEDResolution: (none) => OLD
Documenting that we tried to add -UBOOST_ERROR_CODE_HEADER_ONLY to CXXFLAGS to fix the build problem but it made no difference. Same missing file error.