You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/03/21 00:47:25 UTC
Prior to apr 2.0 / httpd 2.4...
Nobody has offered a reasonable response, let's try this again... the
availability of pcre and expat are generally a both-or-neither proposition
on most distributions. Ergo, any one of the following resolutions would
restore logically consistency to the next-generation distribution...
[ ] apr 2.0 should resume bundling expat 2.0.1 fork[1]
[ ] expat helpers should be dropped from apr 2.0,
while httpd should assume an ap_ interface to expat
with expat distributed with httpd-deps
[ ] expat helpers should be dropped from apr 2.0,
in favor of direct consumption of expat 2.x by httpd,
with expat distributed with httpd-deps
[ ] httpd will ship expat in srclib/apr/xml
in spite of apr project decisions
[ ] httpd-deps should drop pcre
[ ] httpd-deps should be dropped
Simple majority, will re-offer this vote with the lowest vote getter dropped
until we have consensus. Votes please?
[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.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Guenter Knauf <fu...@apache.org>.
Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
> Nobody has offered a reasonable response, let's try this again... the
> availability of pcre and expat are generally a both-or-neither proposition
> on most distributions. Ergo, any one of the following resolutions would
> restore logically consistency to the next-generation distribution...
>
> [x] apr 2.0 should resume bundling expat 2.0.1 fork[1]
> [ ] expat helpers should be dropped from apr 2.0,
> while httpd should assume an ap_ interface to expat
> with expat distributed with httpd-deps
> [ ] expat helpers should be dropped from apr 2.0,
> in favor of direct consumption of expat 2.x by httpd,
> with expat distributed with httpd-deps
> [ ] httpd will ship expat in srclib/apr/xml
> in spite of apr project decisions
> [ ] httpd-deps should drop pcre
> [ ] httpd-deps should be dropped
>
Gün.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by dreamice <dr...@gmail.com>.
When will httpd-2.4 be released?
2011/3/21 William A. Rowe Jr. <wr...@rowe-clan.net>
> On 3/20/2011 8:26 PM, Guenter Knauf wrote:
> > Am 21.03.2011 01:29, schrieb William A. Rowe Jr.:
> >> On 3/20/2011 7:10 PM, Guenter Knauf wrote:
> >>> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
> >>>> [ ] httpd-deps should drop pcre
> >>> huh? how can we drop it again? we have already with HEAD;
> >>> better would be another point to select including it with the
> httpd-deps tarball.
> >>
> >> It is brought into -deps, no? [Looks...]
> > no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util,
> nothing else.
>
> Sorry, I was being snarky towards myself, I realize that.
>
> So we were at "build zlib and openssl externally", now we are at "build
> zlib, openssl, pcre and expat externally". The net is really not that
> much of an issue (openssl is by far the most complex).
>
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/20/2011 8:26 PM, Guenter Knauf wrote:
> Am 21.03.2011 01:29, schrieb William A. Rowe Jr.:
>> On 3/20/2011 7:10 PM, Guenter Knauf wrote:
>>> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
>>>> [ ] httpd-deps should drop pcre
>>> huh? how can we drop it again? we have already with HEAD;
>>> better would be another point to select including it with the httpd-deps tarball.
>>
>> It is brought into -deps, no? [Looks...]
> no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util, nothing else.
Sorry, I was being snarky towards myself, I realize that.
So we were at "build zlib and openssl externally", now we are at "build
zlib, openssl, pcre and expat externally". The net is really not that
much of an issue (openssl is by far the most complex).
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Guenter Knauf <fu...@apache.org>.
Am 21.03.2011 01:29, schrieb William A. Rowe Jr.:
> On 3/20/2011 7:10 PM, Guenter Knauf wrote:
>> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
>>> [ ] httpd-deps should drop pcre
>> huh? how can we drop it again? we have already with HEAD;
>> better would be another point to select including it with the httpd-deps tarball.
>
> It is brought into -deps, no? [Looks...]
no - my httpd-2.3.11-beta-deps.tar.bz2 does only contain apr/apr-util,
nothing else.
G.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/20/2011 7:10 PM, Guenter Knauf wrote:
> Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
>> [ ] httpd-deps should drop pcre
> huh? how can we drop it again? we have already with HEAD;
> better would be another point to select including it with the httpd-deps tarball.
It is brought into -deps, no? [Looks...]
of course, the item above is our final resolution, I had looked for expat in
the -deps package but hadn't thought to research pcre because I was under the
impression that we had retained it.
I'll go about disconnecting the win32 httpd-2.4 build from expat as well, so
that the net effect is to rely on pre-installed expat and pcre packages.
Thanks Gun,
Bill
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Guenter Knauf <fu...@apache.org>.
Am 21.03.2011 00:47, schrieb William A. Rowe Jr.:
> [ ] httpd-deps should drop pcre
huh? how can we drop it again? we have already with HEAD;
better would be another point to select including it with the httpd-deps
tarball.
Gün.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Mladen Turk <mt...@apache.org>.
On 03/21/2011 12:47 AM, William A. Rowe Jr. wrote:
> Nobody has offered a reasonable response, let's try this again... the
> availability of pcre and expat are generally a both-or-neither proposition
> on most distributions. Ergo, any one of the following resolutions would
> restore logically consistency to the next-generation distribution...
>
> [X] apr 2.0 should resume bundling expat 2.0.1 fork[1]
> [ ] expat helpers should be dropped from apr 2.0,
> while httpd should assume an ap_ interface to expat
> with expat distributed with httpd-deps
> [ ] expat helpers should be dropped from apr 2.0,
> in favor of direct consumption of expat 2.x by httpd,
> with expat distributed with httpd-deps
> [ ] httpd will ship expat in srclib/apr/xml
> in spite of apr project decisions
> [ ] httpd-deps should drop pcre
> [ ] httpd-deps should be dropped
>
> Simple majority, will re-offer this vote with the lowest vote getter dropped
> until we have consensus. Votes please?
>
> [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.
>
The first option seems the least invasive at the moment.
However since we have in many places the "provider" kind of API
I see no reason why the same shouldn't be done for xml parsers
and regular expressions. Think even httpd trunk has already some
code that uses both regex and pcre.
Regards
--
^TM
RE: Prior to apr 2.0 / httpd 2.4...
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: William A. Rowe Jr.
> Sent: Montag, 21. März 2011 00:47
> To: dev@httpd.apache.org
> Subject: Prior to apr 2.0 / httpd 2.4...
>
> Nobody has offered a reasonable response, let's try this again... the
> availability of pcre and expat are generally a
> both-or-neither proposition
> on most distributions. Ergo, any one of the following
> resolutions would
> restore logically consistency to the next-generation distribution...
>
> [+1 ] apr 2.0 should resume bundling expat 2.0.1 fork[1]
> [ ] expat helpers should be dropped from apr 2.0,
> while httpd should assume an ap_ interface to expat
> with expat distributed with httpd-deps
> [ ] expat helpers should be dropped from apr 2.0,
> in favor of direct consumption of expat 2.x by httpd,
> with expat distributed with httpd-deps
> [ ] httpd will ship expat in srclib/apr/xml
> in spite of apr project decisions
> [ ] httpd-deps should drop pcre
> [ ] httpd-deps should be dropped
>
Regards
Rüdiger
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 3:20 AM, Nick Kew wrote:
>
> If I were to substitute libxml2 and demonstrate an expat-free version
> of APR and HTTPD, would there be support for that? I'm thinking
> the choice of native XML parser could become a compile-time or
> even a run-time choice. I'd expect a quick&dirty prototype demo
> to be just a couple of hours work.
Absolutely; this seems like a topic for the apr list. It might alleviate
any 'necessity' to start bundling the xml parser again , if either-or could
be trivially consumed.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 3:20 AM, Nick Kew wrote:
>
> If I were to substitute libxml2 and demonstrate an expat-free version
> of APR and HTTPD, would there be support for that? I'm thinking
> the choice of native XML parser could become a compile-time or
> even a run-time choice. I'd expect a quick&dirty prototype demo
> to be just a couple of hours work.
Absolutely; this seems like a topic for the apr list. It might alleviate
any 'necessity' to start bundling the xml parser again , if either-or could
be trivially consumed.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Nick Kew <ni...@webthing.com>.
On 21 Mar 2011, at 01:13, William A. Rowe Jr. wrote:
> 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.
I think we can be relaxed about it. We're one of many users, and our usage
is hardly pushing the boundary.
On the other hand, the reason we're not pushing the boundary is that
to do so would be to re-invent the wheel. That is to say, applications
interested in markup are introducing other libraries with more capabilities.
Expat has proved too limiting.
That raises the question: is there mileage in dropping expat and
substituting libxml2? For our core usage, it's pretty-much a drop-in
replacement, and it's the basis for a whole bunch of hitherto-separate
applications like mod_proxy_html, mod_transform, mod_xml2 or
mod_security.
If I were to substitute libxml2 and demonstrate an expat-free version
of APR and HTTPD, would there be support for that? I'm thinking
the choice of native XML parser could become a compile-time or
even a run-time choice. I'd expect a quick&dirty prototype demo
to be just a couple of hours work.
--
Nick Kew
Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Guenter Knauf <fu...@apache.org>.
Greg,
Am 22.03.2011 00:05, schrieb Greg Stein:
> I don't see how httpd GA is related to serf?? ... certainly, you want
> serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
> libserf nowadays? (ie. one of the proxy modules?)
yep:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_serf.c?view=log
Gün.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Mar 21, 2011 at 12:23, Guenter Knauf <fu...@apache.org> wrote:
> Greg,
> Am 21.03.2011 15:38, schrieb Greg Stein:
>...
>> 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.
>>
>> 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?
>>
>> 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?
>
> I followed up with libxml2 for a while on NetWare, and every now and then
> compilation was broken with next release due to not only fixing bugs but
> also adding a bunch of new features which then require futher tweaks (search
> for stubs which provide missing OS functions in network layer, etc).
> Further more many projects dont care about issues with compilers which dont
> like declarations after statements, and often you then end up with
> uncompilable code :-(
Yeah. In Subversion, we have a bunch of Windows developers, and they
call out when declarations occur after statements :-)
>> In short: I can make a release happen, but would that matter to the APR
>> project?
>
> when I tried to compile for Win32 with Watcom C I had to add this to expat:
> --- expat.h.orig Mon Nov 27 03:51:58 2006
> +++ expat.h Mon Aug 09 16:27:36 2010
> @@ -193,11 +193,19 @@
> XML_XmlDeclHandler xmldecl);
>
>
> +#if defined(WIN32) && defined(__WATCOMC__)
> +typedef struct {
> + void * __watcall (*malloc_fcn)(size_t size);
> + void * __watcall (*realloc_fcn)(void *ptr, size_t size);
> + void __watcall (*free_fcn)(void *ptr);
> +} XML_Memory_Handling_Suite;
> +#else
> typedef struct {
> void *(*malloc_fcn)(size_t size);
> void *(*realloc_fcn)(void *ptr, size_t size);
> void (*free_fcn)(void *ptr);
> } XML_Memory_Handling_Suite;
> +#endif
Seems reasonable. There have been a number of other little compilation
bug reports that have crept in over time. Could probably spend a day
just closing out those issues.
> /* Constructs a new parser; encoding is the encoding specified by the
> external protocol or NULL if there is none specified.
>
> BTW. is there a public repo from where oen can fetch current code?
http://sourceforge.net/scm/?type=cvs&group_id=10127
> oh, and while on things to fix where you are commiter:
> another one who plays with httpd and subversion on NetWare told me that
> current code of libserf has its quirks on NetWare - are you willing to take
> a look into that before we go for httpd GA?
I don't see how httpd GA is related to serf?? ... certainly, you want
serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
libserf nowadays? (ie. one of the proxy modules?)
> And where to post patches? To you directly?
serf-dev@googlegroups.com
and/or open issues at code.google.com/p/serf/
Cheers,
-g
netware libserf quirks
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 11:23 AM, Guenter Knauf wrote:
>
> BTW. is there a public repo from where oen can fetch current code?
I presumed expat's home was http://sourceforge.net/projects/expat/ ... if it's
not, I'd like to know :)
> oh, and while on things to fix where you are commiter:
> another one who plays with httpd and subversion on NetWare told me that current code of
> libserf has its quirks on NetWare - are you willing to take a look into that before we go
> for httpd GA?
> And where to post patches? To you directly?
About serf, http://code.google.com/p/serf/ - and there are a few others here
on this list that are committers to serf.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Guenter Knauf <fu...@apache.org>.
Greg,
Am 21.03.2011 15:38, schrieb Greg Stein:
> On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr.<wr...@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."<wr...@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.
>
> 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?
>
> 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?
I followed up with libxml2 for a while on NetWare, and every now and
then compilation was broken with next release due to not only fixing
bugs but also adding a bunch of new features which then require futher
tweaks (search for stubs which provide missing OS functions in network
layer, etc).
Further more many projects dont care about issues with compilers which
dont like declarations after statements, and often you then end up with
uncompilable code :-(
> In short: I can make a release happen, but would that matter to the APR project?
when I tried to compile for Win32 with Watcom C I had to add this to expat:
--- expat.h.orig Mon Nov 27 03:51:58 2006
+++ expat.h Mon Aug 09 16:27:36 2010
@@ -193,11 +193,19 @@
XML_XmlDeclHandler xmldecl);
+#if defined(WIN32) && defined(__WATCOMC__)
+typedef struct {
+ void * __watcall (*malloc_fcn)(size_t size);
+ void * __watcall (*realloc_fcn)(void *ptr, size_t size);
+ void __watcall (*free_fcn)(void *ptr);
+} XML_Memory_Handling_Suite;
+#else
typedef struct {
void *(*malloc_fcn)(size_t size);
void *(*realloc_fcn)(void *ptr, size_t size);
void (*free_fcn)(void *ptr);
} XML_Memory_Handling_Suite;
+#endif
/* Constructs a new parser; encoding is the encoding specified by the
external protocol or NULL if there is none specified.
BTW. is there a public repo from where oen can fetch current code?
oh, and while on things to fix where you are commiter:
another one who plays with httpd and subversion on NetWare told me that
current code of libserf has its quirks on NetWare - are you willing to
take a look into that before we go for httpd GA?
And where to post patches? To you directly?
greets, Gün.
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 9:38 AM, Greg Stein wrote:
> On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wr...@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." <wr...@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.
>
> 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?
>
> 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?
>
> In short: I can make a release happen, but would that matter to the APR project?
Greg, I'm eagerly anticipating releases of openssl-1.0.1 and zlib-1.2.7
to include them in the Windows package. We won't be moving that target
very much over the course of the 2.4.x lifecycle, so I didn't care to
ship something with openssl 1.0.0 or other stale packages.
I see there is some commit activity. Is there any hope of an expat 2.0.2
in the near future, since these vulnerabilities have been know for about
half a year or more, now? I would really love to ship an httpd binary
which includes something more fresh than expat 1.9.7-tweaked.
Bill
Re: Fwd: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/21/2011 7:42 PM, Greg Stein wrote:
> Maybe we could simply detect the Expat version and provide a
> warning ("hey! get 2.0.2. we'll go with this, but you should update.")
+1
Re: Fwd: Prior to apr 2.0 / httpd 2.4...
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Mar 21, 2011 at 20:04, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 3/21/2011 6:06 PM, Greg Stein wrote:
>...
>> 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.
Oh, I'm all for unbundling. I think it is mostly about whether APR
wants to bundle the "best" Expat rather than potentially linking
against a non-secure version. Of course, I guess that could happen
today. Maybe we could simply detect the Expat version and provide a
warning ("hey! get 2.0.2. we'll go with this, but you should update.")
>> 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.
As a concrete example: Subversion directly uses the Expat APIs. We
depend upon apr-util to find/provide those APIs by including expat
into its exported link switches, or to compile/bundle Expat directly
into the apr-util library. That allows Subversion to skip a whole
bunch of config-time logic to locate/link against Expat.
Applications that expect this kind of behavior ("find me Expat") would
need to be be recoded to discover Expat for themselves. And/or
discover libxml2.
>...
>> 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.
Alrighty. Thanks.
Cheers,
-g
Re: Fwd: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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 <gs...@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." <wr...@rowe-clan.net>
>
>
> On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wr...@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." <wr...@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.
Fwd: Prior to apr 2.0 / httpd 2.4...
Posted by Greg Stein <gs...@gmail.com>.
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 <gs...@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." <wr...@rowe-clan.net>
On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wr...@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." <wr...@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.
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?
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?
In short: I can make a release happen, but would that matter to the APR project?
Cheers,
-g
Fwd: Prior to apr 2.0 / httpd 2.4...
Posted by Greg Stein <gs...@gmail.com>.
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 <gs...@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." <wr...@rowe-clan.net>
On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wr...@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." <wr...@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.
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?
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?
In short: I can make a release happen, but would that matter to the APR project?
Cheers,
-g
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. <wr...@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." <wr...@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.
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?
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?
In short: I can make a release happen, but would that matter to the APR project?
Cheers,
-g
Re: Prior to apr 2.0 / httpd 2.4...
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/20/2011 7:43 PM, Dan Poirier wrote:
> On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr." <wr...@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?
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Dan Poirier <po...@pobox.com>.
On Sun. 2011-03-20 at 07:47 PM EDT, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> Nobody has offered a reasonable response, let's try this again... the
> availability of pcre and expat are generally a both-or-neither proposition
> on most distributions. Ergo, any one of the following resolutions would
> restore logically consistency to the next-generation distribution...
>
> [X] apr 2.0 should resume bundling expat 2.0.1 fork[1]
> [ ] expat helpers should be dropped from apr 2.0,
> while httpd should assume an ap_ interface to expat
> with expat distributed with httpd-deps
> [ ] expat helpers should be dropped from apr 2.0,
> in favor of direct consumption of expat 2.x by httpd,
> with expat distributed with httpd-deps
> [ ] httpd will ship expat in srclib/apr/xml
> in spite of apr project decisions
> [ ] httpd-deps should drop pcre
> [ ] httpd-deps should be dropped
>
> Simple majority, will re-offer this vote with the lowest vote getter dropped
> until we have consensus. Votes please?
>
> [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.
Dan
Re: Prior to apr 2.0 / httpd 2.4...
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 20, 2011, at 7:47 PM, William A. Rowe Jr. wrote:
> Nobody has offered a reasonable response, let's try this again... the
> availability of pcre and expat are generally a both-or-neither proposition
> on most distributions. Ergo, any one of the following resolutions would
> restore logically consistency to the next-generation distribution...
>
> [+1] apr 2.0 should resume bundling expat 2.0.1 fork[1]