date:20151221

Re: OpenSSL 0.9.8/1.0.0 on Trunk

2015-12-21 Thread Jacob Perkins

This is kind of a show stopper here. I’m surprised something as major as code 
not compiling was not caught before it was sent out.

—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Dec 15, 2015, at 9:57 AM, Mike Rumph  wrote:
> 
> FYI.  Bug 58737 was just opened today for this error.
> 
> Thanks,
> 
> Mike
> 
> On 12/14/2015 10:15 AM, William A Rowe Jr wrote:
>> W.r.t. http://svn.apache.org/r1719967 - I'm +1 for the backport.
>> I'd like to propose we remove all support from *trunk* for OpenSSL < 1.0.1
>> effective now...
>> 
>> https://mta.openssl.org/pipermail/openssl-announce/2014-December/00.html
>> 
>> We don't deprecate support on maintenance branches (e.g. 2.2/2.4),
>> because we seek to minimize the pain of moving from one subversion
>> release to another.  If someone wanted to hack a non-fatal warning for
>> the ./configure phase, that could be a worthwhile patch.
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenSSL 0.9.8/1.0.0 on Trunk

2015-12-21 Thread Eric Covener

On Mon, Dec 21, 2015 at 1:48 PM, Jacob Perkins  wrote:
> This is kind of a show stopper here. I’m surprised something as major as
> code not compiling was not caught before it was sent out.

This particular failure only occurs when compiling httpd against older
levels of openssl 0.9.8.
It's no surprise to me that none of the handful of people who test new
release candidates test
with contemporary levels of openssl that are actually fit for some use.

Re: OpenSSL 0.9.8/1.0.0 on Trunk

2015-12-21 Thread Jacob Perkins

CentOS 5 still ships with OpenSSL 0.9.8, and is still supported for another 
year or so. Considering there’s a lot of servers still running CentOS 5 (and 
possibly older), it feels as if this would have been caught. Especially 
something as small as a missing semicolon.

Would a linter / compile check to proactively check those things help?
—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Dec 21, 2015, at 1:06 PM, Eric Covener  wrote:
> 
> On Mon, Dec 21, 2015 at 1:48 PM, Jacob Perkins  
> wrote:
>> This is kind of a show stopper here. I’m surprised something as major as
>> code not compiling was not caught before it was sent out.
> 
> This particular failure only occurs when compiling httpd against older
> levels of openssl 0.9.8.
> It's no surprise to me that none of the handful of people who test new
> release candidates test
> with contemporary levels of openssl that are actually fit for some use.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: doxygen docs

2015-12-21 Thread Alan Nilsson

awesome, many thanks!


> On Dec 21, 2015, at 7:10 AM, Luca Toscano  wrote:
> 
> Hi Alan,
> 
> the daily build was broken, it has been fixed now! (thanks to Humbedooh)
> 
> Luca
> 
> 2015-12-15 19:12 GMT+01:00 Alan Nilsson :
> 
>> There used to be an online doxygen API ref @
>> https://ci.apache.org/projects/httpd/trunk/doxygen/.  That has been gone
>> for a while now.
>> 
>> Does anyone know of another online API ref for 2.4?  Or does anyone have a
>> working doxygen conf to build from the source tree?  I cannot seem to get
>> doxygen to generate very well.
>> 
>> thanks
>> alan
>> 
>>

[PATCH] Reduce memory footprint in mod_dav's property code

2015-12-21 Thread Stefan Fuhrmann


Hi,

I stumbled over this while investigation an OOM report from a
Subversion user [1].  Due to unfortunate circumstances [2], I've
seen directory listings with a few 1 entries eat 10s of GB
of RAM.  Those circumstances are being addressed but the root
cause is in mod_dav and the patch below fixes it.

The problem is that dav_open_propdb creates a pool that
dav_close_propdb can't destroy.  So, for every property, at least
8 KB of memory will be allocated.  If we simply use the parent
pool as is, only a few 100 bytes will be used.

Moreover, if the APR allocator should return a larger block once
in a while, that block will get used up nicely before more memory
is allocated.  So with this patch, the worst case will still use
only about to 1/10th of the current best case for large collections.

-- Stefan^2.

[1] 
http://mail-archives.apache.org/mod_mbox/subversion-users/201512.mbox/%3C1CEE115D02633942A40D49D447DCF46E432F3A32%40SD01CFMM0202.OMEGA.DCE-EIR.NET%3E
[2] 
http://mail-archives.apache.org/mod_mbox/subversion-dev/201512.mbox/%3C5676A54F.9040609%40apache.org%3E



[[[
Fix a pool handling asymmetry in mod_dav that caused inefficient
memory usage with collection properties.

If we can't clear nor destroy the local pool in dav_propdb, there
is no point in creating it as a sub-pool of its parent.

* modules/dav/main/props.c
  (DAV_PROPDB_LOCAL_POOL): New compile-time switch replacing the
   plain "#if 0" in dav_close_propdb.  It
   ensures consistent behaviour between
   open and close in the future.
  (dav_open_propdb): If we can't clear the pool, we may as well use
 its parent directly.
  (dav_close_propdb): Use the new define.
]]]

[[[
Index: modules/dav/main/props.c
===
--- modules/dav/main/props.c(revision 1721073)
+++ modules/dav/main/props.c(working copy)
@@ -167,6 +167,16 @@

 #define DAV_EMPTY_VALUE"\0"/* TWO null terms */

+/*
+** Currently, mod_dav's pool usage doesn't allow clearing the pool
+** at dav_propdb.p . Therefore, we won't create a sub-pool for it
+** and use the request's pool directly instead.
+**
+** Once the pool usage issue has been fixed, set this to 1 for optimal
+** memory usage.
+*/
+#define DAV_PROPDB_LOCAL_POOL  0
+
 struct dav_propdb {
 apr_pool_t *p;/* the pool we should use */
 request_rec *r;   /* the request record */
@@ -537,7 +547,11 @@
 #endif

 propdb->r = r;
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_create(>p, r->pool);
+#else
+propdb->p = r->pool;
+#endif
 propdb->resource = resource;
 propdb->ns_xlate = ns_xlate;

@@ -562,8 +576,7 @@
 (*propdb->db_hooks->close)(propdb->db);
 }

-/* Currently, mod_dav's pool usage doesn't allow clearing this pool. */
-#if 0
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_destroy(propdb->p);
 #endif
 }
]]]

Re: OpenSSL 0.9.8/1.0.0 on Trunk

2015-12-21 Thread Eric Covener

On Mon, Dec 21, 2015 at 2:38 PM, Jacob Perkins  wrote:
> CentOS 5 still ships with OpenSSL 0.9.8, and is still supported for another
> year or so. Considering there’s a lot of servers still running CentOS 5 (and
> possibly older), it feels as if this would have been caught.

Do you mean could or should have been caught?

It wasn't caught until someone compiled it against openssl < 0.9.8m
(which is not the latest 0.9.8).  I can't see many scenarios where someone
will compile a new 2.4.x release and not have a contemporary openssl --
beyond trying to catch exactly these kinds of problems during a release.

> Especially something as small as a missing semicolon.

Well, usually small problems are the ones that fly under the radar.Anything
catastrophic to the build will not go unnoticed, but someone has to build on the
affected platform/compiler/prereqs/???.

> Would a linter / compile check to proactively check those things help?

Dunno, possible.

Re: svn commit: r1721121 - in /httpd/httpd/trunk/modules/http2: h2_h2.c h2_io.c h2_io.h h2_mplx.h h2_push.c h2_request.c h2_request.h h2_session.c h2_session.h h2_stream.c h2_stream.h h2_task.c h2_tas

2015-12-21 Thread Christophe JAILLET


Le 21/12/2015 18:41, Mike Rumph a écrit :

Comment below:

Thanks,

Mike

On 12/21/2015 2:54 AM, ic...@apache.org wrote:

Author: icing
Date: Mon Dec 21 10:54:38 2015
New Revision: 1721121

URL: http://svn.apache.org/viewvc?rev=1721121=rev
Log:
byte savings by using bit fields, new env vars HTTP2 and H2PUSH, set 
to on when enabled on request


== 


