OpenSuSE has issued an advisory today (January 25): http://lists.opensuse.org/opensuse-updates/2016-01/msg00090.html We already fixed CVE-2015-6908. OpenSuSE patch for CVE-2015-4000 (LOGJAM) checked into Mageia 5 and Cauldron SVN to be included in the next update. Reproducible: Steps to Reproduce:
Patch came from this bug: https://bugzilla.suse.com/show_bug.cgi?id=937766
Assigning to packagers collectively, with the (mostly inactive AFAIK) maintainer in CC.
CC: (none) => bgmilneAssignee: bugsquad => pkg-bugs
There doesn't seem to have been an upstream issue logged by SUSE. I would prefer a patch vetted by upstream.
BTW., the upstream fix for this was applied to OpenLDAP master / 2.5 in Sept 2013 in ITS 7506 (http://www.openldap.org/its/index.cgi?findid=7506 ). But this hasn't been merged into the 2.4 release branch. The patch takes a slightly different approach (allowing DH parameters to be provided in a file, similar to as using something like this on Apache SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}" ) If using cn=config, this would be used like this: olcTLSDHParamFile: /path/to/dhparams.pem In the event of a DH parameters file not being configured, the code now uses a static 1024-bit DH parameter (apparently the DH parameter selection of the larger parameters was not working). So, without any configuration, the net effect will be the same, 1024-bit DH parameters, but configuration would actually allow the use of bigger DH parameters. I am trying to find out from upstream if there is a reason the changes merged into master haven't made it to the 2.4 release branch.
do you have new infos about this bug ?
CC: (none) => mageia
Don't worry about it. The patch is already in SVN, so it will be fixed if we have to issue another update for this package.
then this is on updates_testing with the other issue ? ( the one we need to fix the tests ;) )
I think it's obsoleted by the version update. If we fix the tests and issue the update we can mark this as fixed too.
Patch was removed in the update for Bug 21003. May or may not have been fixed upstream.
Resolution: (none) => OLDStatus: NEW => RESOLVED