Re: svn commit: r1811831 - /httpd/httpd/trunk/server/util_script.c

[Yann Ylavic]

On Wed, Oct 11, 2017 at 4:48 PM,   wrote:
> Author: jorton
> Date: Wed Oct 11 14:48:55 2017
> New Revision: 1811831
>
> URL: http://svn.apache.org/viewvc?rev=1811831&view=rev
> Log:
> * server/util_script.c (ap_add_common_vars): Allow mod_env to override
>   all system path environment variables, not just PATH.  (The
>   behaviour for PATH alone was changed in r965679 for PR 43906.)

Since SetEnv* are usable from htaccess, don't we open a risky door here?


Regards,
Yann.

Re: svn commit: r1796352

[Yann Ylavic]

On Wed, Apr 4, 2018 at 7:33 PM, Eric Covener  wrote:
> On Wed, Apr 4, 2018 at 1:02 PM, Nick Kew  wrote:
>> On Wed, 4 Apr 2018 10:46:31 -0400
>> Eric Covener  wrote:
>>
>>
>>> What is the correct configuration that doesn't cause htaccess to be
>>> visited?  If it's trunk only, I think it should be an alternate config
>>> mechanism rather than making it incompatible with any other setting in
>>> htaccess.
>>
>> Anything equivalent to the "canonical" example in both the
>> mod_status docs and the shipped httpd-info.conf.in .
>>
>> Note that the latter also implies it can be restricted to
>> an access list, which is misleading if any "Require" can
>> be bypassed through .htaccess.
>>
>> # Allow server status reports generated by mod_status,
>> # with the URL of http://servername/server-status
>> # Change the ".example.com" to match your domain to enable.
>>
>> 
>> SetHandler server-status
>> Require host .example.com
>> Require ip 127
>> 
>>
>
> That configuration has no bearing on whether htaccess files are
> visited for a request to /server-status.
> That's why the taint check is too aggressive in this case.

Couldn't we have a TaintedAction (or so) directive/function which
modules could check (instead of the black or white "is tainted") so
that users can choose? Maybe per module choice or?

We then possibly could be quite relaxed on 2.4 and more aggressive on
trunk, by default.


Regards,
Yann.

Re: TLSv1.3

[Stefan Eissing]

> Am 04.04.2018 um 20:23 schrieb William A Rowe Jr :
> 
> SSLProtocol TLSv1.2 TLSv1.3
> SSLProxyProtocol TLSv1.2 TLSv1.3
> 
> should be syntactically valid, no?

Not sure. Is

> SSLProtocol TLSv1.2 TLSv1.1

valid? On the road right now and cannot test. I agree
that it probably makes sense, but for backport compat
I tried to add TLSv1.3 in the same spirit as the other
protocols.

> 
> [Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid
> 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides
> already set parameter(s). Check if a +/- prefix is missing.
> [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid
> 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3'
> overrides already set parameter(s). Check if a +/- prefix is missing.
> 
> TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers.
> 
> 
> On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing
>  wrote:
>> Just added TLSv1.3 support in trunk. No fancy new early data features, just 
>> the basic.
>> 
>> Open for discussion:
>> - The Mozilla server-side-tls people are still thinking of what they will 
>> recommend, see:
>>   
>> https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933
>> - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will 
>> co-host 1.2 and 1.3
>>   for some time, we need additional config directives, I think. Added 
>> "SSLCipherSuiteV1_3" and
>>   am ashamed of the name.
>> - The current handling of TLS versions that are not supported by the *SSL 
>> lib linked is not
>>   super helpful. It more or less pretends that the version does not exist 
>> (unknown protocol),
>>   but that is far from the truth. Shall we continue that or is this an 
>> opportunity to reconsider?
>> - Should we allow the configuration of TLSv1_3 ciphers, even if the linked 
>> SSL does not support
>>   it? This is different from SSLProtocol which of course needs to fail if it 
>> cannot enable the
>>   version that is explicitly configured.
>>   I think it is ok to take it into the config, even though it never 
>> activates.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if 
>> trunk compiles with it. I would not stop him.
>>