Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-16 Thread olli hauer
On 2015-06-16 13:39, Yann Ylavic wrote: On Mon, Jun 15, 2015 at 7:24 PM, olli hauer oha...@gmx.de wrote: As a side note, even I've read the Release Notes I was thankful to see my console was trashed with the deprecation warning ;) What I miss is a section on httpd.apache.org/docs/2.4/ with

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-16 Thread Yann Ylavic
On Mon, Jun 15, 2015 at 7:24 PM, olli hauer oha...@gmx.de wrote: As a side note, even I've read the Release Notes I was thankful to see my console was trashed with the deprecation warning ;) What I miss is a section on httpd.apache.org/docs/2.4/ with a link list what has changed since

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Eric Covener
Anyone else inclined to just remove the message? It's a deprecation that didn't happen on a release boundary. AFAICT there's no reason to change how you run your server unless you use two different cert chains and then you'd find the info in the manual. On Mon, Jun 15, 2015 at 8:57 AM Jim

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Jim Jagielski
Well, we have time now to Do This Right in 2.4.15, so On Jun 14, 2015, at 9:43 PM, Noel Butler noel.but...@ausics.net wrote: On 15/06/2015 07:56, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@gknw.net wrote:

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Jim Jagielski
On Jun 15, 2015, at 9:12 AM, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? I'm +1 for that.

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread William A Rowe Jr
On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? It's a deprecation that didn't happen on a release boundary. AFAICT there's no reason to change how you run your server unless you use two different cert chains and then

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Jeff Trawick
On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? It's a deprecation that didn't happen on a release boundary. AFAICT there's no reason to

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Tim Bannister
On 15 June 2015 14:12:27 UTC+01:00, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? It's a deprecation that didn't happen on a release boundary. AFAICT there's no reason to change how you run your server unless you use two different cert chains and then you'd

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-15 Thread olli hauer
On 2015-06-15 03:36, Gregg Smith wrote: On 6/14/2015 6:14 PM, Gregg Smith wrote: On 6/14/2015 2:56 PM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@gknw.net wrote: http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff I'm fine with this

Re: SSLCertificateChainFile deprecation, still

2015-06-15 Thread Jeff Trawick
On Mon, Jun 15, 2015 at 11:10 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Jun 15, 2015 at 10:54 AM, William A Rowe Jr wr...@rowe-clan.net wrote: On Mon, Jun 15, 2015 at 8:12 AM, Eric Covener cove...@gmail.com wrote: Anyone else inclined to just remove the message? It's a deprecation

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-14 Thread Gregg Smith
On 6/14/2015 2:54 AM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 11:29 AM,gsm...@apache.org wrote: Author: gsmith Date: Sun Jun 14 09:29:50 2015 New Revision: 1685371 URL: http://svn.apache.org/r1685371 Log: -1 vote w/ comment Modified: httpd/httpd/branches/2.4.x/STATUS Modified:

SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-14 Thread Yann Ylavic
On Sun, Jun 14, 2015 at 11:29 AM, gsm...@apache.org wrote: Author: gsmith Date: Sun Jun 14 09:29:50 2015 New Revision: 1685371 URL: http://svn.apache.org/r1685371 Log: -1 vote w/ comment Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL:

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-14 Thread Yann Ylavic
On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@gknw.net wrote: http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff I'm fine with this approach too. We have to decide whether a single [warn] is acceptable or not since it may still confuse startup monitors, which

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-14 Thread Gregg Smith
On 6/14/2015 6:14 PM, Gregg Smith wrote: On 6/14/2015 2:56 PM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@gknw.net wrote: http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff I'm fine with this approach too. We have to decide whether a

Re: SSLCertificateChainFile deprecation, still

2015-06-14 Thread Noel Butler
On 15/06/2015 07:56, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smith g...@gknw.net wrote: http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff [1] I'm fine with this approach too. We have to decide whether a single [warn] is acceptable

Re: SSLCertificateChainFile deprecation, still (was: svn commit: r1685371 - /httpd/httpd/branches/2.4.x/STATUS)

2015-06-14 Thread Gregg Smith
On 6/14/2015 2:56 PM, Yann Ylavic wrote: On Sun, Jun 14, 2015 at 1:31 PM, Gregg Smithg...@gknw.net wrote: http://people.apache.org/~gsmith/proposal/sslcertificatechainfile_compromise.diff I'm fine with this approach too. We have to decide whether a single [warn] is acceptable or not since it