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>