Debian has issued an advisory on July 2: http://www.debian.org/security/2012/dsa-2506 I updated the package to 2.6.6 in Cauldron which fixes it, and added the patch in SVN for Mageia 2. Something is broken in Cauldron and it won't build (builds fine locally).
CC: (none) => guillomovitchWhiteboard: (none) => MGA2TOO
CC: (none) => dlucio
can you post the build failure link?
CC: (none) => alien
Fails early in the process during autotools. Trying to build patched version: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120703204008.luigiwalser.valstar.32609/log/apache-mod_security-2.6.3-4.mga3/build.0.20120703204020.log Trying to build updated version: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20120703204820.luigiwalser.valstar.723/log/apache-mod_security-2.6.6-1.mga3/build.0.20120703204834.log Same error both times. The last time this package was built wasn't too awful long before mga2 came out, so I suspect it still builds there. I didn't actually try it on mga2 when I was working on it yesterday, but it does build fine on mga1.
i suspect this is some kind of updated autotools for what is building this. since guillomovitch didn't have any issue and this autotools thing is definately something unrelated. perhaps ask sysadmin team to look into this... either that, or autotools was updated and had new features...
this is probably due to newer autotools which requires that missing section. in any case, you should try to build the patch for mga2 and submit this to updates_testing, that's the more important fix. then just add that missing macro it's complaining about.
i think submitting to update testing on mga2 takes priority, but cauldron is unstable, therefor it's normal for it to take time to fix. in any case, i think just adding the AC_LANG_SOURCE and possible AM_PROG_AR macro in configure.ac or configure.in will do wonders for this... see also http://www.flameeyes.eu/autotools-mythbuster/forwardporting/autoconf.html
regenerating the build system without explicit reason seems overkill here, I just fixed the cauldron package.
Thanks Guillaume. Pushed to the build system in Cauldron and Mageia 2. Advisory: ======================== Updated apache-mod_security package fixes security vulnerability: Qualys Vulnerability & Malware Research Labs discovered a vulnerability in ModSecurity, a security module for the Apache webserver. In situations where both "Content:Disposition: attachment" and "Content-Type: multipart" were present in HTTP headers, the vulnerability could allow an attacker to bypass policy and execute cross-site script (XSS) attacks through properly crafted HTML documents (CVE-2012-2751). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2751 http://www.debian.org/security/2012/dsa-2506 ======================== Updated packages in core/updates_testing: ======================== apache-mod_security-2.6.3-3.1.mga2 mlogc-2.6.3-3.1.mga2 from apache-mod_security-2.6.3-3.1.mga2.src.rpm
Version: Cauldron => 2Assignee: bugsquad => qa-bugsWhiteboard: MGA2TOO => (none)
apache-mod_security should have a requires on perl-GnuPG as /usr/sbin/rules-updater.pl will not run without it. I'm looking through http://www.modsecurity.org/documentation/ to try and figure out how to test this one properly. Does this apply to Mageia 1 as well?
CC: (none) => davidwhodgins
It's not packaged for Mageia 1 :o)
(In reply to comment #8) > apache-mod_security should have a requires on perl-GnuPG as > /usr/sbin/rules-updater.pl will not run without it. well, i see no problem with someone adding this requires (it looks required to my untrained eye). but if no packager does the work, let's not wait too long without validating it, for that reason. can i ask what will be tested for validation? is there a reproducer method for the vulnerability itself? or are you just trying to run it and looking for regressions? (or both).
As we always have done AL13N: https://wiki.mageia.org/en/QA_process_for_validating_updates
Requires added. It was missed by the autoreq script because it was pulled in inside of an eval statement. I guess perl-GnuPG will require linking. Advisory: ======================== Updated apache-mod_security package fixes security vulnerability: Qualys Vulnerability & Malware Research Labs discovered a vulnerability in ModSecurity, a security module for the Apache webserver. In situations where both "Content:Disposition: attachment" and "Content-Type: multipart" were present in HTTP headers, the vulnerability could allow an attacker to bypass policy and execute cross-site script (XSS) attacks through properly crafted HTML documents (CVE-2012-2751). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2751 http://www.debian.org/security/2012/dsa-2506 ======================== Updated packages in core/updates_testing: ======================== apache-mod_security-2.6.3-3.2.mga2 mlogc-2.6.3-3.2.mga2 from apache-mod_security-2.6.3-3.2.mga2.src.rpm
The missing requires wouldn't have blocked the update, as it's not a regression, the program will generate a message if it isn't installed, and the program that uses it requires configuration before it can be run anyway, and appears to be optional to use. I would have opened a new bug report for the requires, if it wasn't added. There is no POC for the bug, so I'm just trying to figure out how to test it to confirm it's actually working.
ok, awesome. Sorry to be checking this. I just wanted to make sure that it didn't became like those 2 BR's.
Those two were exactly the same AL13N as has been said time and time again. At no point since Mageia 1 was release have we changed anything in the way we work. Some respond better to it than others.
Unless someone has a better idea how to test this, I'm willing to go with just having ... # httpd -M|grep security security_module (shared) be considered adequate, as it shows that the module is loading ok. Testing complete on Mageia 2 i586.
Whiteboard: (none) => MGA2-32-OK
Testing complete x86_64 I went a little further in testing. The default configuration does not enable any rule sets so mod_security will not be doing much. So I uncommented the lines Include conf/modsecurity/*.conf Include conf/modsecurity/base_rules/*.conf in /etc/httpd/modules.d/82_mod_security.conf mod_security then fails to load with a syntax error in one of the base rules Syntax error on line 47 of /etc/httpd/conf/modsecurity/base_rules/modsecurity_crs_21_protocol_anomalies.conf This may simply be because it is a long time since I have used mod_security and have done something wrong, or else there is an issue with the rule set. This should be the subject of another bug report and not a reason to delay this update. Update Validated Could sysadmin please push apache-mod_security-2.6.3-3.2.mga2.src.rpm from core/updares/testing to core/updates depcheck tells me that perl-GnuPG-0.180.0-1.mga2 will require linking Advisory: ======================== Updated apache-mod_security package fixes security vulnerability: Qualys Vulnerability & Malware Research Labs discovered a vulnerability in ModSecurity, a security module for the Apache webserver. In situations where both "Content:Disposition: attachment" and "Content-Type: multipart" were present in HTTP headers, the vulnerability could allow an attacker to bypass policy and execute cross-site script (XSS) attacks through properly crafted HTML documents (CVE-2012-2751). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2751 http://www.debian.org/security/2012/dsa-2506
Keywords: (none) => validated_updateCC: (none) => derekjenn, sysadmin-bugs
I should add that I checked that the previous version of mod_security gave the same syntax error with that rule set, so it is not a regression.
Bug 6736 has been opened regarding the syntax errors in mod_secure rule sets
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0158
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED