cvs commit: www/en/releases/5.4R errata.html

[Simon L. Nielsen]

On 2005.05.30 00:27:50 +0900, Hiroki Sato wrote:

> "Bruce A. Mah" <bmah at freebsd.org> wrote
>   in <1117298991.46625.33.camel at tomcat.kitchenlab.org>:
> 
> 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 before
> 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 document
> 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.)
> 
>  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.

-- 
Simon L. Nielsen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-doc/attachments/20050529/fe4c9bf4/attachment.bin