Re: svn commit: r1807777 - /httpd/httpd/trunk/modules/md/Makefile.in

[William A Rowe Jr]

On Fri, Sep 8, 2017 at 10:14 AM, Yann Ylavic  wrote:
> Hi Stefan,
>
> On Fri, Sep 8, 2017 at 5:06 PM,   wrote:
>> Author: icing
>> Date: Fri Sep  8 15:06:44 2017
>> New Revision: 180
>>
>> URL: http://svn.apache.org/viewvc?rev=180=rev
>> Log:
>> On the trunk:
>>
>> mod_md: added necessary CPPFLAGS for a2md build.
>
> Thanks, it fixed some APR dependencies for me.
>
> Now I'm here:
>
> || *** Warning: Linking the shared library mod_md.la against the non-libtool
> || *** objects  md_acme.o md_acme_acct.o md_acme_authz.o
> md_acme_drive.o md_core.o md_curl.o md_crypt.o md_http.o md_json.o
> md_jws.o md_log.o md_reg.o md_store.o md_store_fs.o md_util.o is not
> portable!
> || /home/yle/bin/ld: error: md_json.o: requires dynamic R_X86_64_PC32
> reloc against 'md_json_destroy' which may overflow at runtime;
> recompile with -fPIC
> || /home/yle/bin/ld: error: md_reg.o: requires dynamic R_X86_64_PC32
> reloc against 'md_reg_find_overlap' which may overflow at runtime;
> recompile with -fPIC
> || /home/yle/bin/ld: error: md_util.o: requires dynamic R_X86_64_PC32
> reloc against 'md_array_str_index' which may overflow at runtime;
> recompile with -fPIC
> || collect2: error: ld returned 1 exit status
>
> Any idea?


Missing CFLAGS or wrong CC invocation.

Re: svn commit: r1807777 - /httpd/httpd/trunk/modules/md/Makefile.in

[Yann Ylavic]

Hi Stefan,

On Fri, Sep 8, 2017 at 5:06 PM,   wrote:
> Author: icing
> Date: Fri Sep  8 15:06:44 2017
> New Revision: 180
>
> URL: http://svn.apache.org/viewvc?rev=180=rev
> Log:
> On the trunk:
>
> mod_md: added necessary CPPFLAGS for a2md build.

Thanks, it fixed some APR dependencies for me.

Now I'm here:

|| *** Warning: Linking the shared library mod_md.la against the non-libtool
|| *** objects  md_acme.o md_acme_acct.o md_acme_authz.o
md_acme_drive.o md_core.o md_curl.o md_crypt.o md_http.o md_json.o
md_jws.o md_log.o md_reg.o md_store.o md_store_fs.o md_util.o is not
portable!
|| /home/yle/bin/ld: error: md_json.o: requires dynamic R_X86_64_PC32
reloc against 'md_json_destroy' which may overflow at runtime;
recompile with -fPIC
|| /home/yle/bin/ld: error: md_reg.o: requires dynamic R_X86_64_PC32
reloc against 'md_reg_find_overlap' which may overflow at runtime;
recompile with -fPIC
|| /home/yle/bin/ld: error: md_util.o: requires dynamic R_X86_64_PC32
reloc against 'md_array_str_index' which may overflow at runtime;
recompile with -fPIC
|| collect2: error: ld returned 1 exit status

Any idea?

Re: svn commit: r1803396 - in /httpd/httpd/trunk: modules/ssl/ support/

[Yann Ylavic]

On Thu, Aug 3, 2017 at 9:25 AM, Ruediger Pluem  wrote:
>
> On 07/30/2017 01:05 AM, yla...@apache.org wrote:
>>
>> Modified: httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c?rev=1803396=1803395=1803396=diff
>> ==
>> --- httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c (original)
>> +++ httpd/httpd/trunk/modules/ssl/ssl_ct_sct.c Sat Jul 29 23:05:02 2017
>> @@ -32,7 +32,7 @@ static apr_status_t verify_signature(sct
>>  return APR_EINVAL;
>>  }
>>
>> -#if OPENSSL_VERSION_NUMBER < 0x1010L
>> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>
> Why not using MODSSL_USE_OPENSSL_PRE_1_1_API here?
>
>>  ctx = EVP_MD_CTX_create();
>>  #else
>>  ctx = EVP_MD_CTX_new();
>> @@ -41,7 +41,7 @@ static apr_status_t verify_signature(sct
>>  ap_assert(1 == EVP_VerifyUpdate(ctx, sctf->signed_data,
>>  sctf->signed_data_len));
>>  rc = EVP_VerifyFinal(ctx, sctf->sig, sctf->siglen, pkey);
>> -#if OPENSSL_VERSION_NUMBER < 0x1010L
>> +#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
>
> Why not using MODSSL_USE_OPENSSL_PRE_1_1_API here?

#including "ssl_private.h" in "ssl_ct_sct.c" doesn't work; the former
defines MODSSL_USE_OPENSSL_PRE_1_1 but also APLOG_USE_MODULE(ssl), the
latter has AP_DECLARE_MODULE(ssl_ct).

There are surely ways to address this, but I don't know how for now...


Regards,
Yann.

Re: svn commit: r1803396 - in /httpd/httpd/trunk: modules/ssl/ support/

[Yann Ylavic]

On Thu, Aug 3, 2017 at 9:34 AM, William A Rowe Jr  wrote:
> IMO that's garbage, please revert. I don't believe that any ASF project,
> which has very firm rules about appropriating code bases, should be
> tolerating namespace abuse and mark infringement against other
> projects.

Not really a technical argument...
LibreSSL is a fork, for some reasons (which we don't have to and won't
discuss/dispute here) some people decided that OpenSSL (as is/was)
didn't suit their needs and forked it (which, AFAICT, isn't forbidden
by the OpenSSL license), and for the same or other reasons (whatever),
some people decided to use and package it in distros.
Thus both projects share code and namespace...

