Thread: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

Brought to you by: victorhora, zimmerletw

mod-security-developers

[Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Alberto G. I. <ag...@in...> - 2018-11-27 11:01:12

Hi,

The build daemons at Debian are failing the test suite for modsecurity
3.x. There are two failures I could use some help on:

1) 
./regression_tests .././test/test-cases/regression/variable-ENV.json:1
:test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)

My guess is that build daemon don't have the TERM variable set, and I'm
pondering disabling this test unless someone claims this is a bad idea.

2) But the ones that are really beyond my understanding are those in:
test/test-cases/secrules-language-tests/operators/ipMatch.json
Failing in s390, ppc64 and sparc64. I suspect they may be related to
endianness, but I really need help with those. You may find the build
logs here [1].

If we get this solved quickly, modsecurity 3.x will be available in
Debian's next release. [2]


Thanks,

Alberto


[1]
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=s390x&ver=3.0.2-1&stamp=1539707222&raw=0
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=ppc64&ver=3.0.2-1&stamp=1540024601&raw=0
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=sparc64&ver=3.0.2-1&stamp=1539704551&raw=0

[2] https://release.debian.org/buster/freeze_policy.html
-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Ervin H. <ai...@gm...> - 2018-11-27 11:21:51

Hi Alberto,

On Tue, Nov 27, 2018 at 11:42:54AM +0100, Alberto Gonzalez Iniesta wrote:
> Hi,
> 
> The build daemons at Debian are failing the test suite for modsecurity
> 3.x. There are two failures I could use some help on:
> 
> 1) 
> ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> 
> My guess is that build daemon don't have the TERM variable set, and I'm
> pondering disabling this test unless someone claims this is a bad idea.

that's what I wrote you on mod-security-packagers list:

https://sourceforge.net/p/mod-security/mailman/message/36455922/

But my question is: why is it better to completely disable the
test than my suggestion?

* I've suggested a solution:
https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
* I'm sure that there are several other solution, eg: make a
  patch in debian/patches/ directory, which replaces the TERM
  variable for an another ENV variable, which exists in build
  system?

> 2) But the ones that are really beyond my understanding are those in:
> test/test-cases/secrules-language-tests/operators/ipMatch.json
> Failing in s390, ppc64 and sparc64. I suspect they may be related to
> endianness, but I really need help with those. You may find the build
> logs here [1].

I'll check that soon.

> If we get this solved quickly, modsecurity 3.x will be available in
> Debian's next release. [2]

please review the milestones:

https://github.com/SpiderLabs/ModSecurity/milestones

The next release had planned at Nov 08, 2019 - that's about a
year. Hope that's just a "plan" :).

But if the next release will not published till the freeze time,
you have to make the patches. I'll help you readily.

a.

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Alberto G. I. <ag...@in...> - 2018-11-27 13:02:46

Hi Ervin!

On Tue, Nov 27, 2018 at 12:21:28PM +0100, Ervin Hegedüs wrote:
> Hi Alberto,
> 
> On Tue, Nov 27, 2018 at 11:42:54AM +0100, Alberto Gonzalez Iniesta wrote:
> > Hi,
> > 
> > The build daemons at Debian are failing the test suite for modsecurity
> > 3.x. There are two failures I could use some help on:
> > 
> > 1) 
> > ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> > :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> > 
> > My guess is that build daemon don't have the TERM variable set, and I'm
> > pondering disabling this test unless someone claims this is a bad idea.
> 
> that's what I wrote you on mod-security-packagers list:
> 
> https://sourceforge.net/p/mod-security/mailman/message/36455922/
> 
> But my question is: why is it better to completely disable the
> test than my suggestion?

As we already talked about, I'm not sure that playing with envvars in
build daemons is such a good idea. And I'd like to know if that test is
really useful. That's why I asked here again.

> * I've suggested a solution:
> https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
> * I'm sure that there are several other solution, eg: make a
>   patch in debian/patches/ directory, which replaces the TERM
>   variable for an another ENV variable, which exists in build
>   system?

Maybe the person that created the test case in the first place can
clarify the target of it.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Ervin H. <ai...@gm...> - 2018-11-27 13:25:19

Hi Alberto,

On Tue, Nov 27, 2018 at 02:02:22PM +0100, Alberto Gonzalez Iniesta wrote:
> > > Hi,
> > > 
> > > The build daemons at Debian are failing the test suite for modsecurity
> > > 3.x. There are two failures I could use some help on:
> > > 
> > > 1) 
> > > ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> > > :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> > > 
> > > My guess is that build daemon don't have the TERM variable set, and I'm
> > > pondering disabling this test unless someone claims this is a bad idea.
> > 
> > that's what I wrote you on mod-security-packagers list:
> > 
> > https://sourceforge.net/p/mod-security/mailman/message/36455922/
> > 
> > But my question is: why is it better to completely disable the
> > test than my suggestion?
> 
> As we already talked about, I'm not sure that playing with envvars in
> build daemons is such a good idea. And I'd like to know if that test is
> really useful. That's why I asked here again.

