Re: svn commit: r1839920 - /httpd/httpd/trunk/modules/ssl/ssl_private.h
Just wrote a mail. My intention is to have a version that is suitable for back porting. > Am 03.09.2018 um 11:16 schrieb Ruediger Pluem : > > > > On 09/03/2018 11:06 AM, ic...@apache.org wrote: >> Author: icing >> Date: Mon Sep 3 09:06:35 2018 >> New Revision: 1839920 >> >> URL: http://svn.apache.org/viewvc?rev=1839920=rev >> Log: >> On the trunk: >> >> SSL protocl TLSv1.3 no longer part of 'all' when configured. Needs to be >> added explicitly. >> When using 'modern' as SSL policy, TLSv1.3 is enabled. > > What is the purpose of removing it from 'all'? > > Regards > > Rüdiger >
Re: Run httpd's testsuite
Hi Jim! Thanks for the tip, but how can I do that? Following the make file when "make check" is executed would be an option? Regards, Danesh On Sun, Sep 2, 2018 at 9:25 PM Jim Jagielski wrote: > > FWIW, I've never run 'make check' but always run the test suite explicitly. > > > On Sep 2, 2018, at 6:49 AM, Danesh Daroui wrote: > > > > Hi all, > > > > I would like to be bale to run Apache https's testsuite. I have clones > > Apache-Test and configures the project with the given path and then > > built the httpd server, but when I execute "make cheek", all tests for > > "all.t" are skipped. The logs show that the test scripts runs the > > server with some isolated configurations on a specific port but it > > apparently cannot find "mod_perl.c" for instance. This is the last > > part of the log that I get when I run the test: > > > > waiting 60 seconds for server to start: . > > waiting 60 seconds for server to start: ok (waited 0 secs) > > server localhost:8529 started > > [ info] adding source lib > > /home/danesh/open/github/Apache-Test/../Apache-Test/lib to @INC > > t/alltest/all.t . skipped: testing all.t > > t/alltest2/all.t skipped: testing more than one all.t > > t/bad_coding.t .. ok > > t/cookies.t . skipped: cannot find module 'CGI', > > cannot find module 'CGI::Cookie' > > t/import.t .. ok > > t/log_watch.t ... ok > > t/log_watch_for_broken_lines.t .. ok > > t/more/all.t skipped: cannot find module 'mod_perl.c' > > t/next_available_port.t . ok > > t/ping.t ok > > t/redirect.t ok > > t/request.t . ok > > t/sok.t . ok > > All tests successful. > > Files=13, Tests=91, 4 wallclock secs ( 0.05 usr 0.01 sys + 2.17 > > cusr 0.56 csys = 2.79 CPU) > > Result: PASS > > [warning] server localhost:8529 shutdown > > > > There are also some unit tests under "test" directory that they are > > all passed when I run the executable. I would like to know what is the > > difference between these two tests? Also I expected the tests that are > > triggered with "make check" to be much more extensive than some small > > tests that are run quickly. Something like night-run tests! Am I > > missing something? > > > > Regards, > > > > Danesh Daroui >
Re: svn commit: r1839920 - /httpd/httpd/trunk/modules/ssl/ssl_private.h
On 09/03/2018 11:06 AM, ic...@apache.org wrote: > Author: icing > Date: Mon Sep 3 09:06:35 2018 > New Revision: 1839920 > > URL: http://svn.apache.org/viewvc?rev=1839920=rev > Log: > On the trunk: > > SSL protocl TLSv1.3 no longer part of 'all' when configured. Needs to be > added explicitly. > When using 'modern' as SSL policy, TLSv1.3 is enabled. What is the purpose of removing it from 'all'? Regards Rüdiger
TLSv1.3 supprt for 2.4.x?
Dear SSL care takers and stake holders, trunk has TLSv1.3 support for some time. I just now changed the 'all' SSLProtocol selection, so that it does not include TLSv1.3. This means that in order to enable it, admins must add an explicit '+TLSv1.3' to their config (same for SSLProxyProtocl of course). With this, the added support is really an opt-in and we could backport it to 2.4.x, if we want. We have been burned with backporting SSL features just recently (by my mistake), so I would understand that people feel a bit reluctant here. On the other hand, there is certainly interest by users. So, what is your opinion? Cheers, Stefan PS. There are some combinations in renegotiation/client certs that are not tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or at least with a heavy caveat for those setups. But I see no issue with using it for plain-vanilla https: setups.
Re: TLSv1.3 supprt for 2.4.x?
> Am 03.09.2018 um 13:56 schrieb Ruediger Pluem : > > > > On 09/03/2018 01:32 PM, Stefan Eissing wrote: >> >> >>> Am 03.09.2018 um 13:19 schrieb Joe Orton : >>> >>> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: Dear SSL care takers and stake holders, > >> >>> IMO there is no problem with supporting it by default (not needing >>> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >>> enable it at build time, this isn't going to break production users on >>> current systems. >> >> Interesting. If that is consensus, I'd revert my change from earlier today. > > +1 Done in r1839946. Cheers, Stefan
Re: TLSv1.3 supprt for 2.4.x?
+1! for backporting > On Sep 3, 2018, at 5:17 AM, Stefan Eissing > wrote: > > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that > in order to enable it, admins must add an explicit '+TLSv1.3' to their config > (same for SSLProxyProtocl of course). > > With this, the added support is really an opt-in and we could backport it to > 2.4.x, if we want. We have been burned with backporting SSL features just > recently (by my mistake), so I would understand that people feel a bit > reluctant here. On the other hand, there is certainly interest by users. > > So, what is your opinion? > > Cheers, > > Stefan > > PS. There are some combinations in renegotiation/client certs that are not > tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or at > least with a heavy caveat for those setups. But I see no issue with using it > for plain-vanilla https: setups.
Re: TLSv1.3 supprt for 2.4.x?
> Am 03.09.2018 um 13:19 schrieb Joe Orton : > > On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. I just now changed the 'all' >> SSLProtocol selection, so that it does not include TLSv1.3. This means that >> in order to enable it, admins must add an explicit '+TLSv1.3' to their >> config (same for SSLProxyProtocl of course). >> >> With this, the added support is really an opt-in and we could backport it to >> 2.4.x, if we want. We have been burned with backporting SSL features just >> recently (by my mistake), so I would understand that people feel a bit >> reluctant here. On the other hand, there is certainly interest by users. >> >> So, what is your opinion? > > Yes, I just worked on a backport of that set for Fedora, so I'm on board > for pushing & testing that in 2.4.x. Possibly warrants a branch to work > through the merge? We could do that. The patch, right now, is not that large, I think, but a branch does not hurt. >> PS. There are some combinations in renegotiation/client certs that are >> not tested well. Therefore, '+TLSv1.3' should be tagged as >> 'experimental' or at least with a heavy caveat for those setups. But I >> see no issue with using it for plain-vanilla https: setups. > > AIUI the various bits of new API added for TLS/1.3 are not necessarily > stable until there is a final OpenSSL 1.1.1 release, so maybe we should > wait for that first? I think they (or at least the parts we use) have been stable since pre3 in spring. There have been fixes under the hood in timing of callbacks, AFAIK. Since none of these are in any public part of httpd - apart from the protocol config which we alaways be there - I think we could broaden the test audience without much risk. > IMO there is no problem with supporting it by default (not needing > explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to > enable it at build time, this isn't going to break production users on > current systems. Interesting. If that is consensus, I'd revert my change from earlier today. Cheers, Stefan > Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On 09/03/2018 01:32 PM, Stefan Eissing wrote: > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton : >> >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >>> Dear SSL care takers and stake holders, > >> IMO there is no problem with supporting it by default (not needing >> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >> enable it at build time, this isn't going to break production users on >> current systems. > > Interesting. If that is consensus, I'd revert my change from earlier today. +1 Regards Rüdiger
Re: TLSv1.3 supprt for 2.4.x?
Am 03.09.2018 um 13:19 schrieb Joe Orton: AIUI the various bits of new API added for TLS/1.3 are not necessarily stable until there is a final OpenSSL 1.1.1 release, so maybe we should wait for that first? Last mentioned date for GA release of OpenSSL 1.1.1 was Tuesday 11th September. Not sure how fix this it, but at least that would be pretty close. Regards, Rainer
Re: Run httpd's testsuite
The test framework itself is under: https://svn.apache.org/viewvc/httpd/test/framework/trunk/ and is run using: t/TEST > On Sep 3, 2018, at 3:34 AM, Danesh Daroui wrote: > > Hi Jim! > > Thanks for the tip, but how can I do that? Following the make file > when "make check" is executed would be an option? > > Regards, > > Danesh > > On Sun, Sep 2, 2018 at 9:25 PM Jim Jagielski wrote: >> >> FWIW, I've never run 'make check' but always run the test suite explicitly. >> >>> On Sep 2, 2018, at 6:49 AM, Danesh Daroui wrote: >>> >>> Hi all, >>> >>> I would like to be bale to run Apache https's testsuite. I have clones >>> Apache-Test and configures the project with the given path and then >>> built the httpd server, but when I execute "make cheek", all tests for >>> "all.t" are skipped. The logs show that the test scripts runs the >>> server with some isolated configurations on a specific port but it >>> apparently cannot find "mod_perl.c" for instance. This is the last >>> part of the log that I get when I run the test: >>> >>> waiting 60 seconds for server to start: . >>> waiting 60 seconds for server to start: ok (waited 0 secs) >>> server localhost:8529 started >>> [ info] adding source lib >>> /home/danesh/open/github/Apache-Test/../Apache-Test/lib to @INC >>> t/alltest/all.t . skipped: testing all.t >>> t/alltest2/all.t skipped: testing more than one all.t >>> t/bad_coding.t .. ok >>> t/cookies.t . skipped: cannot find module 'CGI', >>> cannot find module 'CGI::Cookie' >>> t/import.t .. ok >>> t/log_watch.t ... ok >>> t/log_watch_for_broken_lines.t .. ok >>> t/more/all.t skipped: cannot find module 'mod_perl.c' >>> t/next_available_port.t . ok >>> t/ping.t ok >>> t/redirect.t ok >>> t/request.t . ok >>> t/sok.t . ok >>> All tests successful. >>> Files=13, Tests=91, 4 wallclock secs ( 0.05 usr 0.01 sys + 2.17 >>> cusr 0.56 csys = 2.79 CPU) >>> Result: PASS >>> [warning] server localhost:8529 shutdown >>> >>> There are also some unit tests under "test" directory that they are >>> all passed when I run the executable. I would like to know what is the >>> difference between these two tests? Also I expected the tests that are >>> triggered with "make check" to be much more extensive than some small >>> tests that are run quickly. Something like night-run tests! Am I >>> missing something? >>> >>> Regards, >>> >>> Danesh Daroui >>
Re: TLSv1.3 supprt for 2.4.x?
On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: > Dear SSL care takers and stake holders, > > trunk has TLSv1.3 support for some time. I just now changed the 'all' > SSLProtocol selection, so that it does not include TLSv1.3. This means that > in order to enable it, admins must add an explicit '+TLSv1.3' to their config > (same for SSLProxyProtocl of course). > > With this, the added support is really an opt-in and we could backport it to > 2.4.x, if we want. We have been burned with backporting SSL features just > recently (by my mistake), so I would understand that people feel a bit > reluctant here. On the other hand, there is certainly interest by users. > > So, what is your opinion? Yes, I just worked on a backport of that set for Fedora, so I'm on board for pushing & testing that in 2.4.x. Possibly warrants a branch to work through the merge? > PS. There are some combinations in renegotiation/client certs that are > not tested well. Therefore, '+TLSv1.3' should be tagged as > 'experimental' or at least with a heavy caveat for those setups. But I > see no issue with using it for plain-vanilla https: setups. AIUI the various bits of new API added for TLS/1.3 are not necessarily stable until there is a final OpenSSL 1.1.1 release, so maybe we should wait for that first? IMO there is no problem with supporting it by default (not needing explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to enable it at build time, this isn't going to break production users on current systems. Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
Speaking of SSL and rare renegotiation setups: Bernard and me are suspecting that libressl has issues here for quite some time. At least it looks that way: https://github.com/libressl-portable/portable/issues/443 Just FYI in case someone encounters such things. > Am 03.09.2018 um 13:32 schrieb Stefan Eissing : > > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton : >> >> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing wrote: >>> Dear SSL care takers and stake holders, >>> >>> trunk has TLSv1.3 support for some time. I just now changed the 'all' >>> SSLProtocol selection, so that it does not include TLSv1.3. This means that >>> in order to enable it, admins must add an explicit '+TLSv1.3' to their >>> config (same for SSLProxyProtocl of course). >>> >>> With this, the added support is really an opt-in and we could backport it >>> to 2.4.x, if we want. We have been burned with backporting SSL features >>> just recently (by my mistake), so I would understand that people feel a bit >>> reluctant here. On the other hand, there is certainly interest by users. >>> >>> So, what is your opinion? >> >> Yes, I just worked on a backport of that set for Fedora, so I'm on board >> for pushing & testing that in 2.4.x. Possibly warrants a branch to work >> through the merge? > > We could do that. The patch, right now, is not that large, I think, but > a branch does not hurt. > >>> PS. There are some combinations in renegotiation/client certs that are >>> not tested well. Therefore, '+TLSv1.3' should be tagged as >>> 'experimental' or at least with a heavy caveat for those setups. But I >>> see no issue with using it for plain-vanilla https: setups. >> >> AIUI the various bits of new API added for TLS/1.3 are not necessarily >> stable until there is a final OpenSSL 1.1.1 release, so maybe we should >> wait for that first? > > I think they (or at least the parts we use) have been stable since pre3 in > spring. There have been fixes under the hood in timing of callbacks, AFAIK. > Since none of these are in any public part of httpd - apart from the > protocol config which we alaways be there - I think we could broaden the > test audience without much risk. > >> IMO there is no problem with supporting it by default (not needing >> explicit +TLSv1.3) in 2.4. Since "bleeding edge OpenSSL" is needed to >> enable it at build time, this isn't going to break production users on >> current systems. > > Interesting. If that is consensus, I'd revert my change from earlier today. > > Cheers, Stefan > >> Regards, Joe
Re: TLSv1.3 supprt for 2.4.x?
On 09/03/2018 09:45 AM, Jim Jagielski wrote: +1! for backporting >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing wrote: >> >> Dear SSL care takers and stake holders, >> >> trunk has TLSv1.3 support for some time. TLSv1.3 is a published protocol and I see no reason why it wouldn't be available in a stable release. https://tools.ietf.org/html/rfc8446 Dennis
