Re: alias.t/extra.conf.in change 1829008

2018-08-22 Thread pgajdos
On Tue, Aug 21, 2018 at 08:51:56PM +0200, Marion & Christophe JAILLET wrote:
> > One thing I noticed is insufficient version checking of httpd version,
> Well, it is sometimes hard to figure out when a given feature or directive
> has been added. Especially when tests are added a long time afterwards.
> Well, it is not that hard, but it is time consuming and honestly, I don't
> really focus on old releases compatibility.
> And as you say, 2.2 is no more supported by us, so...

Yes, this was actually implicit question if you want to see such
patches I had sent you or you rather want to get rid of 2.2 ifversions
in the testsuite. Thanks for replying, again implicitly ;).

> Having more test is always needed and we consider that some work should be
> needed in this area.
> Contributions welcome :)

Noted.

Petr



Re: alias.t/extra.conf.in change 1829008

2018-08-21 Thread Marion & Christophe JAILLET




Le 21/08/2018 à 15:27, pgajdos a écrit :

Hello Christophe,

On Mon, Aug 20, 2018 at 08:34:16PM +0200, Marion & Christophe JAILLET wrote:

according to https://httpd.apache.org/docs/2.4/en/mod/mod_alias.html#alias,
Alias with-in a LocationMatch is allowed since 2.4.19.
If you can test and confirm, I'll update the test-framework accordingly.

yes, as far as I tested correctly, this is true from 2.4.20 on, 2.4.19
was not released, so I can not test.


BTW, glad to see someone tweaking our test framework.
Feel free to send any improvements and/or additional tests. They will be
added to the base in order to improve future releases.

And I should say big thank you for the test suite. It helps me every
security update in regression testing.

For curiosity, there is a apache-test spec running the testsuite
during build (the package results in no rpm):
[0] https://build.opensuse.org/package/show/Apache:Test/apache-test
and therefore testing the httpd in respective distros. I have similar
setup in internal build service instance, where I am testing httpd
BEFORE and AFTER each security update in several distros.

For one example, from link [0], the testsuite is failing for
openSUSE Leap 42.3, and this is because we backported http_strict
things, but had not noticed
http://svn.apache.org/viewvc?view=revision=1800215
which we now found thanks to the testsuite and we will be releasing
update in near future to fix that.

You can notice from the [0], we have around twenty patches, but almost
all are dedicated to get around issues in older distros, like 'we
ported something to older distros', which the testsuite can not know.

One thing I noticed is insufficient version checking of httpd version,
Well, it is sometimes hard to figure out when a given feature or 
directive has been added. Especially when tests are added a long time 
afterwards. Well, it is not that hard, but it is time consuming and 
honestly, I don't really focus on old releases compatibility.

And as you say, 2.2 is no more supported by us, so...

Having more test is always needed and we consider that some work should 
be needed in this area.

Contributions welcome :)


The 'lbmethod=heartbeat' in 2.3.0+ has been fixed in r1838576.
The 'ProxyAddHeaders' in 2.3.10+ has been fixed in r1838578.

For 'SSLOCSPResponderCertificateFile' I've asked on the dev@ list if 
just skipping the directive is enough or if something else must be tweaked.



I've gone through [0] and applied what make sense to me. If you consider 
that something else could be backported (i.e. is not opensuse specific), 
do not hesitate to tell me what.


I'm also adding the dev@ list in copy, there is no need to keep this 
private. Others could be interested.


CJ



see attachments. Note we will still be supporting 2.2 branch for
certain amount of time in one of our distros, not sure though how much
the testsuite upstream should take it into account given that 2.2 is no
longer supported upstream. But at least SSLOCSPResponderCertificateFile
should be surrounded I think.

I have also issue with ocsp.t failing completely, but that needs more
investigation.

Thanks again for the great testsuite!

Petr