You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2019/07/09 09:57:00 UTC
mod_md v2.0.x + mod_ssl backport
mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support and offers various monitoring possibilities for admins to see what is going on. But...it really needs votes for a mod_ssl related backport:
mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's optional functions.
Without this, the new TLS challenge will not work and people still need to rely on port 80. I heard from one user whose ISP is blocking incoming port 80 (everything can be reasoned with "security" nowadays). So, for some, this is really vital.
I'd appreciate if some would find the time for a vote.
Cheers, Stefan
Re: mod_md v2.0.x + mod_ssl backport
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 09.07.2019 um 13:28 schrieb Joe Orton <jo...@redhat.com>:
>
> On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
>> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support and offers various monitoring possibilities for admins to see what is going on. But...it really needs votes for a mod_ssl related backport:
>>
>> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's optional functions.
>>
>> Without this, the new TLS challenge will not work and people still need to rely on port 80. I heard from one user whose ISP is blocking incoming port 80 (everything can be reasoned with "security" nowadays). So, for some, this is really vital.
>>
>> I'd appreciate if some would find the time for a vote.
>
> Sorry, should have looked when you asked before...
I am even more sorry that the person originally requesting this change never replied back.
This all makes me very sad.
> The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
> properly for type-safety rather than void *, that's exactly the kind of
> thing this header was added for. Or else it should marshall everything
> through DER, not sure if that is feasible, probably less efficient.
>
> Not sure why 'struct apr_array_header_t' was used but I committed the
> trivial fix for that.
>
> The API is a bit less documented that I'd like though I know mod_ssl is
> worse than awful here, e.g. a few places not clear what the return value
> means, I have to guess/look at the implementation, this is ignored:
>
> + ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
>
> but this one is not:
>
> if (ssl_run_get_stapling_status(&rspder, &rspderlen, conn, s, x) == APR_SUCCESS) {
>
> and when passing apr_array_header_t make clear it's an array of (const
> char *) because again otherwise you have to guess/read the code.
*shrugs*
Re: mod_md v2.0.x + mod_ssl backport
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 12.07.2019 um 09:53 schrieb Joe Orton <jo...@redhat.com>:
>
> On Wed, Jul 10, 2019 at 01:40:10PM +0200, Stefan Eissing wrote:
>> Added descriptions for this.
>>
>> Updated the backport patch. Updated the mod_md version in trunk, 2.4.x
>> and github master and github maintenance branch. At this time, each
>> change is about half a day's work.
>
> Thanks, all LGTM!
Thanks!
>> Ceterum censeo, it's a pain to develop something for 2.4.x. And I
>> forgot the reason why this is so...
>
> We do at least try not to break the stable release all the time by
> having RTC for 2.4.x, I am not sure what is so unusual here.
Maybe it's just me then. That we stayed backwards compatible for a decade(?) now has advantages for our users, but it comes at a cost. For me personally, it is doubling the work in integration and testing.
Cheers, Stefan
> Regards, Joe
Re: mod_md v2.0.x + mod_ssl backport
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jul 10, 2019 at 01:40:10PM +0200, Stefan Eissing wrote:
> Added descriptions for this.
>
> Updated the backport patch. Updated the mod_md version in trunk, 2.4.x
> and github master and github maintenance branch. At this time, each
> change is about half a day's work.
Thanks, all LGTM!
> Ceterum censeo, it's a pain to develop something for 2.4.x. And I
> forgot the reason why this is so...
We do at least try not to break the stable release all the time by
having RTC for 2.4.x, I am not sure what is so unusual here.
Regards, Joe
Re: mod_md v2.0.x + mod_ssl backport
Posted by Stefan Eissing <st...@greenbytes.de>.
One day later...
> Am 09.07.2019 um 13:28 schrieb Joe Orton <jo...@redhat.com>:
>
> On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
>> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support and offers various monitoring possibilities for admins to see what is going on. But...it really needs votes for a mod_ssl related backport:
>>
>> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's optional functions.
>>
>> Without this, the new TLS challenge will not work and people still need to rely on port 80. I heard from one user whose ISP is blocking incoming port 80 (everything can be reasoned with "security" nowadays). So, for some, this is really vital.
>>
>> I'd appreciate if some would find the time for a vote.
>
> Sorry, should have looked when you asked before...
Thanks for looking at it, nevertheless.
> The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
> properly for type-safety rather than void *, that's exactly the kind of
> thing this header was added for. Or else it should marshall everything
> through DER, not sure if that is feasible, probably less efficient.
Ok, learned something new.
> Not sure why 'struct apr_array_header_t' was used but I committed the
> trivial fix for that.
Just not a big fan of nested includes myself. But it's not that important.
> The API is a bit less documented that I'd like though I know mod_ssl is
> worse than awful here, e.g. a few places not clear what the return value
> means, I have to guess/look at the implementation, this is ignored:
>
> + ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
>
> but this one is not:
>
> if (ssl_run_get_stapling_status(&rspder, &rspderlen, conn, s, x) == APR_SUCCESS) {
>
> and when passing apr_array_header_t make clear it's an array of (const
> char *) because again otherwise you have to guess/read the code
Added descriptions for this.
Updated the backport patch. Updated the mod_md version in trunk, 2.4.x and github master and github maintenance branch. At this time, each change is about half a day's work.
Cheers, Stefan
Ceterum censeo, it's a pain to develop something for 2.4.x. And I forgot the reason why this is so...
Re: mod_md v2.0.x + mod_ssl backport
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jul 09, 2019 at 11:57:00AM +0200, Stefan Eissing wrote:
> mod_md v2.0.x has landed in 2.4.x. This offers the ACMEv2 (RFC 8555) support and offers various monitoring possibilities for admins to see what is going on. But...it really needs votes for a mod_ssl related backport:
>
> mod_ssl: offer new hooks for modules like mod_md and remove use of mod_md's optional functions.
>
> Without this, the new TLS challenge will not work and people still need to rely on port 80. I heard from one user whose ISP is blocking incoming port 80 (everything can be reasoned with "security" nowadays). So, for some, this is really vital.
>
> I'd appreciate if some would find the time for a vote.
Sorry, should have looked when you asked before...
The new hooks should be in mod_ssl_openssl.h and use OpenSSL types
properly for type-safety rather than void *, that's exactly the kind of
thing this header was added for. Or else it should marshall everything
through DER, not sure if that is feasible, probably less efficient.
Not sure why 'struct apr_array_header_t' was used but I committed the
trivial fix for that.
The API is a bit less documented that I'd like though I know mod_ssl is
worse than awful here, e.g. a few places not clear what the return value
means, I have to guess/look at the implementation, this is ignored:
+ ssl_run_add_cert_files(s, p, pks->cert_files, pks->key_files);
but this one is not:
if (ssl_run_get_stapling_status(&rspder, &rspderlen, conn, s, x) == APR_SUCCESS) {
and when passing apr_array_header_t make clear it's an array of (const
char *) because again otherwise you have to guess/read the code.