Netty has a security issue fixed upstream in 4.0.37: https://nvd.nist.gov/vuln/detail/CVE-2016-4970
Fixed for mga6 updating to 4.0.42! Note also that I have to updated jctools too!
CC: (none) => geiger.david68210
Advisory: ======================== Updated netty packages fix security vulnerability: handler/ssl/OpenSslEngine.java in Netty before 4.0.37.Final allows remote attackers to cause a denial of service (infinite loop) (CVE-2016-4970). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4970 https://nvd.nist.gov/vuln/detail/CVE-2016-4970 ======================== Updated packages in core/updates_testing: ======================== jctools-1.2.1-1.mga6 jctools-experimental-1.2.1-1.mga6 jctools-javadoc-1.2.1-1.mga6 jctools-parent-1.2.1-1.mga6 netty-4.0.42-1.mga6 netty-javadoc-4.0.42-1.mga6 from SRPMS: jctools-1.2.1-1.mga6.src.rpm netty-4.0.42-1.mga6.src.rpm
Assignee: java => qa-bugs
MGA6-32 MATE on IBM Thinkpad R50e No installation issues. I have been googling around to find a simple explanation or test case, but this seems all network development stuff. Giving up, at least it is a clean install and does not seem to bother anything else. Leaving OK'ing to the higher powers in QA.
CC: (none) => herman.viaene
x86_64 Have to agree with Herman; there is not much we could do with this without familiarity with java programming. There is a guide to writing a netty server and client at https://www.baeldung.com/netty which does require more than a passing acquaintance with development in java. The code samples are available on GitHub including a pom.xml but cannot see anything about deployment. Several applications or packages seem to refer to it; e.g. artemis cxf hadoop hornetq infinispan ironjacamar jetty jython mongo-java picketbox resteasy wildfly Updated the six packages. Installed wildfly, which hauled in 259 packages and took half an hour. At the end: Warning: Problems encountered when activating services. Please check and enable manually if necessary. Service units affected: wildfly.service.service Probably something needing to be set up beforehand, and there were three failed package installations in all that - the network was choked several times - possibly at the mirror end. Or there could be a typo in the installation script. .service.service? $ sudo systemctl enable wildfly Created symlink /etc/systemd/system/multi-user.target.wants/wildfly.service → /usr/lib/systemd/system/wildfly.service. $ sudo systemctl start wildfly.service $ systemctl status wildfly.service ● wildfly.service - The WildFly Application Server Loaded: loaded (/usr/lib/systemd/system/wildfly.service; enabled; vendor pres Active: failed (Result: exit-code) since Tue 2018-12-18 21:00:24 GMT; 30s ago Process: 21997 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDF Main PID: 21997 (code=exited, status=1/FAILURE) It was a longshot. So we shall go with Herman's assessment. Clean install - 64-bit OK.
CC: (none) => tarazed25Whiteboard: (none) => MGA6-64-OK
Validating on the basis of 'good update'. Advisory from comment 2.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0485.html
Status: NEW => RESOLVEDResolution: (none) => FIXED