apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Fwd: Prior to apr 2.0 / httpd 2.4...
Date Tue, 22 Mar 2011 00:04:15 GMT
On 3/21/2011 6:06 PM, Greg Stein wrote:
> I saw "dev" and was thinking this was on dev@apr... but it was @httpd.
> 
> Anyways... APR peeps: see below.
> 
> 
> ---------- Forwarded message ----------
> From: Greg Stein <gstein@gmail.com>
> Date: Mon, Mar 21, 2011 at 10:38
> Subject: Re: Prior to apr 2.0 / httpd 2.4...
> To: dev@httpd.apache.org, "William A. Rowe Jr." <wrowe@rowe-clan.net>
> 
> 
> On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
>> On 3/20/2011 7:43 PM, Dan Poirier wrote:
>>> On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr." <wrowe@rowe-clan.net>
wrote:
>>>>
>>>> [1] Note particularly that expat appears to be abandoned, no releases
>>>> in almost 4 yrs, with a significant security issue hanging over it we
>>>> patched in apr.  No effort appears to be expended in providing any
>>>> alternate non-expat apr_xml interfaces.
>>>
>>> For APR to continue bundling expat seems easiest, in the absence of
>>> anyone motivated to do something more.
>>
>> I wish we had a better understanding of where expat is headed, or if it
>> is truly abandoned.  It seems strange to rely on an orphaned dependency.
>>
>> Anyone have any inside knowledge or informed opinion?
> 
> I'm a committer on Expat, but (as you've noted) the project has had no
> attention for quite a while. I wasn't aware of a security problem in
> there, however.

Yea, it's lingered for a long while, downstream most everyone has patched
around the cruft.  But it does raise eyebrows.  With that exception 2.0.1
pretty much works as-promised

> Even if I dropped a new release of Expat, would we want to rely on the
> external build (and latest release being propagated) or continue to
> ship a patched Expat within APR?

'build' - you mean package?  Yes, we default to an external apr today
if one is found.  With none detected, ./configure works up apr's distro.

For 2.0 I'd like to see us shift our expectation if we build in tree,
to expat/ sitting in parallel to apr/ - but that's minor.  It would
allow downstream users to either bundle or leave expat 2.0.2 unbundled
and apr project wouldn't have to worry about new security issues at
some point in the future when 0.9/1.x are less frequently distributed.

> Switching to libxml2 would be possible (it is MIT licensed), but would
> require a lot more coding work in the xml support. Users of APR (1.x)
> also depend on Expat being available, and a switch would require them
> to rewrite their XML parsing code. Maybe that is acceptable for apps
> to switch to 2.0?

Of course those users could continue to link to expat.  Are you saying
they doing cross apr<>expat manipulation?  That sounds as unsound as our
current ldap practices.

I'm looking forward to what niq puts forward for a libxml2 alternative
choice.

> In short: I can make a release happen, but would that matter to the APR project?

It matters to expat from a credibility perspective, and it allows httpd to
toss in 2.0.2 expat sources into their srclib/ distribution.  I don't know
that apr cares.


Mime
View raw message