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

[Simon L. Nielsen]

On 2005.05.28 09:49:51 -0700, Bruce A. Mah wrote:
> If memory serves me right, Simon L. Nielsen wrote:
> > 2. Just link to the advisory and have no description, or a very brief
> > one of where there problem lies, so it can be written in a very short
> > time and is therefor more likely to be written by a security-team@
> > memeber during the advisory release cycle.
> 
> I think someone suggested a simple link before...I objected to this on
> the grounds that the link gives almost no information as to whether
> someone should bother looking up the advisory.

In general I would say people should read all advisories, but I'm
biased... :-).

> However, I just reread the past few advisories issued by security-team@
> and the "Topic" of each advisory is actually a pretty good "brief
> description", which we could probably use.

Hopefully the topic should be rather descriptive, and of cause if we
decide to use it for the errata and release notes, I will at least
keep that in mind when reviewing/writing new advisories.

> > 3. Simply copy/paste the relevant part of the security advisory
> > (probably the "Problem Description" and "Impact" sections) and use
> > that.
> 
> This has the writing style mismatch problem that we discussed earlier.

Exactly.

> > I would probably prefer 2, with an appropriate header in the section
> > basically telling people to read the advisories.
> 
> OK.  How about something like the following paragraph and table (pretend
> there is some real DocBook markup in here and don't worry too much about
> the wording):
> 
> -----8<-----
> 
> The following security advisories pertain to FreeBSD 5.4-RELEASE.  For
> more information, consult the individual advisories.
> 
> Advisory		Date		Topic
> --------		----		-----
> FreeBSD-SA-05:09.htt	13 May 2005	information disclosure when using HTT
> FreeBSD-SA-05:08.kmem	6 May 2005	Local kernel memory disclosure
> FreeBSD-SA-05.07.ldt	6 May 2005	Local kernel memory disclosure in i386_get_ldt
> ...
> 
> -----8<-----
> 
> The nice thing about this table is that security-team@ doesn't need to
> worry about writing a single grammatically correct sentence (or two) to
> describe each issue,

Yes, that would probably mean that somebody from the security team
could update the errata right after the advisory has been released.
Possibly even in some automated fasion.

In short, I like it :-).

> other than making sure that the initial word of
> each topic is capitalized consistently (hint hint).  :-)

He, yes that one slipped by :-).

> > The same issue goes for the Release Notes btw.
> 
> Right...I think we both understood this but didn't state it explicitly.
> 
> One problem with the table approach above is the case of MD advisories
> (such as SA-05:09.htt).  Because we (currently) generate a different
> release notes document for each architecture.  The method I devised for
> doing conditional text inclusion might not work inside a table.  That's
> OK...I'm starting to think that having separate MD release notes wasn't
> such a great idea to begin with; a single MI document with annotations
> for the few items that are MD might be better.  But that's a different
> issue.

Yes, most release documents are very similar.

> I suggest that if we adopt the above approach we just pretend
> every advisory is MI and just include it regardless of architecture.

For most advisories that is also the case.  From a quick check it
seems that in 2004 and 2005 we had two MD advisories, the rest was MI.

> A related point:  The errata document for (for example) 5.3 was
> maintained on the RELENG_5 branch (and not RELENG_5_3).  So right before
> we branched for 5.4, the 5.3 errata content was purged.  Thus, users
> tracking the 5.3 security fix branch can't count on the errata document
> being current anymore; they have to go to RELENG_5_3 src/UPDATING to get
> this information.  (It's worked this way all the way back to
> 4.3-RELEASE.  Curiously, nobody has complained to me about it in the
> past four years.  I can't remember why I set it up this way.)

Possibly (guess) becase it's a bad idea to commit to the release notes
on the security branches.

-- 
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/d8a6dc18/attachment.bin