You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2011/03/12 22:13:14 UTC
Re: apr 1.4.3, apr-util 1.3.11
On 3/12/2011 7:31 AM, Jeff Trawick wrote:
> lots of fixes awaiting apr 1.4.3, a few fixes awaiting apr-util 1.3.11
>
> there's perhaps even some low hanging fruit in bugzilla, but I think
> we're going to need to pull out the machete and do some general
> cleaning so that the useful reports are more obvious
>
> I volunteer to T & R
>
> if you're working on fixes, please suggest a date by which you can
> complete any work you want to do for the next release (no, this isn't
> &dayjob; but it would be great to have a general idea)
Wouldn't it be better to do this on the dev@apr list? Or at least hit
all the affected projects e.g. svn, log4cpp etc :)
I have a very short list of things to work on for apr 1.4/util 1.3 branches
that I think I expect I can wrap up this coming week, several of them being
championed by subversion. I'll push off all of the apr 1.5-2.0/util 1.4
thoughts from discussion until the week after.
Re: apr 1.4.3, apr-util 1.3.11
Posted by Guenter Knauf <fu...@apache.org>.
Hi Bill,
Am 14.03.2011 18:39, schrieb William A. Rowe Jr.:
> On 3/14/2011 12:32 PM, Bert Huijben wrote:
>>
>> Any application that uses apr_filepath_merge() to get an absolute pathfrom a relative path is broken.... but only if the current directory before starting the application is based on a lower case drive letter.
>>
>> This is not a common condition, but this patch just fixes that specific error condition.
>>
>> It doesn't alter the comparison of paths.... It fixes an API bug.
>
> Yea, I think that apr_filepath_merge() and apr_filepath_get() are at the
> root of this real issue, and that the result, not the comparison, was
> what was broken. I have no real interest in ensuring that the path
> name manipulation in your test remains valid, but we agree there is an
> underlying, real issue here. I've seen 16 bit apps do similar things
> to corrupt the current path, and am looking at both cases together.
I think since we agree that we have a bug with APR + we have a working
fix for it we should go with the fix and backport it to all branches for
now. Sure I agree with you that we should always look for root causes
rather than intruducing workarounds - but what I not agree is to veto
working fixes and delaying upcoming releases. Look, we had last release
2010-04-03, and in few days that means one year back! I strongly hope
that we get this release now out before the year is full, and that are
only few days! You can at any time later look for a better fix which
covers more error cases, and we casn do another release in 2 months, but
its not ok that we always hold back for these and that and keep fixes in
trunk only. For others the time moves on, and our end users / consumers
use releases rather than trunk code, and its not ok to do releases that
seldom, and even more not ok that we then get in releases rushes and
release APR, APU and two httpds at same time.
Jeff has proposed to release now for 2nd time (last time was before
christmas when I asked for), and we should this time get the babe out
soon, and before we get next httpd release where Jim is urging for.
And BTW I would really like to see a more regulary release intervall,
f.e. at least all 4 months - regardless if we have only 1 fix since last
release, or 100.
My 3ct.
Gün.
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/14/2011 6:31 PM, Guenter Knauf wrote:
> I think since we agree that we have a bug with APR + we have a working fix for it we
> should go with the fix and backport it to all branches for now. Sure I agree with you that
> we should always look for root causes rather than intruducing workarounds
Sorry, totally disagree when you talk about any parsers. They tend to be
the root of most security issues and nearly all interop problems.
As I said *Saturday* to no objections, I would plow through all such issues
over the course of this week. So, no, I disagree with applying this without
thinking it through (if someone is using this to compare canonical paths,
the new 'feature' introduces a security hole, and if this was a problem in
the past, it may represent already existing security holes in the consumer).
It's actually third on my apr-plate, meaning this now distracts me from
finishing my review of all these single unix specs and legacy behaviors
for the undefined bits to ensure my fnmatch optimization logic is correct.
So please, don't backport until this coming Saturday, if Bert and I haven't
found a better resolution. kthx
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/14/2011 12:32 PM, Bert Huijben wrote:
>
> Any application that uses apr_filepath_merge() to get an absolute path from a relative path is broken.... but only if the current directory before starting the application is based on a lower case drive letter.
>
> This is not a common condition, but this patch just fixes that specific error condition.
>
> It doesn't alter the comparison of paths.... It fixes an API bug.
Yea, I think that apr_filepath_merge() and apr_filepath_get() are at the
root of this real issue, and that the result, not the comparison, was
what was broken. I have no real interest in ensuring that the path
name manipulation in your test remains valid, but we agree there is an
underlying, real issue here. I've seen 16 bit apps do similar things
to corrupt the current path, and am looking at both cases together.
RE: apr 1.4.3, apr-util 1.3.11
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: maandag 14 maart 2011 18:22
> To: Bert Huijben; APR Developer List
> Subject: Re: apr 1.4.3, apr-util 1.3.11
>
> On 3/14/2011 12:11 PM, Bert Huijben wrote:
> >>
> >> Sorry to have left it hanging.
> >
> > As long as it properly fixes the testcase added with this patch, I really don't
> mind a better fix.
> >
> > Normally you get in this state before starting the application that uses Apr;
> not from inside the application (see the original thread from November
> 2009). So getting in the error state is not an application error!
> > But reproducing it that way would require a more extensive test.
>
> Well, what I want to clarify is that, with this patch, does *your* application
> actually work comparing C:/Program Files from c:/progra~1/ from
> C:\PROGRAM FILES
> etc? If not, this was a mis-application of apr's comparison API. If it does,
> then this fix (or something related, perhaps fixing apr_filepath_get()) might
> be more appropriate.
These examples don't apply to this change.
It just makes "C:\PROGRAM FILES" equivalent to "c:\PROGRAM FILES" in this specific check deep inside apr_filepath_merge(). Any other change would make it unequal.
It fixes that single letter compare of the drive letter which caused the merge filepath api to choke on the example I added as a testcase.
When your current directory happens to be "c:\hello" instead of "C:\hello" then you can't use apr_filepath_merge() without this patch.
Any application that uses apr_filepath_merge() to get an absolute path from a relative path is broken.... but only if the current directory before starting the application is based on a lower case drive letter.
This is not a common condition, but this patch just fixes that specific error condition.
It doesn't alter the comparison of paths.... It fixes an API bug.
Bert
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/14/2011 12:11 PM, Bert Huijben wrote:
>>
>> Sorry to have left it hanging.
>
> As long as it properly fixes the testcase added with this patch, I really don't mind a better fix.
>
> Normally you get in this state before starting the application that uses Apr; not from inside the application (see the original thread from November 2009). So getting in the error state is not an application error!
> But reproducing it that way would require a more extensive test.
Well, what I want to clarify is that, with this patch, does *your* application
actually work comparing C:/Program Files from c:/progra~1/ from C:\PROGRAM FILES
etc? If not, this was a mis-application of apr's comparison API. If it does,
then this fix (or something related, perhaps fixing apr_filepath_get()) might
be more appropriate.
RE: apr 1.4.3, apr-util 1.3.11
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: maandag 14 maart 2011 17:14
> To: dev@apr.apache.org
> Subject: Re: apr 1.4.3, apr-util 1.3.11
>
> On 3/14/2011 8:02 AM, Bert Huijben wrote:
> >
> > I would really like to see r960665 ported back and released in the next
> release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>
> Agreed in principal, which is why this is on my short list already
> when I replied to Jeff. As you know, I believe this change is
> incorrect, you shouldn't be able to get canonical APR paths into
> this state, which is why I need to spend cycles [I hadn't had yet].
> Either way, I'll veto the change on trunk with the explanation or
> backport this patch, this week.
>
> Sorry to have left it hanging.
As long as it properly fixes the testcase added with this patch, I really don't mind a better fix.
Normally you get in this state before starting the application that uses Apr; not from inside the application (see the original thread from November 2009). So getting in the error state is not an application error!
But reproducing it that way would require a more extensive test.
Bert
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/14/2011 8:02 AM, Bert Huijben wrote:
>
> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
Agreed in principal, which is why this is on my short list already
when I replied to Jeff. As you know, I believe this change is
incorrect, you shouldn't be able to get canonical APR paths into
this state, which is why I need to spend cycles [I hadn't had yet].
Either way, I'll veto the change on trunk with the explanation or
backport this patch, this week.
Sorry to have left it hanging.
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/4/2011 12:02 PM, Jeff Trawick wrote:
>>
>> The issues I'm working on should be wrapped up by Thursday evening.
>
> have a new ETA?
For APR, I have the crt malloc patch for VC10 ready to commit once I've
finished bumping to VC10 myself. Then it's simply Bert's work identifying
the filename case sensitivity, my observations about short-pathname CWD's
(probably one in the same issue), and win32 symlink recognition (both the
junction style, which seems to trip up svn on win32 just a bit, and our
newer sibling in Win2008 'true' symlinks).
For APR-util, it's simply fnmatch optimization to avoid recursion and
redundant trailing filename segment matches (about 75% done). This one
I'll be hoping for extra eyeballs when its committed.
These things above I can have done give some hours I've set aside tomorrow
and Thursday.
For both (due to trunk changes), I have the complete reworking of the
apr_crypto declarations (about 50% done, headers fixed, code to follow).
And obviously that never had enough eyeballs, but there is no rush for
code review since it would just herald a brand new apr version minor
and let us get closer to releasing apr 2.0.
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Mar 23, 2011 at 12:10 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 3/23/2011 7:02 AM, Jeff Trawick wrote:
>> On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>> On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>>
>>>> Repeating my requests from last year:
>>>>
>>>> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>>>
>>> Any concerns out there with this fix for Windows? There's no CHANGES
>>> entry, so it may have been overlooked.
>>
>> (wrowe discussed this previously, and may or may not get time to
>> resolve in the short term)
>
> I'll be able to propose the resolution by midday Thursday and make sure that
> Bert and I are satisfied with the solution from the svn perspective.
>
>>> A couple of other fixes in trunk CHANGES to consider backporting:
>>>
>>> *) apr_dbd_oracle: fix endianness issue in prepared statements
>>> PR 50690 [Stefan Ruppert <sr myarm.com>]
>>>
>>> *) Fix address handling when accepting an AF_INET socket from a socket
>>> bound as AF_INET6. PR 49678. [Joe Orton]
>>
>> I forgot about these two, and will go look.
>>
>> What else before 1.4.3/1.3.11?
>>
>> * wrowe is working on another issue which (I guess) requires a couple more days
>> * I may find time to backport some revisions from trunk to get MinGW
>> in better shape if I'm "sure" it won't break anything else
>> ** several trunk revisions of .in/.m4 foo will get 1.4.x running the
>> test suite pretty well; call it "experimental" since the feature set
>> doesn't exactly match a normal Windows build, it only builds static
>> libs, etc.)
>
> The issues I'm working on should be wrapped up by Thursday evening.
have a new ETA?
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/23/2011 7:02 AM, Jeff Trawick wrote:
> On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick <tr...@gmail.com> wrote:
>> On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben <be...@qqmail.nl> wrote:
>>
>>> Repeating my requests from last year:
>>>
>>> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>>
>> Any concerns out there with this fix for Windows? There's no CHANGES
>> entry, so it may have been overlooked.
>
> (wrowe discussed this previously, and may or may not get time to
> resolve in the short term)
I'll be able to propose the resolution by midday Thursday and make sure that
Bert and I are satisfied with the solution from the svn perspective.
>> A couple of other fixes in trunk CHANGES to consider backporting:
>>
>> *) apr_dbd_oracle: fix endianness issue in prepared statements
>> PR 50690 [Stefan Ruppert <sr myarm.com>]
>>
>> *) Fix address handling when accepting an AF_INET socket from a socket
>> bound as AF_INET6. PR 49678. [Joe Orton]
>
> I forgot about these two, and will go look.
>
> What else before 1.4.3/1.3.11?
>
> * wrowe is working on another issue which (I guess) requires a couple more days
> * I may find time to backport some revisions from trunk to get MinGW
> in better shape if I'm "sure" it won't break anything else
> ** several trunk revisions of .in/.m4 foo will get 1.4.x running the
> test suite pretty well; call it "experimental" since the feature set
> doesn't exactly match a normal Windows build, it only builds static
> libs, etc.)
The issues I'm working on should be wrapped up by Thursday evening.
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Mar 23, 2011 at 5:41 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 3/23/2011 2:02 PM, Jeff Trawick wrote:
>> On Wed, Mar 23, 2011 at 2:56 PM, Stefan Ruppert <sr...@myarm.com> wrote:
>>>
>>> What about https://issues.apache.org/bugzilla/show_bug.cgi?id=49882
>>>
>>> Its really a simple patch and closes a semantic issue on windows for
>>> apr_pollset_poll()!
>>
>> Thanks for the pointer; I'll have a look.
>
> It looks good here, although it seems like an odd expectation for poll :)
I pulled on the thread and got a lifetime supply ;) Patch for
consideration or just amusement coming shortly after I double-check
the new testcase on Linux once again.
>
--
Born in Roswell... married an alien...
Re: apr 1.4.3, apr-util 1.3.11
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/23/2011 2:02 PM, Jeff Trawick wrote:
> On Wed, Mar 23, 2011 at 2:56 PM, Stefan Ruppert <sr...@myarm.com> wrote:
>>
>> What about https://issues.apache.org/bugzilla/show_bug.cgi?id=49882
>>
>> Its really a simple patch and closes a semantic issue on windows for
>> apr_pollset_poll()!
>
> Thanks for the pointer; I'll have a look.
It looks good here, although it seems like an odd expectation for poll :)
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Mar 23, 2011 at 2:56 PM, Stefan Ruppert <sr...@myarm.com> wrote:
> On 23.03.2011 13:02, Jeff Trawick wrote:
>>
>> On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick<tr...@gmail.com> wrote:
>>>
>>> On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben<be...@qqmail.nl> wrote:
>>>
>>>> Repeating my requests from last year:
>>>>
>>>> I would really like to see r960665 ported back and released in the next
>>>> release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>>>
>>> Any concerns out there with this fix for Windows? There's no CHANGES
>>> entry, so it may have been overlooked.
>>
>> (wrowe discussed this previously, and may or may not get time to
>> resolve in the short term)
>>
>>> A couple of other fixes in trunk CHANGES to consider backporting:
>>>
>>> *) apr_dbd_oracle: fix endianness issue in prepared statements
>>> PR 50690 [Stefan Ruppert<sr myarm.com>]
>>>
>>> *) Fix address handling when accepting an AF_INET socket from a socket
>>> bound as AF_INET6. PR 49678. [Joe Orton]
>>
>> I forgot about these two, and will go look.
>>
>> What else before 1.4.3/1.3.11?
>
> What about https://issues.apache.org/bugzilla/show_bug.cgi?id=49882
>
> Its really a simple patch and closes a semantic issue on windows for
> apr_pollset_poll()!
Thanks for the pointer; I'll have a look.
Re: apr 1.4.3, apr-util 1.3.11
Posted by Stefan Ruppert <sr...@myarm.com>.
On 23.03.2011 13:02, Jeff Trawick wrote:
> On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick<tr...@gmail.com> wrote:
>> On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben<be...@qqmail.nl> wrote:
>>
>>> Repeating my requests from last year:
>>>
>>> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>>
>> Any concerns out there with this fix for Windows? There's no CHANGES
>> entry, so it may have been overlooked.
>
> (wrowe discussed this previously, and may or may not get time to
> resolve in the short term)
>
>> A couple of other fixes in trunk CHANGES to consider backporting:
>>
>> *) apr_dbd_oracle: fix endianness issue in prepared statements
>> PR 50690 [Stefan Ruppert<sr myarm.com>]
>>
>> *) Fix address handling when accepting an AF_INET socket from a socket
>> bound as AF_INET6. PR 49678. [Joe Orton]
>
> I forgot about these two, and will go look.
>
> What else before 1.4.3/1.3.11?
What about https://issues.apache.org/bugzilla/show_bug.cgi?id=49882
Its really a simple patch and closes a semantic issue on windows for
apr_pollset_poll()!
Stefan
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>> Repeating my requests from last year:
>>
>> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
>
> Any concerns out there with this fix for Windows? There's no CHANGES
> entry, so it may have been overlooked.
(wrowe discussed this previously, and may or may not get time to
resolve in the short term)
> A couple of other fixes in trunk CHANGES to consider backporting:
>
> *) apr_dbd_oracle: fix endianness issue in prepared statements
> PR 50690 [Stefan Ruppert <sr myarm.com>]
>
> *) Fix address handling when accepting an AF_INET socket from a socket
> bound as AF_INET6. PR 49678. [Joe Orton]
I forgot about these two, and will go look.
What else before 1.4.3/1.3.11?
* wrowe is working on another issue which (I guess) requires a couple more days
* I may find time to backport some revisions from trunk to get MinGW
in better shape if I'm "sure" it won't break anything else
** several trunk revisions of .in/.m4 foo will get 1.4.x running the
test suite pretty well; call it "experimental" since the feature set
doesn't exactly match a normal Windows build, it only builds static
libs, etc.)
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Repeating my requests from last year:
>
> I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
Any concerns out there with this fix for Windows? There's no CHANGES
entry, so it may have been overlooked.
A couple of other fixes in trunk CHANGES to consider backporting:
*) apr_dbd_oracle: fix endianness issue in prepared statements
PR 50690 [Stefan Ruppert <sr myarm.com>]
*) Fix address handling when accepting an AF_INET socket from a socket
bound as AF_INET6. PR 49678. [Joe Orton]
I don't see anything else in CHANGES.
RE: apr 1.4.3, apr-util 1.3.11
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: zaterdag 12 maart 2011 22:13
> To: APR Developer List
> Subject: Re: apr 1.4.3, apr-util 1.3.11
>
> On 3/12/2011 7:31 AM, Jeff Trawick wrote:
> > lots of fixes awaiting apr 1.4.3, a few fixes awaiting apr-util 1.3.11
> >
> > there's perhaps even some low hanging fruit in bugzilla, but I think
> > we're going to need to pull out the machete and do some general
> > cleaning so that the useful reports are more obvious
> >
> > I volunteer to T & R
> >
> > if you're working on fixes, please suggest a date by which you can
> > complete any work you want to do for the next release (no, this isn't
> > &dayjob; but it would be great to have a general idea)
>
> Wouldn't it be better to do this on the dev@apr list? Or at least hit
> all the affected projects e.g. svn, log4cpp etc :)
>
> I have a very short list of things to work on for apr 1.4/util 1.3 branches
> that I think I expect I can wrap up this coming week, several of them being
> championed by subversion. I'll push off all of the apr 1.5-2.0/util 1.4
> thoughts from discussion until the week after.
Repeating my requests from last year:
I would really like to see r960665 ported back and released in the next release to fix this Apr issue, before Subversion 1.7.0 goes in public beta.
Bert
PS: My apache username is rhuijben
Re: apr 1.4.3, apr-util 1.3.11
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Mar 12, 2011 at 4:13 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 3/12/2011 7:31 AM, Jeff Trawick wrote:
>> lots of fixes awaiting apr 1.4.3, a few fixes awaiting apr-util 1.3.11
>>
>> there's perhaps even some low hanging fruit in bugzilla, but I think
>> we're going to need to pull out the machete and do some general
>> cleaning so that the useful reports are more obvious
>>
>> I volunteer to T & R
>>
>> if you're working on fixes, please suggest a date by which you can
>> complete any work you want to do for the next release (no, this isn't
>> &dayjob; but it would be great to have a general idea)
>
> Wouldn't it be better to do this on the dev@apr list? Or at least hit
> all the affected projects e.g. svn, log4cpp etc :)
(blush)
> I have a very short list of things to work on for apr 1.4/util 1.3 branches
> that I think I expect I can wrap up this coming week, several of them being
> championed by subversion. I'll push off all of the apr 1.5-2.0/util 1.4
> thoughts from discussion until the week after.
cool!