CPE as a consistent element of pkg annotations

[Dewayne Geraghty]

I don't recall the argument for adding a CPE (Common Platform
Enumeration) into USES for port building, nor why its inserted into the
annotation section when using "pkg info". Though on a lightly
configured machine, only 107 of the 265 ports actually had a CPE entry
in annotations.

So I wondered, if its important then shouldn't it be mandatory? So I
added to /usr/ports/Mk/bsd.port.mk the following, so its applied to all
ports

.if empty(USES:Mcpe)
USES+=cpe
.endif

And access it via
"pkg-static query "%Av" $PKG

I use it when checking against CVE lists and when upgrading major
versions of the OS.

Is there a reason that inclusion of a cpe being available, is determined
by the port maintainer?

Interestingly, after reviewing
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
its noteworthy that the ports team uses the "Other" field (described in
section 5.3.3.11) within the CPE structure for the port revision, rather
than the "Update" (refer 5.3.3.5) field, as given as an example in the pdf.

So using tmux as an example, the CPE would be
cpe:2.3:a:tmux_project:tmux:3.3a:1::::freebsd13:x64:
enabling the other field to be used for something else.


I have reconfigured my Mk/cpe.mk so that Other is used for CPUTYPE. The
format becomes:
cpe:2.3:o:freebsd:freebsd:14.3:beta2:en_AU:::freebsd14:x64:x86-64-v3
which I think, utilises the available fields a little better. As we can
at a glance see if we've missed a port during upgrades or have an app
for a different cputype installed via a simple 'pkg query "%Av"|grep cpe'

The question of why the "language" field isn't populated, is for another
day...

For those with an interest to see how CPE's can be used, reference:
https://nvd.nist.gov/products/cpe
https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&orderBy=CPEURI&keyword=cpe%3A2.3%3Aa%3Afreebsd%3A&status=FINAL&startIndex=0

I've also created a PR to correct a minor CPE anomaly and a patch with
my suggestions:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286737

Regards, Dewayne
PS It would be nice to see something like:
cpe:2.3:o:nomadbsd:freebsd:14.3:Releng::en_US::freebsd14:x64:x86-64-v2
cpe:2.3:o:hardenedbsd:freebsd:14.3:Release::fr_FR::freebsd14:x64:x86-64-v4

[Dag-Erling Smørgrav]

Dewayne Geraghty <dew...@heuristicsystems.com.au> writes:
> I don't recall the argument for adding a CPE (Common Platform
> Enumeration) into USES for port building, nor why its inserted into
> the annotation section when using "pkg info". Though on a lightly
> configured machine, only 107 of the 265 ports actually had a CPE entry
> in annotations.

It gets added when a CVE has actually been issued.

> So I wondered, if its important then shouldn't it be mandatory?

No, because we can't just make up CPEs.

> Is there a reason that inclusion of a cpe being available, is
> determined by the port maintainer?

Because the port maintainer needs to make sure it is correct.

> Interestingly, after reviewing
> https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
> its noteworthy that the ports team uses the "Other" field (described
> in section 5.3.3.11) within the CPE structure for the port revision,
> rather than the "Update" (refer 5.3.3.5) field, as given as an example
> in the pdf.

The port revision and epoch are specific to the FreeBSD ports system.
The update field is intended for a patch level or such chosen by the
original author of the software.

> So using tmux as an example, the CPE would be
> cpe:2.3:a:tmux_project:tmux:3.3a:1::::freebsd13:x64:
> enabling the other field to be used for something else.

That would be incorrect.

> The question of why the "language" field isn't populated, is for
> another day...

You understand that we don't get to just make shit up, right?

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

[Dewayne Geraghty]

