Thread: [mod-security-users] ModSecurity v2.8.0-RC1
Brought to you by:
victorhora,
zimmerletw
From: Felipe C. <FC...@tr...> - 2014-04-01 03:16:51
|
Hi, It is a pleasure to announce that ModSecurity version 2.8.0-RC1 is now ready! This release candidate contains new features, bug fixes and improvements. The new features are: * JSON Parser is no longer under tests. Now it is part of our mainline. * Connection limits (SecConnReadStateLimit/SecConnWriteStateLimit) now support white and suspicious list. * New variables: FULL_REQUEST and FULL_REQUEST_LENGTH were added, allowing the rules to access the full content of a request. * ModSecurity status is now part of our mainline. * New operator: @detectXSS was added. It makes usage of the newest libinjection XSS detection functionality. * Append and prepend are now supported on nginx (Ref: #635<https://github.com/SpiderLabs/ModSecurity/issues/635>). * SecServerSignature is now available on nginx (Ref: #637<https://github.com/SpiderLabs/ModSecurity/issues/637>). Check out the full list of changes straight from GitHub: https://github.com/SpiderLabs/ModSecurity/releases/tag/v2.8.0-rc1 Besides the listed changes we are also modifying the name of our release tarball. We were labeling our release by: "modsecurity-apache_X.Y.Z.tar.gz", since we started to support Nginx, this name became outdated. Now we are labeling it as "modsecurity-X.Y.Z.tar.gz". For those who are automagically generating packages, it won't be a problem, the old naming policy will be preserved on the modsecurity.org<http://modsecurity.org> server. As in the last release, this will be stored in two different servers: modsecurity.org<http://modsecurity.org> and GitHub. Hashes will be provided for the tarball integrity verification. The release tags are also GPG-Signed. Br., Felipe "Zimmerle" Costa Security Researcher, SpiderLabs Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. |
From: Reindl H. <h.r...@th...> - 2014-04-01 14:13:24
Attachments:
signature.asc
|
recently built RPM and started testing on development machines looks all fine, interaction with mod_remoteip / proxy is the last thing i need to verify P.S.: there is a typo in the changelog 2.0.8 would be a massive downgrade :-) Am 01.04.2014 05:16, schrieb Felipe Costa: > It is a pleasure to announce that ModSecurity version 2.8.0-RC1 is now ready! |
From: Felipe C. <FC...@tr...> - 2014-04-01 16:41:29
|
Hi Reindl, On Apr 1, 2014, at 11:13 AM, Reindl Harald <h.r...@th...<mailto:h.r...@th...>> wrote: recently built RPM and started testing on development machines looks all fine, interaction with mod_remoteip / proxy is the last thing i need to verify P.S.: there is a typo in the changelog 2.0.8 would be a massive downgrade :-) No downgrades, please :) Thanks for testing it. We appreciate. Sorry about the typo, it was already fixed on the master branch. As you guys already started the tests, I don't want to release an -RC2 neither overwrite the git tag. Will be fixed by the final release or -RC2. If something else also needs to be fixed or if you guys need it fixed, due to automagically build scripts, I can release the -RC2, let me know. The final release is scheduled to april 15: https://github.com/SpiderLabs/ModSecurity/issues/milestones Btw, did you had a chance to test the new functionalities? SecStatusEngine, JSON parser? Thanks, Felipe "Zimmerle" Costa Lead Developer for ModSecurity, SpiderLabs Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. |
From: Reindl H. <h.r...@th...> - 2014-04-01 17:00:11
Attachments:
signature.asc
|
Am 01.04.2014 18:41, schrieb Felipe Costa: > On Apr 1, 2014, at 11:13 AM, Reindl Harald <h.r...@th... <mailto:h.r...@th...>> wrote: > >> recently built RPM and started testing on development machines >> looks all fine, interaction with mod_remoteip / proxy is the >> last thing i need to verify >> >> P.S.: >> there is a typo in the changelog >> 2.0.8 would be a massive downgrade :-) > > No downgrades, please :) oh yes :-) > Thanks for testing it. We appreciate. mod_remoteip / proxy is also fine tested with rules like below and a faked nessus-useragent which would be blocked otherwise, in other words i see no changes which is good in case of working production servers 100% identically configured SecRule REMOTE_ADDR "^192\.168\.0\.99" "id:'500009',phase:1,pass,nolog,ctl:ruleRemoveById=80" > Sorry about the typo, it was already fixed on the master branch. As you guys already started the tests, I don't > want to release an -RC2 neither overwrite the git tag. Will be fixed by the final release or -RC2. If something > else also needs to be fixed or if you guys need it fixed, due to automagically build scripts, I can release the > -RC2, let me know i think that don't really matter ____________________________________________ in my case i unpacked the tarball, renamed it and used modsecurity-apache_2.8.0.tar.gz to simply feed rpmbuild with a GA fake versioning and only release comments, the release-tag contains the current date to make mass-rebuilds with deps easier if someone wants to do the same (not only for modsec) see below "%dist .fc20.%(echo $(/bin/date +%Y%m%d)).rh" is the relevant magic mod_security-2.8.0-1.fc20.20140401.rh.x86_64 [builduser@buildserver64:~]$ cat /home/builduser/.rpmmacros %_topdir %(echo $HOME)/rpmbuild %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot %dist .fc20.%(echo $(/bin/date +%Y%m%d)).rh %fedora 20 %fc20 1 %_smp_mflags -j8 %_include_minidebuginfo 0 %_binary_payload w9.xzdio %_source_payload w9.xzdio %__global_ldflags -Wl,-z,now -Wl,-z,relro,-z,noexecstack %configure \ CFLAGS="${CFLAGS:-%optflags}"; export CFLAGS; \ CXXFLAGS="${CXXFLAGS:-%optflags}"; export CXXFLAGS; \ FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}"; export FFLAGS; \ FCFLAGS="${FCFLAGS:-%optflags -I%_fmoddir}"; export FCFLAGS; \ LDFLAGS="${LDFLAGS:-%__global_ldflags}"; export LDFLAGS; \ ./configure \\\ --host=x86_64-redhat-linux \\\ --build=x86_64-redhat-linux \\\ --target=x86_64-redhat-linux \\\ --program-prefix=%{?_program_prefix} \\\ --disable-dependency-tracking \\\ --prefix=%{_prefix} \\\ --exec-prefix=%{_exec_prefix} \\\ --bindir=%{_bindir} \\\ --sbindir=%{_sbindir} \\\ --sysconfdir=%{_sysconfdir} \\\ --datadir=%{_datadir} \\\ --includedir=%{_includedir} \\\ --libdir=%{_libdir} \\\ --libexecdir=%{_libexecdir} \\\ --localstatedir=%{_localstatedir} \\\ --sharedstatedir=%{_sharedstatedir} \\\ --mandir=%{_mandir} \\\ --infodir=%{_infodir} |