--- httpd/httpd/trunk/modules/http2/h2_io.h (original)
+++ httpd/httpd/trunk/modules/http2/h2_io.h Mon Dec 21 10:54:38 2015
@@ -38,29 +38,30 @@ typedef struct h2_io h2_io;
  struct h2_io {

* * *

+
+int orphaned   : 1;  /* h2_stream is gone for this io */
+int task_done  : 1;  /* h2_task has finished for this io */
+int request_body   : 1;  /* iff request has body */
+int eos_in : 1;  /* input eos has been seen */
+int eos_in_written : 1;  /* input eos has been forwarded */
+int eos_out: 1;  /* output eos has been seen */
+

There have been past dev discussions on problems related to using 
signed bitfields.

Using unsigned int avoids these problems.

Fixed in r1721137 and r1721138 (and r1721139 which is not related to 
mod_http2)


CJ

Re: OpenSSL 0.9.8/1.0.0 on Trunk

2015-12-21 Thread Jacob Perkins

Hi Eric,

I’m going to work on setting up a test system for all of our supported 
environments so that we can test our platform quicker and provide feedback 
during the T period.

I’d love to try and give back to the project honestly. cPanel has used Apache 
in the core of our webstack for at least 10 years so it would be great if we 
could provide some extra eyes for testing releases, if not more.

Sorry if I came across a little… crass. It’s been a long day.
—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Dec 21, 2015, at 5:20 PM, Eric Covener  wrote:
> 
> On Mon, Dec 21, 2015 at 2:38 PM, Jacob Perkins  
> wrote:
>> CentOS 5 still ships with OpenSSL 0.9.8, and is still supported for another
>> year or so. Considering there’s a lot of servers still running CentOS 5 (and
>> possibly older), it feels as if this would have been caught.
> 
> Do you mean could or should have been caught?
> 
> It wasn't caught until someone compiled it against openssl < 0.9.8m
> (which is not the latest 0.9.8).  I can't see many scenarios where someone
> will compile a new 2.4.x release and not have a contemporary openssl --
> beyond trying to catch exactly these kinds of problems during a release.
> 
>> Especially something as small as a missing semicolon.
> 
> Well, usually small problems are the ones that fly under the radar.
> Anything
> catastrophic to the build will not go unnoticed, but someone has to build on 
> the
> affected platform/compiler/prereqs/???.
> 
>> Would a linter / compile check to proactively check those things help?
> 
> Dunno, possible.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH] Reduce memory footprint in mod_dav's property code

2015-12-21 Thread Marion & Christophe JAILLET

You can also have a look at 
https://bz.apache.org/bugzilla/show_bug.cgi?id=48130


Le 22/12/2015 01:13, Stefan Fuhrmann a écrit :

Hi,

I stumbled over this while investigation an OOM report from a
Subversion user [1].  Due to unfortunate circumstances [2], I've
seen directory listings with a few 1 entries eat 10s of GB
of RAM.  Those circumstances are being addressed but the root
cause is in mod_dav and the patch below fixes it.

The problem is that dav_open_propdb creates a pool that
dav_close_propdb can't destroy.  So, for every property, at least
8 KB of memory will be allocated.  If we simply use the parent
pool as is, only a few 100 bytes will be used.

Moreover, if the APR allocator should return a larger block once
in a while, that block will get used up nicely before more memory
is allocated.  So with this patch, the worst case will still use
only about to 1/10th of the current best case for large collections.

-- Stefan^2.

[1] 
http://mail-archives.apache.org/mod_mbox/subversion-users/201512.mbox/%3C1CEE115D02633942A40D49D447DCF46E432F3A32%40SD01CFMM0202.OMEGA.DCE-EIR.NET%3E
[2] 
http://mail-archives.apache.org/mod_mbox/subversion-dev/201512.mbox/%3C5676A54F.9040609%40apache.org%3E



[[[
Fix a pool handling asymmetry in mod_dav that caused inefficient
memory usage with collection properties.

If we can't clear nor destroy the local pool in dav_propdb, there
is no point in creating it as a sub-pool of its parent.

* modules/dav/main/props.c
  (DAV_PROPDB_LOCAL_POOL): New compile-time switch replacing the
   plain "#if 0" in dav_close_propdb.  It
   ensures consistent behaviour between
   open and close in the future.
  (dav_open_propdb): If we can't clear the pool, we may as well use
 its parent directly.
  (dav_close_propdb): Use the new define.
]]]

