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 <[email protected]> > Date: Mon, Mar 21, 2011 at 10:38 > Subject: Re: Prior to apr 2.0 / httpd 2.4... > To: [email protected], "William A. Rowe Jr." <[email protected]> > > > On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <[email protected]> > 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." >>> <[email protected]> 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.
