http://invisible-island.net/ansification
Copyright © 2012-2013,2014 by Thomas E. Dickey
I overlooked this on the Xorg mailing list, but noticed it in a web search shortly after:
X.Org security advisory: DoS/info leak in xfs prior to X11R6.7/XFree86 3.3.3 — Alan Coopersmith (24 Jul 17:31 2012).
It quotes my changelog comment:
Prototype/ansification cleanup for Xserver/XIE, xfs, fontlib, mkfontdir, and fix some bugs found along the way (#2103, Thomas Dickey).
but does not give a date. Some discussion is in order, to put this in its proper context.
I started working with XFree86 in January 1996, on xterm. While my main interest was xterm, I felt inclined to help on the larger project scope.
I started by getting a copy of the source, and learning how to build it. That took about 6 hours on a 56Kb modem. This was a given in the 1990s, for anyone who was not using resources owned by a university or company.
I sent patch files to the mailing list. These were integrated by the XFree86 core developers. This was the basis for the versioning which I use for xterm, referring to "patch #".
Periodically the XFree86 developers provided patches to the next incremental version. I applied those, and thereby kept in sync with their versions for a few years, until early 2001 when high-speed Internet connections to the home became a reality. Around that point, I (and several other proficient developers) were given CVS commit privileges in XFree86.
The change cited for the CVE is noted in the XFree86 changelog in this section:
XFree86 3.9Nk (25 October 1998)
and my corresponding patch was dated 23 October 1998.
It is nice to get credit, but it is nicer to credit people correctly.
Reviewing my patches (outside xterm), I see that I changed about 15,000 lines of code between 1996-2000 (15491 inserts, 14417 deletes). My changes to xterm were more extensive over the same period (66710 inserts, 29132 deletes).
My intent was to reduce compiler warnings, to make it possible to see real problems. Initially I made a few fixes in Xlib.h, and later in the Xserver tree. More than half the roughly 600 files which I touched are under Xserver. However, I also modified libraries (X11, Xau, Xaw, Xdmcp, Xi, Xmu, dps, dpstk, font, xkbfile) and programs (mkfontdir, patch, pswrap, setxkbmap, xclipboard, xconsole, xdm, xfs, xkbcomp, xmag, xman, xvidtune).
The reduction was real. When I started, there were 60-70 thousand warning messages from my build logs (which were stricter than the default). After the initial changes (chiefly the changes to Xlib.h), I got it down to about half that amount. With more work, it came down to a little over 20 thousand warning messages. (There are 3.3 million lines of code in my last CVS pull from XFree86 in 2006).
By "more work", I mean that I worked on all files in a library or program, converting them to ANSI C and checking the compiler warnings.
Referring to email for relevant dates:
I read through the portions I'm familiar with; they're a regurgitation of the X11R6.4 public patches from last year (and most of the bulk of the patch seems to be under the XFree86/XFree98 trees).
With that background in mind, consider this posting in 2004 by Daniel Barkalow (iabervon) on Linux Weekly News:
Posted Apr 8, 2004 0:42 UTC (Thu) by subscriber iabervon
X.org has been releasing X versions all along, which XFree86 has been taking and incorporating into their distributions. If you look at an XFree86 distribution, it will have a set of release notes for the X.org portion as well as the main release notes. It has been X.org's versions of things like xrdb, xterm, xfontsel, etc. which you get if you get XFree86. With this release, X.org has started releasing complete distributions, including the stuff that XFree86 would formerly have added. The last like this was done, the organization doing it was still the X Consortium, so this is the first complete X distribution by X.org, despite the fact that they've made a number of previous incomplete distributions. The odd part is mainly that they've kept the same version numbering when going from the incomplete distribution intended for repackaging to the complete one intended for end users.
There are several parts to the posting. The principal one is the assertion that "It has been X.org's versions of things", etc., stating in so many words that XFree86's contribution to the whole was a minor, subservient role. The remainder of the paragraph builds up to that point, reiterates it and ends with a quibble about version numbering.
At that point, I had been developing xterm for 8 years, and knew well that it was not "X.org's versions of things like xrdb, xterm, xfontsel, etc."
Besides xterm, my changes touched the other programs. The resulting changes were used in released versions of XFree86. Barkalow's posting misattributed the work done. In the case of my work which he pointedly mentioned, this is more than three-quarters of the work which I did.
The point of the CVE description is that X.org began at this point to distribute the XFree86 code, which included my fixes. So the problem "went away". Until that point, X.org had not incorporated any of my work.
It was not "odd" that they kept the same version numbering, because after all it was X.org plus a few new people such as Daniel Stone (daniels) commenting in the LWN thread.
At this writing (late July 2012), X.org's webpage is available via the Internet archive:
At no point in X.Org's webpages is found a discontinuity: it was the essentially same people throughout.
Reviewing my patches, I do not see the cited change.
There is another source of information. Looking at the XFree86 CVS for events.c, My changes are revision 3.3. I see that the CVE fix was introduced in the next revision (3.4). The changelog comment by David Dawes says only
initial 3.9Nr patches
The XFree86 changelog is not much help. However, the same commit as above touches on compiler warning fixes. Looking at revision 3.653 offers this possibility:
2086. LP64 compiler warning fixes from the NetBSD xsrc tree (#2019, Ross Harvey).
But that is only an educated guess (unless Ross Harvey happens to have his original patches, etc).
On the other hand, my changes helped find the bug.
They added function prototypes for SendErrToClient
in client.h, and in a new header file dispatch.h. Compiling on my
32-bit machine did not yield a warning message, but it was not
unusual for someone to report warnings in "quiet" code when
building on a 64-bit machine.
Email: dickey@invisible-island.net