Date: Sun, 29 May 2005 22:04:51 +0200 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: bmah@FreeBSD.org, doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, PeterJeremy@optushome.com.au Subject: Re: cvs commit: www/en/releases/5.4R errata.html Message-ID: <20050529200450.GE784@zaphod.nitro.dk> In-Reply-To: <20050530.002750.74719916.hrs@allbsd.org> References: <1117258487.764.14.camel@localhost> <20050528082910.GH787@zaphod.nitro.dk> <1117298991.46625.33.camel@tomcat.kitchenlab.org> <20050530.002750.74719916.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Xm/fll+QQv+hsKip Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.05.30 00:27:50 +0900, Hiroki Sato wrote: > "Bruce A. Mah" <bmah@freebsd.org> wrote > in <1117298991.46625.33.camel@tomcat.kitchenlab.org>: >=20 > bm> A related point: The errata document for (for example) 5.3 was > bm> maintained on the RELENG_5 branch (and not RELENG_5_3). So right bef= ore > bm> we branched for 5.4, the 5.3 errata content was purged. Thus, users > bm> tracking the 5.3 security fix branch can't count on the errata docume= nt > bm> being current anymore; they have to go to RELENG_5_3 src/UPDATING to = get > bm> this information. (It's worked this way all the way back to > bm> 4.3-RELEASE. Curiously, nobody has complained to me about it in the > bm> past four years. I can't remember why I set it up this way.) >=20 > Hmm, for this problem I am thinking about using XML databases for > errata document. Probably we can agree that we should maintain > errata document for a release until its EoL, and duplicated > effort should be reduced. For security advisories, VuXML or > similar one can be used to put information into the errata page, and > by using XSLT, we can easily handle MD/MI separation and output > style change. With these databases the errata page can be generated > on-the-fly and trimming old items is not always needed. > The current structure limits reuse of information, so some sort of > improvements are needed. That's an interesting idea. I have been playing around with simply parsing the advisories which generated a XML file like: <advisory> <name>FreeBSD-SA-05:09.htt</name> <affects>All FreeBSD/i386 and FreeBSD/amd64 releases.</affects> <category>core</category> <cve>CAN-2005-0109</cve> <credits>Colin Percival</credits> <revised>2005-05-13</revised> <module>sys</module> <filename>FreeBSD-SA-05:09.htt</filename> <topic>information disclosure when using HTT</topic> <corrected_ext> <branch>RELENG_5</branch> <release>5.4-STABLE</release> <datetime>2005-05-13 00:13:00</datetime> </corrected_ext> <corrected_ext> <branch>RELENG_5_4</branch> <release>5.4-RELEASE-p1</release> <datetime>2005-05-13 00:13:00</datetime> </corrected_ext> [...] <announced>2005-05-13</announced> </advisory> That makes it very simple to generate a list of advisories per branch with XSLT, as I have done for my proof-of-concept page. > I made several specific implementations and am still wondering > where we should put such databases. Anyway, I am planning to change > these framework before 6.0R (I will submit the necessary changes > to the public mailing-lists for review, of course). Sounds very intesting, I'm looking forward to seeing it. --=20 Simon L. Nielsen --Xm/fll+QQv+hsKip Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCmiBih9pcDSc1mlERAt4iAJ9G6hQvw1Cu81zkqDASChy3gvQIDgCeMW5L 3Yx9A6AchKGSqpfGGnoXB1M= =xYIO -----END PGP SIGNATURE----- --Xm/fll+QQv+hsKip--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050529200450.GE784>