Thanks, I'll back port to J-T-C....
- Henri Gomez ___[_]____ EMAIL : [EMAIL PROTECTED] (. .) PGP KEY : 697ECEDD ...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 >-----Original Message----- >From: Bill Barker [mailto:[EMAIL PROTECTED]] >Sent: Thursday, September 27, 2001 2:42 AM >To: [EMAIL PROTECTED] >Subject: Re: [PATCH] Potential buffer overflow attach in mod_jk > > >Here's with jk_pool_strdup (against RC1, not HEAD). It looked >to me like >uw_map->p wasn't suitable for per-request allocations (i.e. it >would just >eat memory until the server was re-started), and since this is >in common, I >couldn't use ap_strdup since that breaks all non-Apache servers. >----- Original Message ----- >From: "Keith Wannamaker" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, September 26, 2001 5:25 PM >Subject: RE: [PATCH] Potential buffer overflow attach in mod_jk > > >> Hi Bill, would you resubmit a patch that makes use of either >> Apache or jk's pools? ie ap_strdup or jk_pool_strdup. >> That would be a better way to solve the problem. Apache >> modules should and do avoid os memory-allocation routines >> like the plague. I think uw_map->p would be ok, but please >> do some testing. >> >> Thanks, >> Keith >> >> | -----Original Message----- >> | From: Bill Barker [mailto:[EMAIL PROTECTED]] >> | Sent: Wednesday, September 26, 2001 2:37 PM >> | To: [EMAIL PROTECTED] >> | Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk >> | >> | >> | Urm, let's try that again with a patch that at least compiles...... >> >> > > >*----* > >This message is intended only for the use of the person(s) >listed above >as the intended recipient(s), and may contain information that is >PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, >you may not read, copy, or distribute this message or any attachment. >If you received this communication in error, please notify us >immediately >by e-mail and then delete all copies of this message and any >attachments. > > >In addition you should be aware that ordinary (unencrypted) >e-mail sent >through the Internet is not secure. Do not send confidential >or sensitive >information, such as social security numbers, account numbers, >personal >identification numbers and passwords, to us via ordinary (unencrypted) >e-mail. >