[[[
Index: modules/dav/main/props.c
===
--- modules/dav/main/props.c(revision 1721073)
+++ modules/dav/main/props.c(working copy)
@@ -167,6 +167,16 @@

 #define DAV_EMPTY_VALUE"\0"/* TWO null terms */

+/*
+** Currently, mod_dav's pool usage doesn't allow clearing the pool
+** at dav_propdb.p . Therefore, we won't create a sub-pool for it
+** and use the request's pool directly instead.
+**
+** Once the pool usage issue has been fixed, set this to 1 for optimal
+** memory usage.
+*/
+#define DAV_PROPDB_LOCAL_POOL  0
+
 struct dav_propdb {
 apr_pool_t *p;/* the pool we should use */
 request_rec *r;   /* the request record */
@@ -537,7 +547,11 @@
 #endif

 propdb->r = r;
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_create(>p, r->pool);
+#else
+propdb->p = r->pool;
+#endif
 propdb->resource = resource;
 propdb->ns_xlate = ns_xlate;

@@ -562,8 +576,7 @@
 (*propdb->db_hooks->close)(propdb->db);
 }

-/* Currently, mod_dav's pool usage doesn't allow clearing this 
pool. */

-#if 0
+#if DAV_PROPDB_LOCAL_POOL
 apr_pool_destroy(propdb->p);
 #endif
 }
]]]

Re: access control for dynamic hosts

2015-12-21 Thread Fabien



Hello folks,

I would like something like "Require XXX foo.dynamic-dns.somewhere" 
(where XXX could be "name", "hostname", "dynamic", ...) which would 
query the NS when the HTTP request is received and check that the 
corresponding ip is the client IP.


I'm planing to develop a small module for that, and as it is somehow 
quite a basic service it could be a candidate for being added to 
"modules/aaa/mod_authz_host.c".


Attached is a working version with the syntax "Requite name 
foo.somewhere".


Note sure whether "name" is the best... name for the authorization 
provider, though.


I could append this to mod_authz_host.c & update the documentation if I'm 
given a go.


--
Fabien/* Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

/*
 * Security options etc.
 *
 * Module derived from code originally written by Rob McCool
 *
 */

#include "apr_strings.h"
#include "apr_network_io.h"
#include "apr_md5.h"
#include "apr_hash.h"

#define APR_WANT_STRFUNC
#define APR_WANT_BYTEFUNC
#include "apr_want.h"

#include "ap_config.h"
#include "ap_provider.h"
#include "httpd.h"
#include "http_core.h"
#include "http_config.h"
#include "http_log.h"
#include "http_protocol.h"
#include "http_request.h"

#include "mod_auth.h"

#if APR_HAVE_NETINET_IN_H
#include 
#endif

static authz_status name_check_authorization(request_rec *r,
 const char *require_line,
 const void *parsed_require_line)
{
const char *err = NULL;
const ap_expr_info_t *expr = parsed_require_line;
const char *require, *t;
char *w;

/* the require line is an expression, which is evaluated now. */
require = ap_expr_str_exec(r, expr, );
if (err) {
  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, // APLOGNO(FIXME)
"name_check_authorization: "
"Can't evaluate require expression: %s", err);
  return AUTHZ_DENIED;
}

/* tokenize expected list of names */
t = require;
while ((w = ap_getword_conf(r->pool, )) && w[0]) {

apr_sockaddr_t *sa;
apr_status_t rv;
char *hash_ptr;

/* stop on apache configuration file comments */
if ((hash_ptr = ap_strchr(w, '#'))) {
if (hash_ptr == w) {
break;
}
*hash_ptr = '\0';
}

/* does the client ip match one of the name? */
rv = apr_sockaddr_info_get(, w, APR_UNSPEC, 0, 0, r->pool);
if (rv == APR_SUCCESS) {

while (sa) {
int match = apr_sockaddr_equal(sa, r->useragent_addr);

ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, // APLOGNO(FIXME)
  "name_check_authorization: %s for %s: %s",
  w, r->useragent_ip, match? "yes": "no");
if (match) {
return AUTHZ_GRANTED;
}

sa = sa->next;
}
}
else {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, // APLOGNO(FIXME)
"name_check_authorization: no sockaddr info for \"%s\"", w);
}

