The recent problems with the handbook and other areas of the site (UNDEFINED STRING, etc) were caused by newer versions of XML-LibXML, libxslt and libxml2. From googling around, the problem appears to be with our XML/XSL code rather than the libs themselves. Can we please fix guidxml/projectxml/handbookxml/whateverelseisbrokexml so it will work with (at least) the following versions of libs: dev-libs/libxml2-2.6.6 dev-libs/libxslt-1.1.3 dev-perl/XML-LibXML-1.56-r1 Currently, we have to run the following in order for things to function correctly: <=dev-libs/libxml2-2.5.8 <=dev-libs/libxslt-1.0.33 <=dev-perl/XML-LibXML-1.54-r1 blackace might be able to help with this as well. (he doesn't have a bugzilla account atm -- working on getting him one so he can be cc'd)
I'll remove the localisation stuff we added so that the "UNDEFINED STRING" stuff isn't displayed anymore.
at the moment, there shouldn't be any undefined strings or, if there are, it's not due to the upgrade. We downgraded everything back to their previous versions across all nodes.
Sorry, wrong button
As a test, I upgraded libxslt and libxml2 on tern to the latest stable versions: dev-libs/libxslt-1.1.3 dev-libs/libxml2-2.6.6 The handbook appears to work fine now, as well as the grsecurity page (both of which were pointed out as "problematic pages" before: http://tern.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2 http://tern.gentoo.org/proj/en/hardened/grsecurity.xml Perhaps the problem was due to the aforementioned changes you removed?
I didn't remove them then, I did now, but no permanent issues (just commenting out stuff). I'll see if tern gives more errors later (when the cvs changes have dropped in) but I'm not 100% confident that all is fine now :(
I've reverted the updates again as they aren't source of the problem. Sorry if I scared you neysx :)
In testing stuff, I've noticed that AxKit's cache files can cause unexpected results when switching between various versions of libs. For anyone doing similar testing, I recommend doing the following when upgrading/downgrading any libs: * stop apache * remove all AxKit files in /tmp (I use "find /tmp -type d | grep "/tmp/[a-z0-9]\{2\}$" | xargs rm -rf") * emerge <your libs here> * re-start apache
Changing severity - I don't think our XSL design is flawed. It's spaghetti-code, but not flawed. A rewrite of the XSLs is something that is in the pipeline, but not for the upcoming weeks.
If a vulnerability is discovered in any of: dev-libs/libxml2-2.5.8 dev-libs/libxslt-1.0.33 dev-perl/XML-LibXML-1.54-r1 dev-perl/AxKit-1.6.1 We may be unable to upgrade to fixed versions. At this point, we are forced to stick with an older set of libraries due to problems with our code. Respectfully suggest and request that this needs to get bumped up on the priority scale. Also, as I mentioned earlier, blackace might be able to assist you/the docs team with this effort as well.
Like this one: http://www.gentoo.org/security/en/glsa/glsa-200403-01.xml recategorizing as blocker.
k, I'll prioritize this as my first priority.
Apparently we have the same issue as mentioned on http://maclux-rz.uibk.ac.at/maillists/axkit-users/msg06758.shtml: """ Now AxKit doesn't reach that '/foo' should be found in server's root - it did not catch libxml functions and libxml tries to open /foo directory from filesystem... """ Creating a "/xsl" in the root directory solves the "Unable to load /xsl/inserts.xsl" and other errors I received. It doesn't fix the "UNDEFINED STRING" stuff though, still need to check that out. BTW, I have XML::LibXML-1.58 on my system and the error still persists, the rt.cpan.org site is down so I cannot verify.
Okay, the "UNDEFINED STRING" stuff is also due to this. We run the document('/doc/..') function and for some stupid, unknown reason, AxKit (or LibXSLT or LibXML or whatever really performs this) searches for the document on the local filesystem "/doc/...". Symlinking /doc to [gentoo]/xml/htdocs/doc resolves the issue here.
Okay; got everything working by just having symlinks for "doc/", "news/", "dyn/", "xsl/". Ugly, but it seems to do the trick. Perhaps this can be tested on a test webnode if this is an acceptable solution (temporarily of course).
Okay, this is clearly AxKit related. The /dtd/guide.dtd is only "used" by AxKit, never by one of our stylesheets. Yet when the DTD is missing, AxKit gives the internal server error again. Symlinking "dtd/" from the root directory solves this.
The hack doesn't seem necessary anymore with: dev-libs/libxml2-2.6.11 dev-libs/libxslt-1.1.8 dev-perl/XML-LibXML-1.58 Marking as WORKSFORME.
