Re: svn commit: r1834898 - /httpd/httpd/branches/2.4.x/STATUS
On Mon, Jul 2, 2018 at 11:08 PM, Eric Covener wrote: >> So, just proposing, is my only contribution in such a case. >> Hoping it helps. > > pointing out these lost revisions is very helpful! +1
Re: svn commit: r1834898 - /httpd/httpd/branches/2.4.x/STATUS
> So, just proposing, is my only contribution in such a case. > Hoping it helps. pointing out these lost revisions is very helpful!
Re: svn commit: r1834898 - /httpd/httpd/branches/2.4.x/STATUS
Le 02/07/2018 à 22:51, drugg...@apache.org a écrit :
+ druggeri: Why no +1, jallietc36?
+
I vote when I can test or when trivial enough.
But it does not prevent me from proposing what looks interesting, so
that the other ones, with more technical background or experience than
me, have a change to vote and backport it, if my intuition (or in this
particular case, the log message) is correct.
In such a case, just running the test framework is not enough, IMHO. One
need a deeper understanding of what is changed (what can be the
consequences of inserting an error bucket? Should be none, but...). It
also looks not that easy to test and trigger the issue (" When a
post-handshake check fails"...).
This could look trivial, but the devil is in the detail (and mod_ssl is
a to big beast for me, with too many differences between 2.4.x and trunk
(but easy backport proposal are on the way :))
So, just proposing, is my only contribution in such a case.
Hoping it helps.
CJ
Re: svn commit: r1834671 - in /httpd/httpd/branches/2.4.x: CHANGES docs/manual/mod/mod_md.xml modules/md/md_crypt.c modules/md/md_json.c modules/md/md_version.h modules/md/mod_md.c modules/md/mod_md_c
Le 02/07/2018 à 17:36, William A Rowe Jr a écrit : On Mon, Jul 2, 2018 at 8:25 AM, Stefan Eissing mailto:stefan.eiss...@greenbytes.de>> wrote: I thought experimental == CTR, but if this is separate then I‘ll go through the votes. Just let me know what you prefer. I basically thought the same thing, but it is clearly spelled out in STATUS. We aught to adjust this to reflect the eventual consensus; * Current exceptions for RTC for this branch: . mod_proxy_http2 . mod_lua . documentation . non-Unix build . non-Unix, single-platform code I don't have a strong opinion about it, that's why I proposed to update STATUS to add an exception for mod_md? (or maybe even for any module marked as experimental?) A grep in 2.4.x, shows the following modules marked as Experimental: mod_allowmethods.xml:Experimental mod_dialup.xml:Experimental mod_echo.xml:Experimental mod_example_hooks.xml:Experimental mod_file_cache.xml:Experimental mod_heartbeat.xml:Experimental mod_heartmonitor.xml:Experimental mod_lbmethod_heartbeat.xml:Experimental mod_log_debug.xml:Experimental mod_lua.xml:Experimental mod_privileges.xml:Experimental mod_sed.xml:Experimental mod_session_crypto.xml:Experimental I suspect, that some should not be marked as Experimental anymore. mod_md and mod_proxy_http2 don't have an Experimental status, only a red-lined warning at the beginning of its doc. Maybe something should be added in the module list to easily spot the one with an Experimental status and a note explaining what this mean. (i.e., if I'm correct, the code is considered as stable, but its implementation and/or API and/or directives are subject to change in future release) CJ
Re: svn commit: r1834671 - in /httpd/httpd/branches/2.4.x: CHANGES docs/manual/mod/mod_md.xml modules/md/md_crypt.c modules/md/md_json.c modules/md/md_version.h modules/md/mod_md.c modules/md/mod_md_c
On Mon, Jul 2, 2018 at 8:25 AM, Stefan Eissing wrote: > I thought experimental == CTR, but if this is separate then I‘ll go > through the votes. Just let me know what you prefer. I basically thought the same thing, but it is clearly spelled out in STATUS. We aught to adjust this to reflect the eventual consensus; * Current exceptions for RTC for this branch: . mod_proxy_http2 . mod_lua . documentation . non-Unix build . non-Unix, single-platform code
Re: svn commit: r1834671 - in /httpd/httpd/branches/2.4.x: CHANGES docs/manual/mod/mod_md.xml modules/md/md_crypt.c modules/md/md_json.c modules/md/md_version.h modules/md/mod_md.c modules/md/mod_md_c
I thought experimental == CTR, but if this is separate then I‘ll go through the votes. Just let me know what you prefer. > Am 29.06.2018 um 21:31 schrieb Christophe Jaillet > : > >> Le 29/06/2018 à 13:53, ic...@apache.org a écrit : >> Author: icing >> Date: Fri Jun 29 11:53:50 2018 >> New Revision: 1834671 >> URL: http://svn.apache.org/viewvc?rev=1834671=rev >> Log: >> On the 2.4.x branch: >> backport of current mod_md version and documentation. >> Modified: >> httpd/httpd/branches/2.4.x/CHANGES >> httpd/httpd/branches/2.4.x/docs/manual/mod/mod_md.xml >> httpd/httpd/branches/2.4.x/modules/md/md_crypt.c >> httpd/httpd/branches/2.4.x/modules/md/md_json.c >> httpd/httpd/branches/2.4.x/modules/md/md_version.h >> httpd/httpd/branches/2.4.x/modules/md/mod_md.c >> httpd/httpd/branches/2.4.x/modules/md/mod_md_config.c > > Hi, > > according to 2.4.x/STATUS, mod_md is not CTR. > Maybe, STATUS should be updated to add an exception for mod_md? (or maybe > even for any module marked as experimental?) > Otherwise, this should go through STATUS first. > > CJ
AW: svn commit: r1682074 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/ssl/ssl_engine_init.c
> -Ursprüngliche Nachricht- > Von: Christophe Jaillet > Gesendet: Samstag, 30. Juni 2018 14:08 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1682074 - in /httpd/httpd/branches/2.4.x: ./ > STATUS modules/ssl/ssl_engine_init.c > > Le 27/05/2015 à 18:33, wr...@apache.org a écrit : > > Author: wrowe > > Date: Wed May 27 16:33:10 2015 > > New Revision: 1682074 > > > > URL: http://svn.apache.org/r1682074 > > Log: > > mod_ssl: fix small memory leak in ssl_init_server_certs when ECDH is > used. > > SSL_CTX_set_tmp_ecdh increases reference count, so we have to call > > EC_KEY_free, otherwise eckey will not be freed. > > > > Backports: r1666363 > > Author: jkaluza > > Reviewed by: rjung, ylavic, wrowe > > > > Hi, > > This backport looks incomplete. > > In the original patch (r1666363) we have: > @@ -1151,10 +1151,11 @@ > #if defined(SSL_CTX_set_ecdh_auto) > SSL_CTX_set_ecdh_auto(mctx->ssl_ctx, 1); > #else > -SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, > - > EC_KEY_new_by_curve_name(NID_X9_62_prime256v1)); > +eckey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); > +SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey); > which is not in the backported code. (neither in the .patch file, nor in > the backport itself) > > Was it intentional or should the missing part be also backported? > My feeling is that it should be merged. I agree that this part should be merged as well. Regards Rüdiger