On 12/05/2025 3:30 pm, Dag-Erling Smørgrav wrote:
> Dewayne Geraghty <dew...@heuristicsystems.com.au> writes:
>> I don't recall the argument for adding a CPE (Common Platform
>> Enumeration) into USES for port building, nor why its inserted into
>> the annotation section when using "pkg info". Though on a lightly
>> configured machine, only 107 of the 265 ports actually had a CPE entry
>> in annotations.
>
> It gets added when a CVE has actually been issued.
>
>> So I wondered, if its important then shouldn't it be mandatory?
>
> No, because we can't just make up CPEs.
>

I suspect you're conflating CPE with a CVE. The CPE is a construct
defined in the /usr/ports/Mk/Uses/cpe.mk file. It takes as input
standard fields from the port's Makefile, such as PORTNAME, PORTVERSION,
PORTREVISION etc.

>> Is there a reason that inclusion of a cpe being available, is
>> determined by the port maintainer?
>
> Because the port maintainer needs to make sure it is correct.
>

The contribution by the port maintainer is to ensure that the elements
required for the CPE record are current, like PORTVERSION PORTREVISION
etc. Where the details are not included in the Makefile they have defaults.

>> Interestingly, after reviewing
>> https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
>> its noteworthy that the ports team uses the "Other" field (described
>> in section 5.3.3.11) within the CPE structure for the port revision,
>> rather than the "Update" (refer 5.3.3.5) field, as given as an example
>> in the pdf.
>
> The port revision and epoch are specific to the FreeBSD ports system.
> The update field is intended for a patch level or such chosen by the
> original author of the software.

Yes - the update field should be a patch level. Is it really by the
original author or the maintainer? I suspect your familiarity with the
standard is as current as needed.

>
>> So using tmux as an example, the CPE would be
>> cpe:2.3:a:tmux_project:tmux:3.3a:1::::freebsd13:x64:
>> enabling the other field to be used for something else.
>
> That would be incorrect.
>
>> The question of why the "language" field isn't populated, is for
>> another day...
>
> You understand that we don't get to just make shit up, right?
>
> DES

Yes, thank-you DES, I did read the standard before writing the email.
You're involved in a great many areas of FreeBSD and I appreciate the
work that you do. Perhaps the PR that I've referenced will help refresh
familiarity with the matter.

For your convenience
The CPE v2.3 standard is available at
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf

The "language" field references
https://www.rfc-editor.org/rfc/rfc5646.txt

Kind regards, Dewayne

[Dag-Erling Smørgrav]

Dewayne Geraghty <dew...@heuristicsystems.com.au> writes:

> Dag-Erling Smørgrav <d...@FreeBSD.org> writes:
> > No, because we can't just make up CPEs.
> I suspect you're conflating CPE with a CVE. The CPE is a construct
> defined in the /usr/ports/Mk/Uses/cpe.mk file.

Do me a favor and run `git log` on that file. And then maybe check who
was Security Officer at the time it was added to the ports tree.

[Dewayne Geraghty]

Subsequent to an offline discussion with DES, I'm sharing the conclusion:

NIST 7695 provides the necessary guidance for CPE content. The
structure of the CPE is defined in section 6.2. The inclusion of a CPE
can't be automated because the port maintainer must review the National
Vulnerability Database per instructions in the Porters Handbook section
17.19 to maintain alignment in the event of a vulnerability.

References:
1. https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
2. https://docs.freebsd.org/en/books/porters-handbook/book/#uses-cpe

[Dag-Erling Smørgrav]

Dewayne Geraghty <dew...@heuristicsystems.com.au> writes:
> Subsequent to an offline discussion with DES, I'm sharing the conclusion:

> [...]

That's cute, but a more accurate summary would be that I wasted literal
hours yesterday going over the spec and the code line by line and word
by word in case you had seen something I'd missed and rebutting your
email point by point, whereupon you glossed over nearly everything I'd
written, continued to insist that the spec says something else than what
it actually does, and told me your life story in an effort to convince
me that you're a Special Boy and that I should be grateful for having my
time wasted by you.

I'm not opposed to “positive contributions”, as you put it, but they
have to be anchored in reality.