Additional LB providers

2015-06-18 Thread Jim Jagielski
I'm playing around w/ a newish LB provider that balances based
on latency. I'd like to fold it in after I clean it up a bit
but it seems to me that we could also fold in the round-robin
provider in example (after a suitable cleanup) as well as add
in a simply by_random as well.

Comments?


Re: svn commit: r1686248 - /httpd/httpd/branches/2.4.x/STATUS

2015-06-18 Thread William A Rowe Jr
In some cases, perhaps, but this was objection asked-and-answered so my -1
was void.

On Thu, Jun 18, 2015 at 12:07 PM, Yann Ylavic ylavic@gmail.com wrote:

 On Thu, Jun 18, 2015 at 5:39 PM,  wr...@apache.org wrote:
  Author: wrowe
  Date: Thu Jun 18 15:39:53 2015
  New Revision: 1686248
 
  URL: http://svn.apache.org/r1686248
  Log:
  After addressing a defect, don't discuss, this isn't a forum :)
 
  Note the patch is updated, and delete now-irrelevant comments/votes.

 It seems to me that since a -1 needs to be argued, it can't be deleted
 without..



Re: svn commit: r1686248 - /httpd/httpd/branches/2.4.x/STATUS

2015-06-18 Thread Yann Ylavic
On Thu, Jun 18, 2015 at 5:39 PM,  wr...@apache.org wrote:
 Author: wrowe
 Date: Thu Jun 18 15:39:53 2015
 New Revision: 1686248

 URL: http://svn.apache.org/r1686248
 Log:
 After addressing a defect, don't discuss, this isn't a forum :)

 Note the patch is updated, and delete now-irrelevant comments/votes.

It seems to me that since a -1 needs to be argued, it can't be deleted without..


NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Jim Jagielski
Subj sez it all.


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Jeff Trawick
On Thu, Jun 18, 2015 at 1:08 PM, Jim Jagielski j...@jagunet.com wrote:

 Subj sez it all.


+!


Re: Roll 2.2.30 in conjunction with 2.4.14

2015-06-18 Thread William A Rowe Jr
On Jun 11, 2015 8:22 AM, Eric Covener cove...@gmail.com wrote:

 On Thu, Jun 11, 2015 at 9:08 AM William A Rowe Jr wr...@rowe-clan.net
wrote:

 But withholding a security fix for legacy server users?  Sounds like a
way to earn distrust of the user community, not reassure them that 2.4.14
is the best version available.

 +1

The 2.2 patches are in alignment with the resolved 2.4 security patches
plus relaxed trailing spaces rule. Yann and I have reviewed, still weeks
later 2.2.30 needs one more pair of eyeballs and a third +1 of the 2
patches.

I can TR in the morning Friday if it has been reviewed, else it will be a
while before I can RM.


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Yann Ylavic
On Thu, Jun 18, 2015 at 7:08 PM, Jim Jagielski j...@jagunet.com wrote:
 Subj sez it all.

+1

Maybe including the gcc warning silenced in r1684057 (proposed in r1686298)?


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread olli hauer
On 2015-06-18 19:08, Jim Jagielski wrote:
 Subj sez it all.
 

I don't know if it is worth to report this, but the on 2.4.12. I don't see the 
following warnings

Test build 2.4.15 (Last Changed Rev: 1686275)