right - hope somebody will clarify / confirm or confute this, but
I think it's useful and important. I mean it is, but not for the
build environment, but the developers and production
environments.
 
> > * I've suggested a solution:
> > https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
> > * I'm sure that there are several other solution, eg: make a
> >   patch in debian/patches/ directory, which replaces the TERM
> >   variable for an another ENV variable, which exists in build
> >   system?
> 
> Maybe the person that created the test case in the first place can
> clarify the target of it.

let's see the rule, what's happening:
- ModSec wants to read an environment variable, short form ENV
- the name of variable is "TERM"
- ModSec checks if the variable contains the pattern "test"
- and finally, it doesn't care if it does :), because the action
  will pass always

I think this test case just _READ_ the ENV, it doesn't matter,
what's the content of it.

If it can't read, then it will fail.

As I wrote above, hope somebody will confirm it, but I think it
would be good to keep this test, and replace the ENV for
something what exists in build env, or setit up explicitly.



Regards,


a.

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Felipe C. <FC...@tr...> - 2018-11-28 14:22:26

Hi Alberto,

On 11/27/18, 10:02 AM, "Alberto Gonzalez Iniesta" <ag...@in...> wrote:

    Hi Ervin!

    On Tue, Nov 27, 2018 at 12:21:28PM +0100, Ervin Hegedüs wrote:

(...)

    > 
    > https://scanmail.trustwave.com/?c=4062&d=_MD928s2E7_LLeYfmEvXduZalbOHdDL5LPg1bkTMNQ&s=5&u=https%3a%2f%2fsourceforge%2enet%2fp%2fmod-security%2fmailman%2fmessage%2f36455922%2f
    > 
    > But my question is: why is it better to completely disable the
    > test than my suggestion?

    As we already talked about, I'm not sure that playing with envvars in
    build daemons is such a good idea. And I'd like to know if that test is
    really useful. That's why I asked here again.

The test is important. It tests ModSec's ability to read environment variables. It is listed here:
https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-ENV.json

We may have poorly selected the name of the variable as it seems that the variable is not broadly used.

(...)

    Maybe the person that created the test case in the first place can
    clarify the target of it.

The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.

I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

If setting the variable is a problem, I would prefer to change it to make it more broad available.

A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant. 

Br.
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Alberto G. I. <ag...@in...> - 2018-11-28 14:58:34

Hi Felipe,

On Wed, Nov 28, 2018 at 02:21:54PM +0000, Felipe Costa wrote:
(snip)
>     
> The test is important. It tests ModSec's ability to read environment variables. It is listed here:
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-ENV.json

Since the previous test case reads another one (PATH), it wasn't clear
to me if TERM was choosen for a particular reason.

> We may have poorly selected the name of the variable as it seems that the variable is not broadly used.
> 
> (...)
> 
>     Maybe the person that created the test case in the first place can
>     clarify the target of it.
>     
> The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.
> 
> I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

Ok, I'll set the variable as Ervin suggested then.

> If setting the variable is a problem, I would prefer to change it to make it more broad available.
> 
> A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant. 

If setenv is used in the future it will save the packaging scripts from
setting it, thanks.

Thank you both for your help and clarification.

I hope we can trace the FAILures on the s390, ppc64 and sparc64 archs so
the package can start migrating to Debian Buster.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Felipe C. <FC...@tr...> - 2018-11-30 00:55:16

Hi guys,

I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.

Further details are listed here: https://github.com/SpiderLabs/ModSecurity/issues/1969

Thank you.

Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

Trustwave | SMART SECURITY ON DEMAND

www.trustwave.com<http://www.trustwave.com/>

Recognized by industry analysts as a leader in managed security services<https://www.trustwave.com/Company/About-Us/Accolades/>.

________________________________
From: Alberto Gonzalez Iniesta <ag...@in...>
Sent: Wednesday, November 28, 2018 12:58:05 PM
To: mod...@li...
Subject: Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

Hi Felipe,

On Wed, Nov 28, 2018 at 02:21:54PM +0000, Felipe Costa wrote:
(snip)
>
> The test is important. It tests ModSec's ability to read environment variables. It is listed here:
> https://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18QaJ3G24Xg&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2ftest%2ftest-cases%2fregression%2fvariable-ENV%2ejson

