Re: The drive for 2.4.26

2017-05-03 Thread Jan Ehrhardt
Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38 +0200): >Thanks for the analysis. So the following patch on trunk works for me >when using OpenSSL 1.0.1e (on Solaris 10): > >Index: support/ab.c >=== >---

Re: SSL and Usability and Safety

2017-05-03 Thread Issac Goldstand
On 5/3/2017 4:28 PM, Stefan Eissing wrote: > >> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik : >> >>> >>> On 3 May 2017, at 15:14, Issac Goldstand wrote: >>> >>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: > On 3 May 2017, at

Re: SSL and Usability and Safety

2017-05-03 Thread Issac Goldstand
On 5/3/2017 4:22 PM, Dirk-Willem van Gulik wrote: > >> On 3 May 2017, at 15:14, Issac Goldstand wrote: >> >> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: >>> On 3 May 2017, at 14:53, Issac Goldstand > wrote:

Re: SSL and Usability and Safety

2017-05-03 Thread Stefan Eissing
> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik : > >> >> On 3 May 2017, at 15:14, Issac Goldstand wrote: >> >> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: >>> On 3 May 2017, at 14:53, Issac Goldstand

Re: SSL and Usability and Safety

2017-05-03 Thread Dirk-Willem van Gulik
> On 3 May 2017, at 15:14, Issac Goldstand wrote: > > On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: >> >>> On 3 May 2017, at 14:53, Issac Goldstand >> > wrote: >>> >>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik

Re: SSL and Usability and Safety

2017-05-03 Thread Issac Goldstand
On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: > >> On 3 May 2017, at 14:53, Issac Goldstand > > wrote: >> >> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote: >>> On 3 May 2017, at 10:03, Issac Goldstand >>

Re: SSL and Usability and Safety

2017-05-03 Thread Dirk-Willem van Gulik
> On 3 May 2017, at 14:53, Issac Goldstand wrote: > > On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote: >> On 3 May 2017, at 10:03, Issac Goldstand wrote: >>> >>> +1 on the idea >>> >>> So far I'm -0 about all of the proposed implementations for 2

Re: SSL and Usability and Safety

2017-05-03 Thread Issac Goldstand
On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote: > On 3 May 2017, at 10:03, Issac Goldstand wrote: >> >> +1 on the idea >> >> So far I'm -0 about all of the proposed implementations for 2 reasons: >> >> 1) Mr and Mrs normal (whom are our primary customers in the original

Re: SSL Policy Definitions

2017-05-03 Thread Dirk-Willem van Gulik
> On 3 May 2017, at 14:09, Graham Leggett wrote: > > On 03 May 2017, at 2:01 PM, Stefan Eissing > wrote: > >> We seem to all agree that a definition in code alone will not be good >> enough. People need to be able to see what is actually in

Re: SSL Policy Definitions

2017-05-03 Thread Stefan Eissing
> Am 03.05.2017 um 14:20 schrieb Luca Toscano : > > Hi Graham, > > 2017-05-03 14:09 GMT+02:00 Graham Leggett : > On 03 May 2017, at 2:01 PM, Stefan Eissing > wrote: > > > We seem to all agree that a definition in code

SSL Policy Merging

2017-05-03 Thread Stefan Eissing
How will SSL Policies be applied? > Am 03.05.2017 um 12:08 schrieb Stefan Eissing : > > b. There is discussion about the impact on config merging: > >> Am 02.05.2017 um 19:28 schrieb Rainer Jung : >> a) in order of occurrence in the config

Re: SSL Policy Definitions

2017-05-03 Thread Luca Toscano
Hi Graham, 2017-05-03 14:09 GMT+02:00 Graham Leggett : > On 03 May 2017, at 2:01 PM, Stefan Eissing > wrote: > > > We seem to all agree that a definition in code alone will not be good > enough. People need to be able to see what is actually in

Re: SSL Policy Definitions

2017-05-03 Thread Graham Leggett
On 03 May 2017, at 2:01 PM, Stefan Eissing wrote: > We seem to all agree that a definition in code alone will not be good enough. > People need to be able to see what is actually in effect. I think we’re overthinking this. We only need to document the settings

SSL Policy Definitions

2017-05-03 Thread Stefan Eissing
Coming back how we would want to define SSL Security Policies: > Am 03.05.2017 um 12:08 schrieb Stefan Eissing : > 3. Place of Definition > -- > Code vs. Config Files vs. Macros vs. "Owned Macros" > >> Am 03.05.2017 um 00:48 schrieb Jacob

Re: SSL Policies

2017-05-03 Thread Stefan Eissing
> Am 03.05.2017 um 12:08 schrieb Stefan Eissing : > Whatever categories we define where etc. I think we can agree that > a. Security policy needs to be an opt-in. No existing config will change > unless the user choses a policy. > b. One value of policy names is

Re: SSL and Usability and Safety

2017-05-03 Thread Stefan Eissing
I try to summarise the many replies (and thanks for the interest!), to sketch out a possible path forward. 1. Overall -- Replies in general have been very positive. wr...@rowe-clan.net: "I like the proposal." rainer.j...@kippdata.de: "I like the idea."

Re: SSL and Usability and Safety

2017-05-03 Thread Dirk-Willem van Gulik
On 3 May 2017, at 10:03, Issac Goldstand wrote: > > +1 on the idea > > So far I'm -0 about all of the proposed implementations for 2 reasons: > > 1) Mr and Mrs normal (whom are our primary customers in the original > proposal) usually download Apache from their distro or

Re: SSL and Usability and Safety

2017-05-03 Thread Ben Laurie
On 3 May 2017 at 09:03, Issac Goldstand wrote: > What would work, in my eyes, if people are open to it, is treating the > contents of these definitions/macros (and I'm all for the macros, just > so that interested sysadmins can see *exactly* what the settings are on > their

Re: SSL and Usability and Safety

2017-05-03 Thread Issac Goldstand
+1 on the idea So far I'm -0 about all of the proposed implementations for 2 reasons: 1) Mr and Mrs normal (whom are our primary customers in the original proposal) usually download Apache from their distro or some other binary. Their Apache sources are usually not up-to-date, and in the

Re: SSL and Usability and Safety

2017-05-03 Thread Luca Toscano
2017-05-03 2:29 GMT+02:00 Graham Leggett : > On 02 May 2017, at 3:19 PM, Stefan Eissing > wrote: > > How can we help Mr and Ms Normal to stay up to date on these things? > > - We cannot rewrite their config unasked. We need to be backward >