On 18.11.2011 06:32, Kaspar Brand wrote:
As I can't think of any good reason why a new major version of an HTTPS
server released in late 2011 should still support insecure SSL protocol
cruft from the 1990s (v2 was superseded about 15 years ago, when SSLv3
was introduced), I went for the first opt
Hi all,
Right now, we only keep track of the real IP address of the incoming
connection within conn_rec, and with a simple webserver that's fine.
In a world containing load balancers, we now have the real IP address
(the load balancer) and the effective IP address (the IP that
connected t
On Fri, Nov 18, 2011 at 8:24 AM, Graham Leggett wrote:
> Hi all,
>
> Right now, we only keep track of the real IP address of the incoming
> connection within conn_rec, and with a simple webserver that's fine.
>
> In a world containing load balancers, we now have the real IP address (the
> load bal
On 18 Nov 2011, at 4:05 PM, Jeff Trawick wrote:
A. modules keep using conn_rec, core keeps track of TCP peer for
logging, post-read-request or some other per-request hook used to set
effective client in conn_rec
ugly updates to conn_rec by some module; client is really per-request
in some confi
On 18.11.2011 13:09, Rainer Jung wrote:
> You might want to drop the -SSLv2 from our SSLCipherSuite in
> docs/conf/extra/httpd-ssl.conf.in then as well.
You're right, yes. As there were no objections to the changes I proposed
on the list a few days ago, I now committed them with r1203752/r1203753
On 18.11.2011 18:20, Kaspar Brand wrote:
On 18.11.2011 13:09, Rainer Jung wrote:
You might want to drop the -SSLv2 from our SSLCipherSuite in
docs/conf/extra/httpd-ssl.conf.in then as well.
You're right, yes. As there were no objections to the changes I proposed
on the list a few days ago, I n
On 18 Nov 2011, at 4:23 PM, Graham Leggett wrote:
The lines I was thinking along was that effective_ip was in addition
to the remote_ip, rather than instead of. The log format wouldn't
change, there would be a new value that would represent the
effective IP, in addition to the existing valu
On Tue, Nov 15, 2011 at 10:51 AM, wrote:
>
> Log:
> Create a new lock free circular queue, and use it in the EventMPM to
> remove the timeout mutex that was wrapping both timeout queue operations
> and pollset operations.
>
> @@ -1632,6 +1672,20 @@ static void * APR_THREAD_FUNC listener_t
>
Hi together,
I'm messing around with a strange bug now for a few days:
When enabling mod_cache in my reverse-proxy scenario, the first file
with a filesize above some threshold gets delivered corrupted,
subsequent requests served from cache are fine.
I noticed it first with some broken images a
On Fri, Nov 18, 2011 at 2:43 PM, Greg Ames wrote:
>
>
> On Tue, Nov 15, 2011 at 10:51 AM, wrote:
>>
>> Log:
>> Create a new lock free circular queue, and use it in the EventMPM to
>> remove the timeout mutex that was wrapping both timeout queue operations and
>> pollset operations.
>>
>> @@ -1632
On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick wrote:
>
> Try this:
>
> Index: server/mpm/event/event.c
> ===
> --- server/mpm/event/event.c(revision 1203816)
> +++ server/mpm/event/event.c(working copy)
> @@ -1483,9 +1483,9 @
Hi,
in case any of you also have lots of test failures with libwww-perl 6.0.3,
setting these env vars fixes most of them for me:
PERL_NET_HTTPS_SSL_SOCKET_CLASS=Net::SSL
PERL_LWP_SSL_VERIFY_HOSTNAME=0
No idea why Net::SSL works but IO::Socket::SSL doesn't. The remaining
failures are
On Fri, Nov 18, 2011 at 4:06 PM, Greg Ames wrote:
>
>
> On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick wrote:
>>
>> Try this:
>>
>> Index: server/mpm/event/event.c
>> ===
>> --- server/mpm/event/event.c (revision 1203816)
>> +++ se
On Fri, Nov 18, 2011 at 4:38 PM, Jeff Trawick wrote:
>
> > but my fears about the performance of the design seem to be confirmed.
> my
> > fastest run so far with trunk + this patch,
> >
> > Requests per second:7749.66 [#/sec] (mean)
>
> backing up to the prior state (with the mutex), it woul
After several prods, it seems the security@ and hackathon participants
can't be drawn out of their shells on to dev@. So I'll simply call for
a majority vote on the following statement...
Resource abuse of an .htaccess config in the form of cpu/memory/bandwidth;
[ ] Represents a security def
On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote:
After several prods, it seems the security@ and hackathon participants
can't be drawn out of their shells on to dev@. So I'll simply call
for
a majority vote on the following statement...
Resource abuse of an .htaccess config in the fo
On Sat, 2011-11-19 at 01:46 +0200, Graham Leggett wrote:
> On 19 Nov 2011, at 12:38 AM, William A. Rowe Jr. wrote:
>
> > After several prods, it seems the security@ and hackathon participants
> > can't be drawn out of their shells on to dev@. So I'll simply call
> > for
> > a majority vote on
On 18 Nov 2011, at 9:50 PM, f_los_ch wrote:
When enabling mod_cache in my reverse-proxy scenario, the first file
with a filesize above some threshold gets delivered corrupted,
subsequent requests served from cache are fine.
Can you confirm if the following patch makes any difference for you? I
On 11/11/2011 10:49 AM, William A. Rowe Jr. wrote:
On approval of this plan, I would offer to introduce the EOL notices
(as we ultimately committed to 1.3), tag and roll 2.0.65 on Nov 26th
and we would potentially approve and release 2.0 'final' this month.
I have responded to all negative com
On Friday 18 November 2011, William A. Rowe Jr. wrote:
> Resource abuse of an .htaccess config in the form of
> cpu/memory/bandwidth;
>
>[ ] Represents a security defect
>[X] Is not a security defect
>
> This would obviously need to be clarified in the associated
> .htaccess documentati
On Friday 18 November 2011, Graham Leggett wrote:
> > besides the ugliness of updating conn_rec, are there known
> > functional drawbacks of the existing mechanism, assuming that
> > the module which sets the client also sets a note to allow
> > logging of the TCP peer if desired?
There is also th
Nevermind that you failed to be consistent in tag values between
logging schemas... nothing in this proposal addresses the reason
that I myself had implemented mod_remoteip, which was authn/authz
control. In the limited scenario you have considered, authn is
pretty much a noop on the physical add
On Friday 18 November 2011, Kaspar Brand wrote:
> "all" simply stands for "+SSLv3 +TLSv1",
> so we might just leave the default config as is - i.e., not have
> any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf.
We may have "TLSv1.1" "and TLSv1.2" in the future. Changing the
default con
On Fri, Nov 18, 2011 at 10:05 PM, Stefan Fritsch wrote:
> On Friday 18 November 2011, Kaspar Brand wrote:
>> "all" simply stands for "+SSLv3 +TLSv1",
>> so we might just leave the default config as is - i.e., not have
>> any SSLProtocol directive in docs/conf/extra/httpd-ssl.conf.
>
> We may have
On 18.11.2011 18:47, Rainer Jung wrote:
> Fine with me. Current SSLCipherSuite for 2.2 definitely needs
> improvement and latest 2.4 should be the way to go.
>
> Except: Since SSLv2 is still available for 2.2, the -SSLv2 is needed in
> the cipher list.
>
> Please feel free to go ahead an remove
25 matches
Mail list logo