Re: default conf and ScriptAlias

[Alex Hautequest]

… both +1 and -1.

A change in version number or major version can imply significant changes in 
the base configuration, and I see this suggestion as a fit for a httpd-2.5, 
-3.0 or the likes. Hence, +1.

However changing such widely used setting on the existing 10 year old 2.4 tree 
will cause operators headaches as the one outlined by Noel - more so as this 
setting is there for way longer than 2.4 and therefore -1.

Alex

> On Oct 9, 2021, at 20:30, Noel Butler  wrote:
> 
> 
>> 
>> On 10/10/2021 03:39, Eric Covener wrote:
>> 
>> Relative to the recent CVEs, should we replace ScriptAlias in the
>> default conf with Alias + SetHandler cgi-script in the corresponding
>> Directory section?
>> 
>> And .. should ScriptAlias be deprecated/discouraged in some way if the
>> expanded version is safer by avoiding the equivalent of setting the
>> handler in Location vs. Directory?
>> 
>> I am assuming it is not possible/feasible to make ScriptAlias just
>> work as if it was in the 2nd arguments Directory config.
> 
>  -1
> 
> 
> 
> You are talking about changing a httpd life long option, thats used in 
> millions of settings around the world.
> 
> Scriptalias setting is not used in any directory setting in my case, its used 
> in a global way
> 
> DocumentRoot "/var/www/html"
> 
> 
> AllowOverride None
> Options SymlinksIfOwnerMatch
> Require all granted
> 
> 
> Alias /icons/ "/var/www/icons/"
> 
> 
> AllowOverride None
> Require all granted
> 
> 
> ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
> 
> 
> AllowOverride None
> Options None
> Require all granted
> 
> 
> 
> 
> and more globally used in every service provider i've been at (not all my 
> doing but end result is identical) inside virtual hosts confs
> 
> 
> ServerName xxx
> ServerAlias www.
> DocumentRoot /var/www/vhost/xxx/www/html
> ScriptAlias /cgi-bin/ /var/www/vhost/x/www/cgi-bin/
> 
> ...snip...
> 
> 
> 
> This is how every person expects it.
> 
> So you want to go make that more convoluted?
> 
> 
> 
> -- 
> Regards,
> Noel Butler
> 
> This Email, including attachments, may contain legally privileged 
> information, therefore at all times remains confidential and subject to 
> copyright protected under international law. You may not disseminate this 
> message without the authors express written authority to do so.   If you are 
> not the intended recipient, please notify the sender then delete all copies 
> of this message including attachments immediately. Confidentiality, 
> copyright, and legal privilege are not waived or lost by reason of the 
> mistaken delivery of this message.
> 
> 

Re: [VOTE] Release httpd-2.4.51-rc1 as httpd-2.4.51

[Alex Hautequest]

+1 on Slackware64 -current

Alex

> On Oct 7, 2021, at 09:17, ste...@eissing.org wrote:
> 
> Hi all,
> 
> due to found security weaknesses in our 2.4.50 release, the security team
> feels it is necessary to do a new release on very short notice. We will skip
> the usual 3 day voting period and close the vote once we feel comfortable
> with our testing.
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days^h^h^h^hhours to release
> this candidate tarball httpd-2.4.51-rc1 as 2.4.51:
> [ ] +1: It's not just good, it's hopefully good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 
> The computed digests of the tarball up for vote are:
> sha1: 516128e5acb7311e6e4d32d600664deb0d12e61f *httpd-2.4.51-rc1.tar.gz
> sha256: c2cedb0b47666bea633b44d5b3a2ebf3c466e0506955fbc3012a5a9b078ca8b4 
> *httpd-2.4.51-rc1.tar.gz
> sha512: 
> 507fd2bbc420e8a1f0a90737d253f1aa31000a948f7a840fdd4797a78f7a4f1bd39250b33087485213a3bed4d11221e98eabfaf4ff17c7d0380236f8a52ee157
>  *httpd-2.4.51-rc1.tar.gz
> 
> The SVN candidate source is found at tags/candidate-2.4.51-rc1.
> 
> Kind Regards,
> Stefan

Re: [VOTE] Release httpd-2.4.46

[Alex Hautequest]

I don’t see why a verbiage similar to “Fixed in Apache httpd-2.4.44 (not 
released to the public)” couldn’t be used: this is, after all, a true statement.

While it should be common understanding that newer code versions carry 
improvements and fixes from previous ones, maybe this should be clarified on 
the initial paragraphs of the vulnerabilities page.

Last but not least, this also resolves thoughts of “where is 2.4.44, I cannot 
find it” (although only if one browses to the vulnerabilities page).

What I am not sure, however, is how much this affects the existing automation 
workflow.

Alex

