On Fri, Mar 13, 2009 at 5:00 AM, Hans <[email protected]> wrote: > > I still get the same issues with rendering of {+p} in search fmt=
Hans, I'm still working on this, but wanted to think some more about how we handle this utf thing. One thought is to keep all the page names urlencoded and only decode them at the end of the domarkup function. That means we never have problems with filtering, and don't need multiple encode/decode lines all through the code. I'm still concerned about the security implications though. We can now disable the < in utf output, but I'm uncomfortable getting rid of all our input filters, and what that might mean. So until I get some time to really think about, examine, analyze, perhaps even ask Pm or someone some questions, I haven't done anything more with utf. It would probably just end up getting removed later anyway. The last release wasn't so much an upgrade as an emergency security fix. I won't go into details, but with utfpages turned on we had at least one major vulnerability--I absolutely had to patch it. The rest will come later. Next week may be a bit less hectic for me. Though, I'm not sure... Linly, I usually just track things in my inbox. We could set up a BITS system but I really don't have time to manage it. And I'm hoping things will slow down once we hit 3.xx. I really am planning on getting hard nosed about new features then. And so far I've usually been able to patch bugs more or less as quick as they pop up. So I'd hesitate to do something until it's pretty clear it's really needed. We've gone through quite a bit without one... Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
