Fedora has issued an advisory on April 25: https://lists.fedoraproject.org/pipermail/package-announce/2016-April/183129.html Mageia 5 is also affected.
Whiteboard: (none) => MGA5TOO
fixed in mga5. The following packages are now in updates_testing: apache-mod_nss-1.0.14-1.mga5.src.rpm apache-mod_nss-1.0.14-1.mga5.x86_64.rpm apache-mod_nss-debuginfo-1.0.14-1.mga5.x86_64.rpm and relelvant i586 packages,
Status: NEW => ASSIGNED
It didn't build in Cauldron, and as you're using autopatch also in Mageia 5, it's likely that the same patch that failed to apply in Cauldron also failed to apply in Mageia 5, but it silently continued. You should fix the patch and resubmit the build.
Whiteboard: MGA5TOO => MGA5TOO feedback
fixed. Assigning it to qa
Assignee: thomas => qa-bugs
You can use the following reference. Still marking as feedback for now as I don't see a rebuild in Mageia 5 on the build system. Advisory: ======================== Updated apache-mod_nss package fixes security vulnerability: Attempting to exclude ciphers from the list of accepted ciphers to use may not work as expected (CVE-2016-3099). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3099 https://lists.fedoraproject.org/pipermail/package-announce/2016-April/183129.html
Version: Cauldron => 5Whiteboard: MGA5TOO feedback => feedback
Thomas, please fix the failing patch and submit a rebuild for Mageia 5.
CC: (none) => thomas
The patch was fine in mga5, but I still changed it to %apply_patches, just in case we need to do another update.
Whiteboard: feedback => (none)
Both were upgraded to 1.0.14. How was the patch fine in Mageia 5 but not in Cauldron?
Well, it does appear fine. OK.
A rebuild was submitted, so it's now: apache-mod_nss-1.0.14-1.1.mga5 from apache-mod_nss-1.0.14-1.1.mga5.src.rpm
For testing see https://bugs.mageia.org/show_bug.cgi?id=11364#c3
Whiteboard: (none) => has_procedure
Before installing the update, had the prior version installed and https://127.0.0.1:8443/ working in firefox. After installing the update, httpd fails to start with ... httpd: Syntax error on line 54 of /etc/httpd/conf/httpd.conf: Syntax error on line 1 of /etc/httpd/conf/modules.d/10_mod_nss.conf: Cannot load modules/libmodnss.so into server: /etc/httpd/modules/libmodnss.so: cannot open shared object file: No such file or directory # ll /etc/httpd/modules/*nss* -rwxr-xr-x 1 root root 171752 Apr 27 21:04 /etc/httpd/modules/mod_nss.so* # cat /etc/httpd/conf/modules.d/10_mod_nss.conf LoadModule nss_module modules/libmodnss.so Before installing the update, that file has # cat /etc/httpd/conf/modules.d/10_mod_nss.conf LoadModule nss_module modules/mod_nss.so
CC: (none) => davidwhodginsWhiteboard: has_procedure => has_procedure feedback
You found a bug that has been introduced in the updated mod_nss.config.patch I need to fix this
This should be fixed now, and the following packages are now in updates_testing apache-mod_nss-1.0.14-1.2.mga5.src.rpm apache-mod_nss-1.0.14-1.2.mga5.x86_64.rpm apache-mod_nss-debuginfo-1.0.14-1.2.mga5.x86_64.rpm But please wait with testing, I will test them on my server first.
This isn't working in mga5, it does in cauldron. Needs some more work. Assigning back to maintainer
Assignee: qa-bugs => thomas
Please go ahead with testing. I did an upgrade on a vbox and it seems to work as expected. Assigning it back to QA
Whiteboard: has_procedure feedback => has_procedure
Testing mga5 64
Testing M5 x64 real h/w BEFORE update [remove mod_ssl} # urpme apache-mod_ssl tynnu apache-mod_ssl-2.4.10-16.3.mga5.x86_64 tynnu pecyn apache-mod_ssl-2.4.10-16.3.mga5.x86_64. 1/1: tynnu apache-mod_ssl-2.4.10-16.3.mga5.x86_64 [install mod_nss in its place] ############################################# # urpmi apache-mod_nss rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/5/x86_64/media/core/release/apache-mod_nss-1.0.8-28.mga5.x86_64.rpm gosod apache-mod_nss-1.0.8-28.mga5.x86_64.rpm o /var/cache/urpmi/rpms Paratoi... ############################################# 1/1: apache-mod_nss ############################################# apache-mod_nss certificate database generated. ---------------------------------------------------------------------- Rhagor o wybodaeth ar becyn apache-mod_nss-1.0.8-28.mga5.x86_64 NOTE: You may need to convert your existing ssl certs These links provide a good how-to: http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html http://directory.fedora.redhat.com/wiki/Mod_nss None of these links helped: http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html -> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html -> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS http://directory.fedora.redhat.com/wiki/Mod_nss -> nowhere So I left the certificates as they were. apache-mod_nss-1.0.8-28.mga5 # systemctl restart httpd.service # netstat -pant | grep 443 tcp6 0 0 :::8443 :::* LISTEN 25163/httpd Trying Opera 12 https://localhost:8443/ yielded a complaint about the certificate chain not being good. Allowing this for localhost led to the "It works!" page. Trying https://localhost:8443/ with Firefox yielded "Your connection is not safe". So it looks as if the certificates should be updated - but how? I prefer to tackle this before trying the update.
CC: (none) => lewyssmith
Testing complete mga5 64 Before ------ Start apache if not already running. # systemctl start httpd # systemctl status httpd â httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: active (running) ...etc Remove mod_ssl and install mod_nss # urpme apache-mod_ssl # urpmi apache-mod_nss mod_nss uses port 8443 by default so check it's listening with netstat.. # netstat -pant | grep httpd tcp6 0 0 :::80 :::* LISTEN 24065/httpd tcp6 0 0 :::8443 :::* LISTEN 24065/httpd There's a bit of an anomaly here as it shows tcp6 but not tcp. It's due to apache being configured simply to listen on a port rather than address & port. Connecting with IPv4 works ok though and shows a connection as it does so. See eg. https://unix.stackexchange.com/questions/152612/netstat-why-are-ipv4-daemons-listening-to-ports-listed-only-in-a-inet6 and https://httpd.apache.org/docs/2.0/bind.html#ipv6 # netstat -pant | grep httpd tcp6 0 0 :::80 :::* LISTEN 24065/httpd tcp6 0 0 :::8443 :::* LISTEN 24065/httpd tcp6 0 0 192.168.0.10:8443 192.168.0.11:55278 ESTABLISHED 24070/httpd After ----- Checked httpd was restarted # tail /var/log/httpd/error_log It does show a warning but before the update it shows certificate errors, as expected from the README.urpmi [:warn] [pid 24971] NSSSessionCacheTimeout is deprecated. Ignoring. Appears to be this https://bugzilla.redhat.com/show_bug.cgi?id=1257662 Apache is restarted OK though and https connections port 8443 are still working. Systemctl status httpd also shows it in use.
Whiteboard: has_procedure => has_procedure mga5-64-ok
I don't know what the package meant by you may need to convert the certificate when you installed it, but as for Opera and Firefox's complaints, they will always do that for self-signed certificates the first time they see them. Once you tell them to accept the cert, they won't complain anymore. The other way around that is to make your own local CA cert, use that to generate and sign the web server certs, and then configure your browser to accept your CA cert. I do that at work, but obviously that's way more involved than what you need to do to test an update :o)
Keywords: (none) => validated_updateWhiteboard: has_procedure mga5-64-ok => has_procedure advisory mga5-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0197.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED