Re: Wherefor 2.4.36?
On 07/08/2018 03:37, William A Rowe Jr wrote: > It appears 2.4.35 is unusable, as other distributors also paused to start > hauling in regression fixes as they eh? unusable? I have rooms full of them with no errors or problems -- Kind Regards, Noel Butler This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents Links: -- [1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
Re: Wherefor 2.4.36?
> On Aug 6, 2018, at 1:37 PM, William A Rowe Jr wrote: > > Is anyone else disappointed in the number of regressions in 2.4.35? > Could you point them out?
Re: Wherefor 2.4.36?
On Mon, Aug 6, 2018 at 12:37 PM, William A Rowe Jr wrote: > Is anyone else disappointed in the number of regressions in 2.4.35? > > Is anyone else interested in releasing 2.4.36 promptly with no new > features or enhancements which may cause 2.4.36 to be similarly unusable? > Which backports or reversions of new code are still needed to get to that > point? > > s/2.4.36/2.4.35/; s/2.4.35/2.4.34/; Sorry, I jumped over 2.4.34 so quickly after the chunking regression that my numbering is already out of whack.
Wherefor 2.4.36?
Is anyone else disappointed in the number of regressions in 2.4.35? Is anyone else interested in releasing 2.4.36 promptly with no new features or enhancements which may cause 2.4.36 to be similarly unusable? Which backports or reversions of new code are still needed to get to that point? It appears 2.4.35 is unusable, as other distributors also paused to start hauling in regression fixes as they become clear, to make some sort of usable 2.4.35.1 private label source and binary packages, each one different than another. There is no corresponding source release from the ASF; that's a problem. And if it continues, that's a board level problem. If distributors continue to ship a usable 2.4.x to end users, while the ASF does not, we fail in our mission of delivering open *source* to our community at no charge, and our claim that the current release of 2.4.x is the best available version. Suggestions such as below are what I'm suggesting be frozen out of the release branch in the short term, until we have one GA-quality point release for users to consume. On Wed, Aug 1, 2018 at 7:54 AM, wrote: > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/ > STATUS?rev=1837233=1837232=1837233=diff > > == > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Wed Aug 1 12:54:54 2018 > @@ -186,6 +186,17 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >2.4.x patch: http://home.apache.org/~jim/patches/client64.patch >+1: jim, > > + *) Add in mod_socache_redis from trunk > + trunk: http://svn.apache.org/r1768070 > + http://svn.apache.org/r1768120 > + http://svn.apache.org/r1768225 > + http://svn.apache.org/r1769712 > + http://svn.apache.org/r1769737 > + http://svn.apache.org/r1774610 > + http://svn.apache.org/r1828624 > + 2.4.x patch: http://home.apache.org/~jim/ > patches/socache_redis.patch > + +1: jim, > + > PATCHES/ISSUES THAT ARE BEING WORKED >[ New entries should be added at the START of the list ] > > > >
Re: svn commit: r1837435 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_init.c
Hi Stefan,
On Mon, Aug 6, 2018 at 1:47 PM, ste...@eissing.org wrote:
> Yann and Rüdiger, looking at this, I am thinking about how to improve
> mod_md's init of openssl. Basically, if mod_ssl + mod_md is loaded,
> mod_md does not have to do anything, it seems.
>
> However, there is a slim chance that someone has another ssl module
> (or none?) and what should mod_md do then? I can copy the crypto
> parts of the pre_config and cleanup code, but given the ever
> increasing version number checks...is there a better way?
I'm currently working on changing APR's apu_dso_load() so that it can
work on the given pool (user controlled lifetime) and also
(optionally) init/deinit the lib.
This is needed (I think) for APR's self handling of its DSOs (focusing
on apr_crypto and openssl for now).
With this in e.g. APR 1.7 (at best), we can simply call
apr_crypto_load_lib("openssl") in each module using openssl like we
currently do in trunk (the dynamic linking part in APR trunk is
currently being disputed, so I'm on the DSO way now...).
Anyway we can't mandate APR 1.7 (at best) in httpd, so I was thinking
of copying interesting bits of apu_dso_load() into e.g. ap_dso_load()
(or a more openssl only version of it), so that it works in httpd with
earlier APR versions too.
So we'd configure, build and install something like
"mod_ssl_openssl.so/dll" (itself dynamically linked with
libcrypto/ssl), that is when a module needs it. Thus we'd
ap_dso_load() it in mod_ssl/md/session/... at pre_config time so that
the load/unload and init/deinit work once for all according to the
given pool (usually the same one, pconf).
Would that work for you?
I'm not too far from having something for APR, and expecting the ap_
part to be quite straight forward (and mostly copy/paste).
Possibly something this week, otherwise after my vacations (more about
septembre)...
Regards,
Yann.
Re: svn commit: r1837435 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_init.c
Yann and Rüdiger, looking at this, I am thinking about how to improve mod_md's
init of openssl. Basically, if mod_ssl + mod_md is loaded, mod_md does not have
to do anything, it seems.
However, there is a slim chance that someone has another ssl module (or none?)
and what should mod_md do then? I can copy the crypto parts of the pre_config
and cleanup code, but given the ever increasing version number checks...is
there a better way?
-Stefan
> Am 04.08.2018 um 19:17 schrieb yla...@apache.org:
>
> Author: ylavic
> Date: Sat Aug 4 17:17:03 2018
> New Revision: 1837435
>
> URL: http://svn.apache.org/viewvc?rev=1837435=rev
> Log:
> mod_ssl: OpenSSL now initializes fully through APR, use that.
>
> Follow up to r1833368 and r1833452.
>
> Modified:
>httpd/httpd/trunk/modules/ssl/mod_ssl.c
>httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
>
> Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1837435=1837434=1837435=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
> +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Sat Aug 4 17:17:03 2018
> @@ -342,6 +342,7 @@ static int modssl_is_prelinked(void)
> return 0;
> }
>
> +#if !USE_APR_CRYPTO_LIB_INIT
> static apr_status_t ssl_cleanup_pre_config(void *data)
> {
> /*
> @@ -397,47 +398,31 @@ static apr_status_t ssl_cleanup_pre_conf
> */
> return APR_SUCCESS;
> }
> +#endif /* !USE_APR_CRYPTO_LIB_INIT */
>
> static int ssl_hook_pre_config(apr_pool_t *pconf,
>apr_pool_t *plog,
>apr_pool_t *ptemp)
> {
> -#if USE_APR_CRYPTO_LIB_INIT
> -apr_status_t rv;
> -#endif
> -
> #if HAVE_VALGRIND
> ssl_running_on_valgrind = RUNNING_ON_VALGRIND;
> #endif
> modssl_running_statically = modssl_is_prelinked();
>
> -/* Some OpenSSL internals are allocated per-thread, make sure they
> - * are associated to the/our same thread-id until cleaned up.
> - */
> -#if APR_HAS_THREADS && MODSSL_USE_OPENSSL_PRE_1_1_API
> -ssl_util_thread_id_setup(pconf);
> -#endif
> -
> #if USE_APR_CRYPTO_LIB_INIT
> -/* When mod_ssl is builtin, no need to unload openssl on restart */
> -rv = apr_crypto_lib_init("openssl", NULL, NULL,
> - modssl_running_statically ? ap_pglobal : pconf);
> -if (rv == APR_SUCCESS || rv == APR_EREINIT) {
> -/* apr_crypto inits libcrypto only, so in any case init libssl here,
> - * each time if openssl is unloaded with pconf, but only once if
> - * mod_ssl is builtin.
> +{
> +/* When mod_ssl is builtin, no need to unload openssl on restart,
> + * so use pglobal.
> */
> -if (!modssl_running_statically
> -|| !ap_retained_data_get("ssl_hook_pre_config")) {
> -if (modssl_running_statically) {
> -ap_retained_data_create("ssl_hook_pre_config", 1);
> -}
> -SSL_load_error_strings();
> -SSL_library_init();
> +apr_pool_t *p = modssl_running_statically ? ap_pglobal : pconf;
> +apr_status_t rv = apr_crypto_lib_init("openssl", NULL, NULL, p);
> +if (rv != APR_SUCCESS && rv != APR_EREINIT) {
> +ap_log_perror(APLOG_MARK, APLOG_ERR, rv, pconf, APLOGNO()
> + "mod_ssl: can't initialize OpenSSL library");
> +return !OK;
> }
> }
> -else
> -#endif
> +#else /* USE_APR_CRYPTO_LIB_INIT */
> {
> /* We must register the library in full, to ensure our configuration
> * code can successfully test the SSL environment.
> @@ -456,6 +441,7 @@ static int ssl_hook_pre_config(apr_pool_
> #endif
> OpenSSL_add_all_algorithms();
> OPENSSL_load_builtin_modules();
> +
> SSL_load_error_strings();
> SSL_library_init();
>
> @@ -466,6 +452,16 @@ static int ssl_hook_pre_config(apr_pool_
>apr_pool_cleanup_null);
> }
>
> +#if APR_HAS_THREADS && MODSSL_USE_OPENSSL_PRE_1_1_API
> +/* Some OpenSSL internals are allocated per-thread, make sure they
> + * are associated to the/our same thread-id until cleaned up. Then
> + * initialize all the thread locking stuff needed by the lib.
> + */
> +ssl_util_thread_id_setup(pconf);
> +ssl_util_thread_setup(pconf);
> +#endif
> +#endif /* USE_APR_CRYPTO_LIB_INIT */
> +
> if (OBJ_txt2nid("id-on-dnsSRV") == NID_undef) {
> (void)OBJ_create("1.3.6.1.5.5.7.8.7", "id-on-dnsSRV",
> "SRVName otherName form");
>
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?rev=1837435=1837434=1837435=diff
> ==
> ---
[PATCH 62599] support for registering a token binding handler
Hi, I'd like to see a patch included in mod_ssl that enables handling of the token binding protocol as defined in the soon-to-be-RFC-ed: https://www.ietf.org/id/draft-ietf-tokbind-https The token binding functionality itself can be implemented in a 3rd party modules like https://github.com/zmartzone/mod_token_binding/ which depends on: https://github.com/google/token_bind except that somehow mod_ssl somehow needs to call into the token binding implementation code to allow it to register itself for the Token Binding TLS extension. Patch 62599 does that, see: https://bz.apache.org/bugzilla/show_bug.cgi?id=62599 However, that mod_ssl patch is not token binding specific and there may be a more generic way of enabling handling of TLS extensions in 3rd-party code, hence my request for a discussion/review. Regards, Hans. -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
