On Thu, 12 Sep 2013 15:18:47 -0700 Gregg Smith <[email protected]> wrote:
> On 9/12/2013 11:10 AM, Jeff Trawick wrote: > > > > IIUC the Windows build is commit-then-review, so I'll commit the > > similar 2.4 changes to BaseAddr.ref based on a 64-bit debug build > > with Visual Studio 2012 tools. > > > No, the only thing in 2.4 I know of that is CTR is mod_lua, as for > anything else, if I thought it was CTR I'd have backported my > r1505178 at that time. That said however, I do not see this as > hurting as we have time to fix it if a problem is found before the > next tag. I'll run both release & debug builds myself this weekend > and look though the output. One never knows if there is a difference > between your cmake and my way of building the beast :) Please avoid re-sequencing modules during a subversion bump. At least, apply the absolutely minimum delta (leave most modules where they are and move the offending module to a new, wider base address). This avoid potential load-time fixups if the user reverts to a prior or pushes to a newer module along the same major.minor release family. It's entirely reasonable (given our versioning rules) for someone to substitute a module prior to a regression being introduced, or for someone to replace only a single module to test whether or not the new module (/version) fixes a bug they are experiencing. On this topic, it's entirely reasonable that we might want to adopt (or let the builder elect to adopt) the load address randomization techniques, to make remote code execution harder to exploit. Right now I think we have no (few) errors in run time symbol resolution (the reason which we do all the painful AP_DECLARE_DATA logic - this causes the data resolution to use indirection and subjects it to load time address fixups). There are painful examples of where such logic can't work - openssl FIPS self-validation code, for example. But for the vast majority of httpd and apr distributed code, IJW.
