Re: apr 1.4.3, apr-util 1.3.11
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
On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben b...@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
On 3/23/2011 7:02 AM, Jeff Trawick wrote: On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawick traw...@gmail.com wrote: On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben b...@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
On 23.03.2011 13:02, Jeff Trawick wrote: On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawicktraw...@gmail.com wrote: On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijbenb...@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 Ruppertsr 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
On Wed, Mar 23, 2011 at 2:56 PM, Stefan Ruppert s...@myarm.com wrote: On 23.03.2011 13:02, Jeff Trawick wrote: On Mon, Mar 14, 2011 at 10:59 AM, Jeff Trawicktraw...@gmail.com wrote: On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijbenb...@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 Ruppertsr 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
On 3/23/2011 2:02 PM, Jeff Trawick wrote: On Wed, Mar 23, 2011 at 2:56 PM, Stefan Ruppert s...@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
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 s...@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
-Original Message- From: William A. Rowe Jr. [mailto:wr...@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
On Mon, Mar 14, 2011 at 9:02 AM, Bert Huijben b...@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
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
-Original Message- From: William A. Rowe Jr. [mailto:wr...@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
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
-Original Message- From: William A. Rowe Jr. [mailto:wr...@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
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
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
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
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!
