Re: Experimental C unit test suite available for hacking

On 05/23/2018 10:21 PM, Christophe Jaillet wrote: I can reproduce the issue if I don't pass any --enable-mpms-shared paramater to ./configure. Having --with-mpm=xx only also triggers the building issue. What is your ./configure command line? The initial ./configure command line was:

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 10:41 AM, Yann Ylavic wrote: ./configure --prefix=/home/mlenk/Upstream/Apache/target --with-apr=/home/mlenk/Upstream/Apache/target --with-apr-util=/home/mlenk/Upstream/Apache/target --with-mpm=worker --with-mpms-shared=all --enable-mods-static=most

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:28 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic wrote: >> On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: >>> >>> On 05/24/2018 10:41 AM, Yann Ylavic wrote: >>> Btw, as

Re: Experimental C unit test suite available for hacking

Hi Micha, On Thu, May 24, 2018 at 10:29 AM, Micha Lenk wrote: > > I tried several combinations of --with-mpm=worker and > --with-mpms-shared=all, but none of them worked (all attempts with "make > clean"). The most recent attempt used the following ./configure command > line: >

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: > > On 05/24/2018 10:41 AM, Yann Ylavic wrote: > >> Btw, as Jacob noted, the attached patch seems to work for me (even >> without the above option). > > Yes, for me too, except that the linker problem with undefined symbols now

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 11:23 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 11:06 AM, Micha Lenk wrote: >> >> On 05/24/2018 10:41 AM, Yann Ylavic wrote: >> >>> Btw, as Jacob noted, the attached patch seems to work for me (even >>> without the above

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 11:23 AM, Yann Ylavic wrote: Yes, for me too, except that the linker problem with undefined symbols now seems to shift to the modules. I had to disable a few modules (--enable-mods-static=most --disable-apreq --disable-proxy-fcgi --disable-session-cookie

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 10:41 AM, Yann Ylavic wrote: --- Makefile.in (revision 1832123) +++ Makefile.in (working copy) @@ -7,9 +7,9 @@ PROGRAM_SOURCES = modules.c PROGRAM_LDADD= buildmark.o $(HTTPD_LDFLAGS) $(PROGRAM_DEPENDENCIES) $(HTTPD_LIBS) $(EXTRA_LIBS) $(AP_LIBS) $(LIBS)

https vhosts

Do we have a configuration option to allow https://hostname/ only to matching vhosts without any default fallback? Scenario: - a site with vhost A and B - vhost B is taken out, DNS still points there (for a while) - browsers opening https://B/ will get the certificate of A and complain I do

Re: Experimental C unit test suite available for hacking

Hi Yann, FWIW I've found a very good explanation of what's going on during linking and why the library order in static linking is so important. https://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking On 05/24/2018 12:00 PM, Yann Ylavic wrote: Looks like the right order to

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 12:11 PM, Micha Lenk wrote: > > On 05/24/2018 12:00 PM, Yann Ylavic wrote: > >> I think "core" shouldn't depend on a module (even builtin), for >> instance ap_set_{last_modified,accept_range,content_length,...} also >> used by the core are defined in

Re: Experimental C unit test suite available for hacking

Hi Yann, On 05/24/2018 12:31 PM, Yann Ylavic wrote: Well, first things first. Let's first fix trunk to be buildable again on build systems that really only link the needed symbols and thus rely on the correct library order during linking. I think this is*the* dependency issue, the order in

Re: https vhosts

On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing wrote: > >> Am 24.05.2018 um 13:51 schrieb Yann Ylavic : >> >> That'd work (and looks better than Stefan's SNI oriented proposal), >> but I wish we had something working for non-SSL vhosts too, >>

Re: https vhosts

On Thu, May 24, 2018 at 7:51 AM, Yann Ylavic wrote: > On Thu, May 24, 2018 at 1:44 PM, Eric Covener wrote: >> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing >> wrote: >>> >>> Am 24.05.2018 um 13:28 schrieb Eric Covener

Re: https vhosts

On Thu, May 24, 2018 at 2:08 PM, Stefan Eissing wrote: > > >> Am 24.05.2018 um 14:07 schrieb Yann Ylavic : >> >> On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing >> wrote: >>> Am 24.05.2018 um 13:51 schrieb

Re: https vhosts

> Am 24.05.2018 um 14:07 schrieb Yann Ylavic : > > On Thu, May 24, 2018 at 1:57 PM, Stefan Eissing > wrote: >> >>> Am 24.05.2018 um 13:51 schrieb Yann Ylavic : >>> >>> That'd work (and looks better than Stefan's SNI

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018, 06:34 Eric Covener wrote: > On Thu, May 24, 2018 at 7:23 AM, Micha Lenk wrote: > > Hi Yann, > > > > On 05/24/2018 12:31 PM, Yann Ylavic wrote: > >>> > >>> Well, first things first. Let's first fix trunk to be buildable again > on > >>>

Re: https vhosts

On Thu, May 24, 2018 at 2:09 PM, Eric Covener wrote: > > Thinking about base server and how scanners report it the "vulnerability"... > > AllowUnmatchedHost[name]? > RejectUnknownHost[name]? The one or the other is probably a better name than UseDefaultVHost, it allows to

Re: https vhosts

On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing wrote: > Do we have a configuration option to allow https://hostname/ only to matching > vhosts without any default fallback? > > Scenario: > - a site with vhost A and B > - vhost B is taken out, DNS still points there

Re: Experimental C unit test suite available for hacking

On Thu, May 24, 2018 at 7:23 AM, Micha Lenk wrote: > Hi Yann, > > On 05/24/2018 12:31 PM, Yann Ylavic wrote: >>> >>> Well, first things first. Let's first fix trunk to be buildable again on >>> build systems that really only link the needed symbols and thus rely on >>> the >>>

Re: https vhosts

> Am 24.05.2018 um 13:28 schrieb Eric Covener : > > On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing > wrote: >> Do we have a configuration option to allow https://hostname/ only to >> matching vhosts without any default fallback? >> >>

Re: https vhosts

Hi Stefan, as i've tried todo nearly the same some weeks ago i can tell you what i did. Comment inline. Am 24.05.2018 um 13:34 schrieb Stefan Eissing: > So, we are lacking an option here to abort SSL connections without a vhost > match, it seems. Something like > > SSLStrictSNIVHostCheck

Re: https vhosts

On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing wrote: > > >> Am 24.05.2018 um 13:28 schrieb Eric Covener : >> >> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing >> wrote: >>> Do we have a configuration option to

Re: https vhosts

> On 24 May 2018, at 12:44, Eric Covener wrote: > > On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing > wrote: >> >> >>> Am 24.05.2018 um 13:28 schrieb Eric Covener : >>> >>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing

Re: https vhosts

On Thu, May 24, 2018 at 1:44 PM, Eric Covener wrote: > On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing > wrote: >> >> >>> Am 24.05.2018 um 13:28 schrieb Eric Covener : >>> >>> On Thu, May 24, 2018 at 7:23 AM, Stefan Eissing >>>

Re: https vhosts

> Am 24.05.2018 um 13:43 schrieb Stefan Priebe - Profihost AG > : > > Hi Stefan, > > as i've tried todo nearly the same some weeks ago i can tell you what i did. :-) In the era of DGSVO, some sites simply wish to disappear silently... > Comment inline. > > Am

Re: https vhosts

Personally, I am looking for an option where I do not have to keep "old" vhosts around. Also, I would like to avoid that someone points "beastlovers.net" to my ip address and people get the greenbytes.de homepage when follwing some spam/phishing mails (this is a theoretical thread model, rest

Re: https vhosts

> Am 24.05.2018 um 13:51 schrieb Yann Ylavic : > > On Thu, May 24, 2018 at 1:44 PM, Eric Covener wrote: >> On Thu, May 24, 2018 at 7:34 AM, Stefan Eissing >> wrote: >>> >>> Am 24.05.2018 um 13:28 schrieb Eric