>
> If they want us to test a symbol in a LIBRESSL space, that's fine, but
> OPENSSL namespace was not theirs to begin with.

They define LIBRESSL_VERSION, but alas (for us) also OPENSSL_VERSION=2
(I agree that they probably have to change that some day...).

Anyway, if we want to support LibreSSL we could check LIBRESSL_VERSION
all over the place and have distinct code in mod_ssl for both libs, or
do something like this quite simple patch and thanks to most
code/namespace reuse have it work with few changes.

Do you propose that we don't support LibreSSL for ethical reasons?


Regards,
Yann.

Re: Listen 443 https

[Stefan Eissing]

> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
> 
> Reminder, this will not work with the current server_rec, we have a 1:1 
> correspondence to the server port. We would need to stop looking at that 
> field and track the port entirely on the connection and the server rec 
> addresses array.

Urgs.

1. Irregardless of multiple addresses in a VirtualHost, I still like the idea of

SSLEngine *:443 local_interface:8001

that is best used in the base server, once. 
a) I think it is easy to understand what it does.
b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it 
c) It causes required fails when a VirtualHost on a SSL port has no certificates

With that, we could advise people who want to start using SSL to include the 
following in their main conf:

  Listen 443
  # The following fails if your OpenSSL is not new enough. 
  SSLPolicy modern
  SSLEngine *:443


2. For people *moving* from http: to https: for a VirtualHost, we'd advise

  
ServerName yourhostname
Redirect 301 "/" "https://yourhostname/;
  

  
ServerName yourhostname
 ...the former http: config
  

?

3. For people wanting to offer both http: and https: for the same resources 
(maybe for a trial period), what would we tell them?
a) Copy to a new VirtualHost
b) Make separate file and Include in two VirtualHost?
c) Macros???

Cheers,

Stefan

---
Quick scan where we use server_rec->port:

core:
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
...
port = r->parsed_uri.port_str ? r->parsed_uri.port :
   r->server->port ? r->server->port :
   ap_default_port(r);

mod_log_config.c:
static const char *log_server_port(request_rec *r, char *a)
{
apr_port_t port;

if (*a == '\0' || !strcasecmp(a, "canonical")) {
port = r->server->port ? r->server->port : ap_default_port(r);
}


ssl_engine_init.c:
if ((sc->enabled == SSL_ENABLED_TRUE) && (s->port == 
DEFAULT_HTTP_PORT)) {

ssl_util.c:
char *ssl_util_vhostid(apr_pool_t *p, server_rec *s)
{
char *id;
SSLSrvConfigRec *sc;
char *host;
apr_port_t port;

host = s->server_hostname;
if (s->port != 0)
port = s->port;
else {

vhost.c:
/* the Port has to match now, because the rest don't have ports associated
 * with them. */
if (port != s->port) {
return 0;
}


> On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener  wrote:
> > On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
> >  wrote:
> >> I get the first feedback from Apache users that want their http: only 
> >> hosts to also serve https:. This is nice feedback to improve usability of 
> >> mod_md.
> >>
> >> Ideally, what these people want - and that is purely my interpretation - 
> >> is to add a few lines to their config and - voila - https: is available. 
> >> And, honestly, why should they not expect that?
> >>
> >>
> >>
> >> Example: Duplication/Redirect
> >>
> >> They have something like:
> >> --
> >> Listen 80
> >> 
> >> ServerName xxx.yyy
> >> ...
> >> 
> >> --
> >>
> >> and want to also make that available on https:
> >> --
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> 
> >> ServerName xxx.yyy
> >> AlternatePorts 443
> >> ...
> >> 
> >> --
> >>
> >> or redirect everyone to https:
> >> --
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> 
> >> ServerName xxx.yyy
> >> RedirectPermanentFrom 80
> >> ...
> >> 
> >
> > I am not keen on the syntax because we already permit multiple
> > addresses in the VirtualHost tag.
> >
> > How about e.g.
> >
> > 
> 
> Again, fo