> On Aug 8, 2020, at 08:27, Daniel Ruggeri  wrote:
> 
> Hi, Bill;
>   I wondered about this myself. I agree that we allow for ambiguity
> when we say an issue is fixed in 2.4.44 and 2.4.45 (which weren't
> released). Perhaps we should just bump the 'fixed' version up to the
> released version... but then we should also add to the 'affected'
> versions the version numbers we burned during QA. That's odd, too,
> because we didn't release those versions so they aren't really 'affected'.
> 
>   I could go either way... the vulnerability reporting is enough "after
> work" for a release that makes it a prime candidate for processing it
> with announce.sh, so I'm happy to encode whatever we consider the best
> way forward into that script.
> 
> -- 
> Daniel Ruggeri
> 
>> On 8/7/2020 8:56 AM, William A Rowe Jr wrote:
>> Following the announcement link, it isn't clear that
>> https://httpd.apache.org/security/vulnerabilities_24.html
>> fixes issues in 2.4.46.
>> Should the fixed-in be promoted to the revision of Apache HTTP Server
>> actually published (released) by the project? It almost reads like
>> "fixed in
>> 2.4.46-dev" (which 0-day disclosures are described as, until a release
>> is actually published.)
>> On Wed, Aug 5, 2020 at 6:32 AM Daniel Ruggeri > > wrote:
>>   Hi, all;
>>  With 12 binding PMC +1 votes, two additional +1 votes from the
>>   community, and no -1 votes, I'm pleased to report that the vote has
>>   PASSED to release 2.4.46. I will begin the process of pushing to the
>>   distribution mirrors which should enable us for a Friday
>>   announcement -
>>   a great way to wrap up the week!
>>   Here are the votes I recorded during the thread:
>>   PMC
>>   jailletc36, steffenal, elukey, jorton, jfclere, ylavic, covener,
>>   gbechis, gsmith, druggeri, jblond, rjung
>>   Community
>>   Noel Butler, wrowe
>>   --
>>   Daniel Ruggeri
>>>   On 8/1/2020 9:13 AM, Daniel Ruggeri wrote:
>>> Hi, all;
>>>   Third time is a charm! Please find below the proposed release
>>   tarball
>>> and signatures:
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>> I would like to call a VOTE over the next few days to release this
>>> candidate tarball as 2.4.46:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>> The computed digests of the tarball up for vote are:
>>> sha1: 15adb7eb3dc97e89c8a4237901a9d6887056ab98 *httpd-2.4.46.tar.gz
>>> sha256:
>>   44b759ce932dc090c0e75c0210b4485ebf6983466fb8ca1b446c8168e1a1aec2
>>> *httpd-2.4.46.tar.gz
>>> sha512:
>>   
>> 5801c1dd0365f706a5e2365e58599b5adac674f3c66b0f39249909841e6cdf16bfdfe001fbd668f323bf7b6d14b116b5e7af49867d456336fad5e685ba020b15
>>> *httpd-2.4.46.tar.gz
>>> The SVN tag is '2.4.46' at r1880505.

iOS 14 / macOS 11 and HTTP/3 support

[Alex Hautequest]

From Apple’s developer beta release notes, the newest Apple code is now 
shipping with HTTP/3 support. Disabled by default, but can be enabled by users. 
As of today, HTTP/3 Draft 29 isn’t yet supported.

Alex

SSLStrictSNIVHostCheck not being enforced by mod_ssl

[Alex Hautequest]

"SSLStrictSNIVHostCheck On” directive in either _default_ or specific vhost 
entry has no effect: clients not forced to provide SNI data for web site access.

Environment:
- Standard HTTPD 2.4.43 and OpenSSL 1.1.1f builds from Pat Volkerdi’ Slackware 
-current.

Enabled "LogLevel debug”, not seeing *anything* SNI related in the logs.

Ideas?

--
Alex

Support for RFC7627 (Extended Master Secret) on mod_ssl

[Alex Hautequest]

Does mod_ssl supports this RFC for EMS? I’ve found no references to this on the 
current documentation.

Seems this has been added to NIST recommendations a while back, and from an old 
OpenSSL thread[1], this is a client and server combination, most modern clients 
are now using.

More folks might be looking at this now that consumer grade systems[2] are 
reporting if their servers does or does not support this.

[1] https://github.com/openssl/openssl/issues/7246#issuecomment-452360968 

[2] https://www.immuniweb.com/ 

— Alex

Re: svn commit: r1875349 - /httpd/site/trunk/tools/roll.sh

[Alex Hautequest]