/* stop processing, we are in a comment */
if (hash_ptr) {
break;
}
}

return AUTHZ_DENIED;
}

/* copy of host_parse_config */
static const char *name_parse_config(cmd_parms *cmd, const char *require_line,
 const void **parsed_require_line)
{
const char *expr_err = NULL;
ap_expr_info_t *expr;

expr = ap_expr_parse_cmd(cmd, require_line, AP_EXPR_FLAG_STRING_RESULT,
_err, NULL);

if (expr_err)
return apr_pstrcat(cmd->temp_pool,
   "Cannot parse expression in require line: ",
   expr_err, NULL);

*parsed_require_line = expr;

return NULL;
}

static const authz_provider authz_name_provider =
{
_check_authorization,
_parse_config,
};

static void register_hooks(apr_pool_t *p)
{
ap_register_auth_provider(p, AUTHZ_PROVIDER_GROUP, "name",
  AUTHZ_PROVIDER_VERSION,
  _name_provider,
  AP_AUTH_INTERNAL_PER_CONF);
}

Re: Segfault on graceful reload with OCSP stapling enabled?

2015-12-21 Thread Micha Lenk


Hi all,

Am 18.12.2015 12:35, schrieb Micha Lenk:

I am currently observing a httpd segfault that is triggered on my
system by every second graceful reload (i.e. SIGUSR1).

Unfotunately I won't be able to trace this down before Monday, so this
is merely a heads-up for those interested.
Is anybody able to reproduce this behavior?


Just for the records, the segfault seems to be caused by a bad patch.
So sorry for the noise...

Best regards,
Micha

Re: Segfault on graceful reload with OCSP stapling enabled?

2015-12-21 Thread Jeff Trawick

On Mon, Dec 21, 2015 at 8:09 AM, Micha Lenk  wrote:

> Hi all,
>
> Am 18.12.2015 12:35, schrieb Micha Lenk:
>
>> I am currently observing a httpd segfault that is triggered on my
>> system by every second graceful reload (i.e. SIGUSR1).
>>
>> Unfotunately I won't be able to trace this down before Monday, so this
>> is merely a heads-up for those interested.
>> Is anybody able to reproduce this behavior?
>>
>
> Just for the records, the segfault seems to be caused by a bad patch.
> So sorry for the noise...
>

Thanks for reporting back/glad it is resolved!


>
> Best regards,
> Micha
>



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

Re: doxygen docs

2015-12-21 Thread Luca Toscano

Hi Alan,

the daily build was broken, it has been fixed now! (thanks to Humbedooh)

Luca

2015-12-15 19:12 GMT+01:00 Alan Nilsson :

> There used to be an online doxygen API ref @
> https://ci.apache.org/projects/httpd/trunk/doxygen/.  That has been gone
> for a while now.
>
> Does anyone know of another online API ref for 2.4?  Or does anyone have a
> working doxygen conf to build from the source tree?  I cannot seem to get
> doxygen to generate very well.
>
> thanks
> alan
>
>

Re: OpenSSL 0.9.8/1.0.0 on Trunk

Re: OpenSSL 0.9.8/1.0.0 on Trunk

Re: OpenSSL 0.9.8/1.0.0 on Trunk

Re: doxygen docs

[PATCH] Reduce memory footprint in mod_dav's property code

Re: OpenSSL 0.9.8/1.0.0 on Trunk

Re: svn commit: r1721121 - in /httpd/httpd/trunk/modules/http2: h2_h2.c h2_io.c h2_io.h h2_mplx.h h2_push.c h2_request.c h2_request.h h2_session.c h2_session.h h2_stream.c h2_stream.h h2_task.c h2_tas

Re: OpenSSL 0.9.8/1.0.0 on Trunk

Re: [PATCH] Reduce memory footprint in mod_dav's property code

Re: access control for dynamic hosts

Re: Segfault on graceful reload with OCSP stapling enabled?

Re: Segfault on graceful reload with OCSP stapling enabled?

Re: doxygen docs

13 matches

Site Navigation

Mail list logo

Footer information