security/vuxml: refuse non CVE vuln IDs in validate target

[smyru]

Summary

PR: 295994
Approved by: 0mp

[smyru]

For testing purposes use as follows:

cd $PORTSDIR && git show 27367635aaadde7d102c188e32f3867b6e7cd6ef:security/vuxml/vuln/2026.xml > security/vuxml/vuln/2026.xml

[philip]

This looks good. Many thanks!

[0mp]

Thank you for working on that!

[0mp]

It would be good to confirm that the ports secteam is alright with this change.

[smyru]

security/vuxml/Makefile

90–91

Should this rather grep through year XML files instead of the flattened output?

[philip]

In D57539#1318631, @0mp wrote:

It would be good to confirm that the ports secteam is alright with this change.

I wouldn't block on them. Give them a couple of days to comment/object.

security/vuxml/Makefile

90–91

Doesn't make a difference. The contents are the same.

[smyru]

security/vuxml/Makefile

90–91

It may be useful for change redactors, since it points them into the actual place in file(s) that shall be modified, since the flattened output is machine generated. Current state assumes the redactor has an intimate knowledge of the mechanics how the database is generated, which may not be true.

[fernape]

security/vuxml/Makefile

91

Thank you for working on this.

Instead of fgrepping twice, would it be possible to do it once and store the result in a variable? Then we can test for empty strings and if not, show the relevant lines without traversing the file again.

[smyru]

security/vuxml/Makefile

91

I could compact this to '<cvename>[^C]' pattern but this may pose a risk of slipping through IDs that actually start with C but aren't allowed, ie. CWE or CAPEC. I sort of liked the fact that '(CVE|CAN)' is self documenting. Alternatively I can rewrite this to a sed expression.

[smyru]

security/vuxml/Makefile

91

Choose your fighter:

NON_CANONICAL_CVE="`${SED} -E -e '/<cvename>/! d; /(CVE|CAN)-/ d' ${VUXML_FLAT_FILE}`";
NON_CANONICAL_CVE="`grep '<cvename>[^C]' ${VUXML_FLAT_FILE}`";

[fernape]

security/vuxml/Makefile

91

I don't see anything wrong with the regexp of grep. My issue is with the fact that the part before xargs in the first grep is *exactly the same* as the line we execute if we want to print the error-patch message.

Can we do something like this? (pseudo code)

v=fgrep '<cvename>' ${VUXML_FLAT_FILE} | egrep -v '(CAN|CVE)-')
if test -z $v...

ok

else
print "these lines are not ok: $v"
fi.

[smyru]

security/vuxml/Makefile

91

If we store the grep output into a shell variable, and choose to echo it in the else block, and multiple lines were matched – as in the repro example from my very own breakage – the multiple lines will get merged together by echo. Somewhat ugly and unhelpful to the change operator.

My reasoning is as follows, since this is not a high availability use case (correct me if I am wrong or unaware of something), the other grep shall be fine, since it outputs helpful content in a controlled format legible to a human eye, while preserving DWIM and POLA.

[smyru]

security/vuxml/Makefile

91

To illustrate, please compare:

Only CVE IDs are allowed within cvename tags. These lines are wrong:
vuln/2026.xml:33:      <cvename>RUSTSEC-2026-0089</cvename>
vuln/2026.xml:37:      <cvename>GHSA-q49f-xg75-m9xw</cvename>

to…

Only CVE IDs are allowed within cvename tags. These lines are wrong:
vuln/2026.xml:33: <cvename>RUSTSEC-2026-0089</cvename> vuln/2026.xml:37: <cvename>GHSA-q49f-xg75-m9xw</cvename>

[fernape]

security/vuxml/Makefile

91

Use

printf '%s\n' "$v"

for printing the debugging message and lines will be preserved.

Also please use ${EGREP} as defined in bsd.commands.mk. We should be able to use ${EGREP} -f to simulate fgrep:

$ diff /usr/bin/fgrep /usr/bin/grep
$

[smyru]

Address review issues

[philip]

Looks good to me. Many thanks for working on this!

[fernape]

Terriffic. Thanks! (with ports-secteam@ hat) that for some reason doesn't show in Phab.