From OpenSSL download page (https://www.openssl.org/source/):

Note: The latest stable version is the 1.1.1 series. This is also our Long Term 
Support (LTS) version, supported until 11th September 2023. All other versions 
(including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not 
be used. Users of these older versions are encourage to upgrade to 1.1.1 as 
soon as possible. Extended support for 1.0.2 to gain access to security fixes 
for that version is available.

While I understand they do offer paid support for previous versions, I don’t 
think it is wise for httpd to openly support a discouraged code. Previous 
OpenSSL versions were fun, but it is time to move on.

Just my $.02.

Alex

> On Mar 18, 2020, at 09:44, jean-frederic clere  wrote:
> 
> On 18/03/2020 11:09, Ruediger Pluem wrote:
>>> On 3/18/20 9:36 AM, jfcl...@apache.org wrote:
>>> Author: jfclere
>>> Date: Wed Mar 18 08:36:46 2020
>>> New Revision: 1875349
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1875349=rev
>>> Log:
>>> Add sha512
>>> 
>>> Modified:
>>> httpd/site/trunk/tools/roll.sh
>>> 
>>> Modified: httpd/site/trunk/tools/roll.sh
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/site/trunk/tools/roll.sh?rev=1875349=1875348=1875349=diff
>>> ==
>>> --- httpd/site/trunk/tools/roll.sh (original)
>>> +++ httpd/site/trunk/tools/roll.sh Wed Mar 18 08:36:46 2020
>>> @@ -103,9 +103,11 @@ openssl="`which openssl 2> /dev/null | h
>>>  md5sum="`which md5sum 2> /dev/null | head -1`"
>>>  sha1sum="`which sha1sum 2> /dev/null | head -1`"
>>>  sha256sum="`which sha256sum 2> /dev/null | head -1`"
>>> +sha512sum="`which sha512sum 2> /dev/null | head -1`"
>>>  md5="`which md5 2> /dev/null | head -1`"
>>>  sha1="`which sha1 2> /dev/null | head -1`"
>>>  sha256="`which sha256 2> /dev/null | head -1`"
>>> +sha512sum="`which sha512sum 2> /dev/null | head -1`"
>> Should the above be sha512 instead of sha512sum?
>> Are we sure that openssl / gpg are capable of sha512 for a reasonable span 
>> of versions or is it worth checking for a
>> minimal version?
> 
> gpg looks good, openssl > 1.0.0 is good too and 10 years old no?
> 
>> Regards
>> Rüdiger
> 
> 
> -- 
> Cheers
> 
> Jean-Frederic

Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

[Alex Hautequest]

IMHO, it *is* intuitive. If you want no default configuration, do not set one 
by default, otherwise inheritance applies - just as everything else in this 
daemon.

Or are you all planning to opt in/out every other settings as well, to make a 
standard "intuitive-driven” configuration approach?

> On Oct 25, 2019, at 10:18 AM, Yann Ylavic  wrote:
> 
> The current status is that, without an opt-in/out, it takes the root
> value if configured, or the base server's otherwise. Not very
> intuitive...

Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

[Alex Hautequest]

Although I should had made a few things clear, seems some good discussion 
happened. Amongst the same lines:

When I asked about Apache, I should had stated HTTPD. There is a QUIC 
implementation on Apache.org under ATS (Apache Traffic Server), a reverse 
proxy, load balancer daemon. While definitely an interesting approach that 
takes a ton of overhead from the web server, it adds much more than “just a 
mod_h3” to be maintained. Not that a mod_h3 wouldn’t be enough work to be 
maintained.

A motivator for the implementation is the continuity and evolution of the web 
we all know and rely on, which this very ancient dinosaur daemon helped to 
build and solidify. Apache may or may not have the largest market share amongst 
HTTP servers anymore, but it does not means it is stuck in time. As of h2, h3 
is another evolution that should be looked at, when the time is right.

And while all is well said, it needs done. I too agree it might be a fun 
project for anyone with enough time, motivation and skills to do so. I fall 
short on at least one of these, so as much as the enthusiast of me would love 
to turn it on at my systems, I’m yet to remember how to code anything other 
than a bash script or minor automation tools in pre-made, 3rd party Python 
modules. Besides, h3 is not a full formal standard yet, so while it is showing 
signs it will be some day, it might be as QUIC is/was for a while before it 
settles up as standard. But it never hurt to be checked out.

Last but not least, thanks Stefan for your h2 work.

Alex

> On Sep 27, 2019, at 17:12, Helmut K. C. Tessarek  wrote:
> 
> On 2019-09-27 11:47, Eric Covener wrote:
>> I don't think market share is a big motivating factor for active 
>> contributors.
> 
> Maybe not, but I remember a discussion a while back on this list that had to
> do with features vs stability, about market shares and why other web servers
> are gaining.
> 
>> HTTP/3 would be a lot of work, a lot of shoehorning into HTTPD, and
>> likely be de-stabilizing for quite some time.   There is
>> simply nobody (seemingly) working on it.
> 
> I get that, I was simply saying that I didn't understand why there wasn't a
> plan. That's all.
> I also do understand that this might be a highly complex topic, especially
> since it will touch many components.
> I'm very grateful that Stefan took the initiative to get h2 into httpd.
> 
>> HTTPD is great and familiar to lots of people, but HTTPD'S age brings
>> a lot of baggage. Lots of other great servers have much
>> less baggage and currently have much more commercial interest and buzz.
> 
> I've been using Apache httpd since the early days and I won't be switching to
> another web server. But the "baggage" can't be the reason for stagnation. A
> web server's main functionality is to serve web pages. If the protocol evolves
> so must the server, otherwise the server will be obsolete at one point in the
> future.
> 
> Cheers,
>  K. C.
> 
> -- 
> regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */
> 

Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

[Alex Hautequest]

https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support

With that, the obvious question: what about Apache?

Re: Default log file locations

[Alex Hautequest]

$ tail -F /var/log/apache/access_log /var/log/apache/error_log

There’s your stdout output, no code modifications needed. You are welcome.

Jokes aside, you could make use of a web socket to pull these logs out in a way 
code doesn’t need to be changed. Or you could dump them straight into a 
database. Or, IDK, there are so many ways to extract the logs from this ancient 
daemon, that defaulting them to stdout/stderr sounds like a bad idea - for one 
sole user/reason, is too much of a change.

If *maybe* the suggestion was to allow usage of stdout/stderr instead of 
defaulting them to those, it would be a less dramatic change, but hey, caveats 
are starting to appear, as Eric just pointed one out.

Alex

> On Jun 27, 2019, at 17:24, Eric Covener  wrote:
> 
> 
>> 
>> From my perspective it would be advantageous to have Apache write to
>> the terminal by default (i.e. no hardcoded log file locations) and
>> allow to override this behavior via the Apache configuration file.
> 
>> Is there any reason why the default behavior is not that way yet?
> 
> I think it's useful as opt-in, but I wouldn't want to see any
> "defaults" changed (whether that's how the code behaves in the absence
> of logging related directives, or how our default httpd.conf looks)
> 
> One wrinkle I recall here is that the closing of stdout and stderr
> happens in APR (apr_proc_detach?) and it requires a new APR release to
> provide any alternate options there.

Re: Plan to add sandbox branch

[Alex Hautequest]

How often are nodes updating themselves? Are they only updating their main 
proxy server or each other in a “multicast” fashion? How about if one of the 
nodes crash before sending back an update? Are you locking a session to a 
specific backend host, keep it tracked on the proxy/front end server and if so, 
for how long?

When I read your message, in particular the STATUS info statement, this plan of 
yours looked to me like how a regular load balancer product works, and if that 
is the intent, how different from and/or how integrated to ATS is this going to 
be?

Alex

On 2018/11/27 11:23:25, Jim Jagielski  wrote: 
> In the coming week or so, I will be committing my load balance,> 
> load determination and discovery work to a sandbox trunk. Many> 
> people have asked for more info, so here we go.> 
> 
> Basically, this new feature uses nanomsg (nng) to implement the> 
> SURVEY protocol between workers (nodes) and the front end server.> 
> The proxy server will send out MEMBERSHIP and STATUS surveys, that> 
> nodes can respond to; thus new nodes can automagically add themselves> 
> as they come up as well as remove themselves when they restart or> 
> shutdown via MEMBERSHIP. STATUS can be used to provide real-time> 
> load on each node, which will be sent via a __packed__ struct,> 
> ala NTP and other common usage patterns, in which 32bit fields are> 
> converted from endian-ness to network and back. That STATUS info can> 
> be used for "intelligent" load balancing and will provide some> 
> typical server metrics such as memory, # of cpus, etc...> 
> 

smime.p7s
Description: S/MIME cryptographic signature

Server Token: None

[Alex Hautequest]

Can we have an empty SERVER header instead of the minimalistic but yet 
“revealing“ issued by the token when set as Prod? Most people are change this 
header either by patching themselves (and maintaining their patches), or by 
installing extra modules/plugins, but it would be very, very handy if this was 
an option from the main source itself.

I did a quick and dirty patch for the latest release code, and as someone who 
doesn’t code anything past a hello world for quite a few years, it was simple 
enough I’m surprised how nobody cared to do it. Or perhaps this had been 
discussed before and the general consensus was to leave the bare minimum to 
Prod: if so, people that want to keep low would find their ways anyway, but 
giving us choice is not unusual from the spirit of FOSS.

Alex



httpd-server-header-none.diff.gz
Description: GNU Zip compressed data


smime.p7s
Description: S/MIME cryptographic signature