Since the previous test case reads another one (PATH), it wasn't clear
to me if TERM was choosen for a particular reason.

> We may have poorly selected the name of the variable as it seems that the variable is not broadly used.
>
> (...)
>
>     Maybe the person that created the test case in the first place can
>     clarify the target of it.
>
> The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.
>
> I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

Ok, I'll set the variable as Ervin suggested then.

> If setting the variable is a problem, I would prefer to change it to make it more broad available.
>
> A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant.

If setenv is used in the future it will save the packaging scripts from
setting it, thanks.

Thank you both for your help and clarification.

I hope we can trace the FAILures on the s390, ppc64 and sparc64 archs so
the package can start migrating to Debian Buster.

Regards,

Alberto

--
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18VOJjGjqWQ&s=5&u=http%3a%2f%2finittab%2ecom

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

_______________________________________________
mod-security-developers mailing list
mod...@li...
https://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18QSK0GzqXQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Ervin H. <ai...@gm...> - 2018-11-30 07:17:13

Hi Felipe,

On Fri, Nov 30, 2018 at 12:55:03AM +0000, Felipe Costa wrote:
> Hi guys,
> 
> 
> I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.
> 
> 
> Further details are listed here: https://github.com/SpiderLabs/ModSecurity/issues/1969

sounds good,

> Thank you.

we thank you too.

Just one question: as Alberto wrote in his first e-mail, the
freeze date is soon.

We can apply this modification only as Debian patch, if the 3.0.4
will not released the dates. 

What do you think, when will you release the new version?

Here is the dates again:

https://release.debian.org/buster/freeze_policy.html

The freeze for buster will happen according to the following
timeline:

* 2019-01-12 - Transition freeze
* 2019-02-12 - Soft-freeze
* 2019-03-12 - Full-freeze

thanks,

a.

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Felipe C. <FC...@tr...> - 2018-11-30 12:09:00

Hard to tell a precise date for 3.0.4. If not a trouble, I would recommend to keep it as a patch till we figure a precise date for the release.

The patches are:
 - https://github.com/SpiderLabs/ModSecurity/commit/25bb1f1bcc7252e93bd42067cac23a07b71fb8b9.patch
 - https://github.com/SpiderLabs/ModSecurity/commit/b736f0292dd24c53b1f54c027d022440791d9cc4.patch
 - https://github.com/SpiderLabs/ModSecurity/commit/407b6c0f4bbeba519d998dad0e2e99c1c455e3c5.patch

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
 
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
 

On 11/30/18, 4:17 AM, "Ervin Hegedüs" <ai...@gm...> wrote:

    Hi Felipe,
    
    On Fri, Nov 30, 2018 at 12:55:03AM +0000, Felipe Costa wrote:
    > Hi guys,
    > 
    > 
    > I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.
    > 
    > 
    > Further details are listed here: https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UDBmP5pkg&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fissues%2f1969
    
    sounds good,
    
    > Thank you.
    
    we thank you too.
    
    Just one question: as Alberto wrote in his first e-mail, the
    freeze date is soon.
    
    We can apply this modification only as Debian patch, if the 3.0.4
    will not released the dates. 
    
    What do you think, when will you release the new version?
    
    Here is the dates again:
    
    https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UOQlKxrnA&s=5&u=https%3a%2f%2frelease%2edebian%2eorg%2fbuster%2ffreeze%5fpolicy%2ehtml
    
    The freeze for buster will happen according to the following
    timeline:
    
    * 2019-01-12 - Transition freeze
    * 2019-02-12 - Soft-freeze
    * 2019-03-12 - Full-freeze
    
    
    thanks,
    
    
    
    a.
    
    
    
    
    _______________________________________________
    mod-security-developers mailing list
    mod...@li...
    https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UCXla4_zg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
    ModSecurity Services from Trustwave's SpiderLabs:
    https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

From: Hegedüs E. <ai...@gm...> - 2018-11-30 12:11:05

Hi Felipe,

On Fri, Nov 30, 2018 at 12:08:13PM +0000, Felipe Costa wrote:
> Hard to tell a precise date for 3.0.4. If not a trouble, I would recommend to keep it as a patch till we figure a precise date for the release.
> 
> The patches are:
>  - https://github.com/SpiderLabs/ModSecurity/commit/25bb1f1bcc7252e93bd42067cac23a07b71fb8b9.patch
>  - https://github.com/SpiderLabs/ModSecurity/commit/b736f0292dd24c53b1f54c027d022440791d9cc4.patch
>  - https://github.com/SpiderLabs/ModSecurity/commit/407b6c0f4bbeba519d998dad0e2e99c1c455e3c5.patch

thanks, I'll see these.


a.