--- core.lo ---
core.c:5003:1: warning: unused variable 'aplog_module_index' 
[-Wunused-const-variable]
AP_DECLARE_MODULE(core) = {
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5: note: 
expanded from macro 'AP_DECLARE_MODULE'
APLOG_USE_MODULE(foo); \
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24: note: 
expanded from macro 'APLOG_USE_MODULE'
static int * const aplog_module_index = (foo##_module.module_index)
   ^
--- http_core.lo ---
http_core.c:320:1: warning: unused variable 'aplog_module_index' 
[-Wunused-const-variable]
AP_DECLARE_MODULE(http) = {
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5: note: 
expanded from macro 'AP_DECLARE_MODULE'
APLOG_USE_MODULE(foo); \
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24: note: 
expanded from macro 'APLOG_USE_MODULE'
static int * const aplog_module_index = (foo##_module.module_index)
   ^
--- mod_buffer.slo ---
...




Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread olli hauer
On 2015-06-18 22:17, Rainer Jung wrote:
 Am 18.06.2015 um 21:54 schrieb Jeff Trawick:
 On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de
 mailto:oha...@gmx.de wrote:

 On 2015-06-18 19:08, Jim Jagielski wrote:
  Subj sez it all.
 

 I don't know if it is worth to report this, but the on 2.4.12. I
 don't see the following warnings


 Are you using clang for both compiles?

 (I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)
 
 At least technically they are correct. aplog_module_index is used only in 
 APLOG_MODULE_INDEX and this macro is redefined in core.c to use a known 
 constant instead (likely for performance reasons).
 
 And modules/http/http_core.c doesn't have any log statement which is probably 
 the reason for not using aplog_module_index in that file.
 
 So those are expected. The warnings don't actually point to a real problem 
 except for any warning always make one feel uncomfortable.
 
 The second warning could be silenced by adding a log statement.For the first 
 I don't have an easy solution.
 
 Regards,
 
 Rainer

Hi Rainer,

Thanks for your explanation!

The warnings are displayed on a couple more modules (mod_buffer, mod_data, 
mod_logio, mod_version, mod_session_cookie, mod_slotmem_plain, mod_info, 
mod_dav_fs, mod_vhost_alias, mod_userdir, mod_dir) I showed only a shortened 
summary snipped.

I can suppress the warnings in the FreeBSD ports tree for 2.4.15 and following 
releases.

-- 
Regards,
olli



Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Yann Ylavic
Since wherever AP_DECLARE_MODULE is used we don't need the
APLOG_USE_MODULE part (ie. the static declaration of
aplog_module_index), that would possibly be better to use a new
AP_DEFINE_MODULE, simply as:

#define AP_DECLARE_MODULE(foo) \
module AP_MODULE_DECLARE_DATA foo##_module

The attached patch (quite huge since it touches many modules) compiles
with no issue (with gcc which does no warn w/o the patch though).
No missing/undeclared aplog_module_index reported anywhere.

That's mainly (so to preserve the legacy AP_DECLARE_MODULE):

Index: include/http_config.h
===
--- include/http_config.h(revision 1686298)
+++ include/http_config.h(working copy)
@@ -427,6 +427,12 @@ struct module_struct {
 static int * const aplog_module_index = (foo##_module.module_index)

 /**
+ * AP_DEFINE_MODULE is a convenience macro to define the module symbol.
+ */
+#define AP_DEFINE_MODULE(foo) \
+module AP_MODULE_DECLARE_DATA foo##_module
+
+/**
  * AP_DECLARE_MODULE is a convenience macro that combines a call of
  * APLOG_USE_MODULE with the definition of the module symbol.
  *
@@ -434,8 +440,8 @@ struct module_struct {
  * APLOG_USE_MODULE should be used explicitly instead of AP_DECLARE_MODULE.
  */
 #define AP_DECLARE_MODULE(foo) \
-APLOG_USE_MODULE(foo); \
-module AP_MODULE_DECLARE_DATA foo##_module
+APLOG_USE_MODULE(foo); \
+APLOG_DEFINE_MODULE(foo)

 /**
  * @defgroup ModuleInit Module structure initializers
--

with the remainder being s/AP_DECLARE_MODULE/AP_DEFINE_MODULE/g in
the modules...


On Thu, Jun 18, 2015 at 10:17 PM, Rainer Jung rainer.j...@kippdata.de wrote:
 Am 18.06.2015 um 21:54 schrieb Jeff Trawick:

 On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de
 mailto:oha...@gmx.de wrote:

 On 2015-06-18 19:08, Jim Jagielski wrote:
  Subj sez it all.
 

 I don't know if it is worth to report this, but the on 2.4.12. I
 don't see the following warnings


 Are you using clang for both compiles?

 (I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)


 At least technically they are correct. aplog_module_index is used only in
 APLOG_MODULE_INDEX and this macro is redefined in core.c to use a known
 constant instead (likely for performance reasons).

 And modules/http/http_core.c doesn't have any log statement which is
 probably the reason for not using aplog_module_index in that file.

 So those are expected. The warnings don't actually point to a real problem
 except for any warning always make one feel uncomfortable.

 The second warning could be silenced by adding a log statement.For the first
 I don't have an easy solution.

 Regards,

 Rainer


 Test build 2.4.15 (Last Changed Rev: 1686275)

 --- core.lo ---
 core.c:5003:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(core) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
  APLOG_USE_MODULE(foo); \
  ^

 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
  static int * const aplog_module_index =
 (foo##_module.module_index)
 ^
 --- http_core.lo ---
 http_core.c:320:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(http) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
  APLOG_USE_MODULE(foo); \
  ^

 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
  static int * const aplog_module_index =
 (foo##_module.module_index)
 ^
 --- mod_buffer.slo ---
 ...


httpd-2.4.x-AP_DEFINE_MODULE.patch
Description: application/download


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Yann Ylavic
On Thu, Jun 18, 2015 at 9:03 PM, olli hauer oha...@gmx.de wrote:
 On 2015-06-18 19:08, Jim Jagielski wrote:
 Subj sez it all.


 I don't know if it is worth to report this, but the on 2.4.12. I don't see 
 the following warnings

These were not in 2.4.12 with the same compiler (and version)?


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Jeff Trawick
On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de wrote:

 On 2015-06-18 19:08, Jim Jagielski wrote:
  Subj sez it all.
 

 I don't know if it is worth to report this, but the on 2.4.12. I don't see
 the following warnings


Are you using clang for both compiles?

(I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)




 Test build 2.4.15 (Last Changed Rev: 1686275)

 --- core.lo ---
 core.c:5003:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(core) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index = (foo##_module.module_index)
^
 --- http_core.lo ---
 http_core.c:320:1: warning: unused variable 'aplog_module_index'
 [-Wunused-const-variable]
 AP_DECLARE_MODULE(http) = {
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
 note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
 /usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
 note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index = (foo##_module.module_index)
^
 --- mod_buffer.slo ---
 ...





-- 
Born in Roswell... married an alien...
http://emptyhammock.com/


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread olli hauer
On 2015-06-18 21:54, Jeff Trawick wrote:
 On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de wrote:
 
 On 2015-06-18 19:08, Jim Jagielski wrote:
 Subj sez it all.


 I don't know if it is worth to report this, but the on 2.4.12. I don't see
 the following warnings

 
 Are you using clang for both compiles?
 
 (I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)
 
 

Yes, it is with clang (default on FreeBSD 10.x)

I've just build 2.4.12, 2.4.13 and 2.4.14 + a local patch to match the svn.
The warnings are present on with 2.4.13+ but is not on 2.4.12.


-- 
olli


Re: NOTE: Intent to TR 2.4.15 Tomorrow (Friday, June 19)

2015-06-18 Thread Rainer Jung

Am 18.06.2015 um 21:54 schrieb Jeff Trawick:

On Thu, Jun 18, 2015 at 3:03 PM, olli hauer oha...@gmx.de
mailto:oha...@gmx.de wrote:

On 2015-06-18 19:08, Jim Jagielski wrote:
 Subj sez it all.


I don't know if it is worth to report this, but the on 2.4.12. I
don't see the following warnings


Are you using clang for both compiles?

(I think I saw those for 2.4.12,13,14 on FreeBSD 10.1 + Clang.)


At least technically they are correct. aplog_module_index is used only 
in APLOG_MODULE_INDEX and this macro is redefined in core.c to use a 
known constant instead (likely for performance reasons).


And modules/http/http_core.c doesn't have any log statement which is 
probably the reason for not using aplog_module_index in that file.


So those are expected. The warnings don't actually point to a real 
problem except for any warning always make one feel uncomfortable.


The second warning could be silenced by adding a log statement.For the 
first I don't have an easy solution.


Regards,

Rainer


Test build 2.4.15 (Last Changed Rev: 1686275)

--- core.lo ---
core.c:5003:1: warning: unused variable 'aplog_module_index'
[-Wunused-const-variable]
AP_DECLARE_MODULE(core) = {
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index =
(foo##_module.module_index)
^
--- http_core.lo ---
http_core.c:320:1: warning: unused variable 'aplog_module_index'
[-Wunused-const-variable]
AP_DECLARE_MODULE(http) = {
^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:437:5:
note: expanded from macro 'AP_DECLARE_MODULE'
 APLOG_USE_MODULE(foo); \
 ^
/usr/ports/www/apache24/work/httpd-2.4.14/include/http_config.h:427:24:
note: expanded from macro 'APLOG_USE_MODULE'
 static int * const aplog_module_index =
(foo##_module.module_index)
^
--- mod_buffer.slo ---
...


Re: Using UPN from subjectAltName with SSLUserName

2015-06-18 Thread Yann Ylavic
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora jpazdzi...@redhat.com wrote:

 I'd appreciate any comments about suitability of such change, as well
 as the implementation. Specifically, I'm not sure if people will
 prefer the generic and currently proposed

 SSL_CLIENT_SAN_otherName_n

 which gets any value of otherName type, or perhaps going with

 SSL_CLIENT_SAN_UPN_n

 and checking the OID just for the UPNs. Based on that decision I plan
 to then respin the patch with documentation changes included.

I think a more generic way would to have something like
SSL_CLIENT_OID_oid_n, so that we wouldn't have to add a new field
each time.
In this case, that would be: SSL_CLIENT_OID_1.3.6.1.4.1.311.20.2.3_n.

Regards,
Yann.


Re: sni+alpn, vhost+certs

2015-06-18 Thread Stefan Eissing
I have a patch for this now, but discovered that mod_h2 needs some more:

In the ALPN propose callback, the module needs to know which vhost the
connection is about. And not only that, it needs the server_rec of that
to check its config. If the module is disabled in that vhost, it should
not propose anything.

Since mod_ssl stores the selected server only in its internal context and
leaves the base server at the conn_rec untouched, mod_h2 has to make
a workaround to get it.

It retrieves SNI servername via ssl_var_lookup, creates a fake request_rec
incokes ap_update_vhost_from_headers(). 

Not very elegant.

a) is there another way?
b) if not, should the server_rec be a parameter to the alpn callback functions
c) or, alternatively, should the conn_rec carry that information somewhere?

Thanks for the help.


 Am 17.06.2015 um 14:23 schrieb Eric Covener cove...@gmail.com:
 
 On Wed, Jun 17, 2015 at 8:21 AM, Stefan Eissing
 stefan.eiss...@greenbytes.de wrote:
 1. connection, setup for base server and defaults
 2. client hello arrives
 3. ALPN callback is invoked by openssl
 4. ALPN protocol is chosen, this triggers the server answer
 5. SNI callback is invoked by openssl and sets up vhost info and configs
 6. Oops.
 
 Lacking the SNI name and vhost setups, the sendback in 4 seems to fallback 
 to the default vhost selection and that certificate is used to answer the 
 call.
 
 The issue has been reported by me on the openssl dev list. As a workaround 
 for now and compatibility to older openssl versions, I propose to add to the 
 ALPN patch something that
 a) checks in ALPN callback if vhost has been setup by SNI callback
 b) if not, retrieves SNI servername via SSL_get_servername()
 c) if servername is returned, setup vhost just like in SNI callback
 d) if SNI callback is invoked and vhost has been setup already, nop
 
 Sounds reasonable?
 
 
 Seems fair
 
 -- 
 Eric Covener
 cove...@gmail.com

green/bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782





Using UPN from subjectAltName with SSLUserName

2015-06-18 Thread Jan Pazdziora

Hello,

I've noticed that support for getting subjectAltName entries Email and
Type landed in 2.4.13, via r1676087.

We've come across another type in subjectAltName, Microsoft Universal
Principal Name (OID 1.3.6.1.4.1.311.20.2.3) which would be useful to
retrieve from the certificate and use for subsequent authorization
and identity operations against Active Directory.

I've filed

https://bz.apache.org/bugzilla/show_bug.cgi?id=58020
When user authenticates with certificate which has their
Microsoft Universal Principal Name in subjectAltName,
that UPN cannot be used with SSLUserName for further
access controls

and included a patch which extends the original SAN support to
otherName.

I'd appreciate any comments about suitability of such change, as well
as the implementation. Specifically, I'm not sure if people will
prefer the generic and currently proposed

SSL_CLIENT_SAN_otherName_n

which gets any value of otherName type, or perhaps going with

SSL_CLIENT_SAN_UPN_n

and checking the OID just for the UPNs. Based on that decision I plan
to then respin the patch with documentation changes included.

Thank you,

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat


Re: sni+alpn, vhost+certs

2015-06-18 Thread Yann Ylavic
On Thu, Jun 18, 2015 at 11:07 AM, Stefan Eissing
stefan.eiss...@greenbytes.de wrote:

 It retrieves SNI servername via ssl_var_lookup, creates a fake request_rec
 incokes ap_update_vhost_from_headers().

 Not very elegant.

 a) is there another way?

Maybe define a new ap_get_vhost_from_name() and use it in both
ap_update_vhost_from_headers() and your code.

 b) if not, should the server_rec be a parameter to the alpn callback functions

If that's enough, it looks like a simpler change, though.

 c) or, alternatively, should the conn_rec carry that information somewhere?

Such a base struct is not very easy to change without breaking
compatibility (ABI), that would make any backport to 2.4.x less
acceptable...

Regards,
Yann.