security/vuxml: Mark bro < 2.5.5 as vulnerable

[leres]

Summary

Proposed commit message:

Mark bro < 2.5.5 as vulnerable as per:

https://www.bro.org/download/NEWS.bro.html

Reviewed by: ? (mentor)
Approved by: ? (mentor)
Differential Revision: ?

[matthew]

security/vuxml/vuln.xml

71

Who is reporting here?

79

These paragraphs have rather excessively long line lengths -- doesn't make validate warn you about the formatting here? Also, you can use any HTML elements inside the <blockquote> area, not just <p></p> -- so <ul><li></li></ul> could be pasted in directly from the BRO news page, although you will have to trim the CSS class settings.

[leres]

Address mat@'s comments
Populate "reports" and reformat the description.

[leres]

Here's an update, please let me know if the <li> guys are formatted ok (I found examples that formatted the way I did but also some that indented multi line<li>'s).

security/vuxml/vuln.xml

71

Good point (but I'm disappointed validate didn't complain...)

79

make validate did not complain about the line length. Also I used really long lines the last time I added a entry for bro to security/vuxml and was trying to use it as a template. And I'm sure I used long lines because I found old entries that did it that way.

Using <ul> seems much better.

[matthew]

security/vuxml/vuln.xml

71

validate only checks for well-formed XML, not semantic correctness.

99

Hmmm.... AFAIR the indentation style preferred by the project looks like:

  <ul>
    <li>"Weird" events are now generally suppressed/sampled
      by default according to some tunable parameters.</li>
    <li>Improved handling of empty lines in several text
      protocol analyzers that can cause performance issues
      when seen in long sequences.</li>
    <li>Add `smtp_excessive_pending_cmds' weird which
      serves as a notification for when the "pending command"
      queue has reached an upper limit and been cleared to
      prevent one from attempting to slowly exhaust
      memory.</li>
</ul>

although I see this has not been rigorously observed. I guess if make validate doesn't complain then you're golden.

[leres]

No reason not to format the description using the preferred style.

I thought make validate did a bit more checking but I guess it
detects when you don't fill in a field (e.g. <name>) because the
optimized version of <name></name> is </name> which causes the
"tidy" version to be different.

[ler]

Ship it.

[matthew]

[leres]

This seems to always happens with MFH. My new theory is that I need to populate the "Differential Revision" for both the commit (which I did) and with MFH commit (which I did not).