From Newsgroup: muc.lists.freebsd.ports

Instead of the usual CPE_VENDOR?=${CPE_PRODUCT} would there be any value
in a CPE_VENDOR?=${GH_ACCOUNT} for ports with USE_GITHUB=yes ? It seems
like that would save some of the edits necessary to bring in CPE
information and could still be overridden by ports that need to do so.
Maybe the idea would be more trouble than its worth and vendor=product
would be correct more of the time. Anyone know of a good way to test
such a thing other than by manually reviewing all relevant ports one by one?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

From: Edward Sanford Sutton, III <mirror176@hotmail.com>
To: <ports@freebsd.org>
Date: Sun, 13 Sep 2026 08:54:12 +0200
Subject: should USE_GITHUB=yes ports set CPE_VENDOR?=${GH_ACCOUNT}

Instead of the usual CPE_VENDOR?=${CPE_PRODUCT} would there be any value
in a CPE_VENDOR?=${GH_ACCOUNT} for ports with USE_GITHUB=yes ? It seems like that would save some of the edits necessary to bring in CPE information and could still be overridden by ports that need to do so. Maybe the idea would be more trouble than its worth and vendor=product would be correct more of the time. Anyone know of a good way to test
such a thing other than by manually reviewing all relevant ports one by one?

I guess you checked my last commits and that's why the question came up.

Your observation is very much correct, there is quite a number of projects where GH_ACCOUNT matches CPE_VENDOR. I have no practical numbers but I'd say it's probably the majority. The other big contender is "${PORTNAME}_project" and it seems very much random why one or the other is used.

But in fact I would very much like to avoid adding more magic to this CPE variables because it breaks easily when ports are copied/renamed/split/ flavorized/slaved or upstream changes the CPE info and that makes it very
hard to notice the issue. That is also why I try to avoid using variables
in CPE_VENDOR/CPE_PRODUCT even though "${PORTNAME}_project" is technically correct.

Right now we have around 350 ports with questionable CPE information and
around 250 candidates which all need to be checked manually so you will
see me doing that kind of commits for a little longer. I try to be as
compact as possible and add CPE_VENDOR/CPE_PRODUCT only when strictly
needed.




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 9/13/26 00:25, Bernhard Froehlich wrote:

From: Edward Sanford Sutton, III <mirror176@hotmail.com>
To: <ports@freebsd.org>
Date: Sun, 13 Sep 2026 08:54:12 +0200
Subject: should USE_GITHUB=yes ports set CPE_VENDOR?=${GH_ACCOUNT}

> Instead of the usual CPE_VENDOR?=${CPE_PRODUCT} would there be any value
> in a CPE_VENDOR?=${GH_ACCOUNT} for ports with USE_GITHUB=yes ? It seems
> like that would save some of the edits necessary to bring in CPE
> information and could still be overridden by ports that need to do so.
> Maybe the idea would be more trouble than its worth and vendor=product
> would be correct more of the time. Anyone know of a good way to test
> such a thing other than by manually reviewing all relevant ports one by one?

I guess you checked my last commits and that's why the question came up.

I watch over commits off and on and have seen your work more than
once. The recent commits brought it to mind again but I wondered before
and didn't bring it up. Thank you for your work on the ports tree.

Your observation is very much correct, there is quite a number of projects where GH_ACCOUNT matches CPE_VENDOR. I have no practical numbers but I'd say it's probably the majority. The other big contender is "${PORTNAME}_project" and it seems very much random why one or the other is used.

But in fact I would very much like to avoid adding more magic to this CPE variables because it breaks easily when ports are copied/renamed/split/ flavorized/slaved or upstream changes the CPE info and that makes it very hard to notice the issue. That is also why I try to avoid using variables
in CPE_VENDOR/CPE_PRODUCT even though "${PORTNAME}_project" is technically correct.

I wondered if setting such would not only simplify a few ports but
cause things to be automatically+properly set for the maintainers more
than it would cause a mistake. I'm still not clear when a fork or new
home follows the same value vs when it should end up changed.
I admit that the more the Mk framework takes over doing things the
easier it is to get lost in what is really happening at times. I've
learned simple tricks and forgotten some other tricks to keep track of
what is going on without manually always reading the code.
If you think the extra work outweighs the work of finding+correcting mistakes then I can see value there too.
Is there already any mechanism that uses this information or is all
of the work preparation for such a change?

Right now we have around 350 ports with questionable CPE information and around 250 candidates which all need to be checked manually so you will
see me doing that kind of commits for a little longer. I try to be as
compact as possible and add CPE_VENDOR/CPE_PRODUCT only when strictly
needed.

My thinking was to minimize the "when needed" cases as I thought it
likely applied a majority of the time too. Thought it may minimize
workloads such as yours while making more ports correct by default
leaving only a few of the related cases needing such adjustment.
Something is still needed since its not enabled until USES+=cpe comes
into play.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

---- Am Sun, 13 Sep 2026 23:07:54 +0200 mirror176@hotmail.com schrieb ----

On 9/13/26 00:25, Bernhard Froehlich wrote:

From: Edward Sanford Sutton, III

To:
Date: Sun, 13 Sep 2026 08:54:12 +0200
Subject: should USE_GITHUB=yes ports set CPE_VENDOR?=${GH_ACCOUNT}

Instead of the usual CPE_VENDOR?=${CPE_PRODUCT} would there be any value in a CPE_VENDOR?=${GH_ACCOUNT} for ports with USE_GITHUB=yes ? It seems like that would save some of the edits necessary to bring in CPE information and could still be overridden by ports that need to do so. Maybe the idea would be more trouble than its worth and vendor=product would be correct more of the time. Anyone know of a good way to test
such a thing other than by manually reviewing all relevant ports one by

one?

I guess you checked my last commits and that's why the question came up.

I watch over commits off and on and have seen your work more than
once. The recent commits brought it to mind again but I wondered before
and didn't bring it up. Thank you for your work on the ports tree.

Your observation is very much correct, there is quite a number of projects where GH_ACCOUNT matches CPE_VENDOR. I have no practical numbers but I'd say
it's probably the majority. The other big contender is "${PORTNAME}_project"
and it seems very much random why one or the other is used.

But in fact I would very much like to avoid adding more magic to this CPE variables because it breaks easily when ports are copied/renamed/split/ flavorized/slaved or upstream changes the CPE info and that makes it very hard to notice the issue. That is also why I try to avoid using variables in CPE_VENDOR/CPE_PRODUCT even though "${PORTNAME}_project" is technically correct.

I wondered if setting such would not only simplify a few ports but
cause things to be automatically+properly set for the maintainers more
than it would cause a mistake. I'm still not clear when a fork or new
home follows the same value vs when it should end up changed.
I admit that the more the Mk framework takes over doing things the
easier it is to get lost in what is really happening at times. I've
learned simple tricks and forgotten some other tricks to keep track of
what is going on without manually always reading the code.
If you think the extra work outweighs the work of finding+correcting
mistakes then I can see value there too.
Is there already any mechanism that uses this information or is all
of the work preparation for such a change?

The CPE data will allow us to match vulnerabilities to actual ports. So pkg audit will be able to match all CVEs out there to installed ports and not just those in our vuxml database.

It is also a prerequisite for SBOM.

Right now we have around 350 ports with questionable CPE information and around 250 candidates which all need to be checked manually so you will
see me doing that kind of commits for a little longer. I try to be as compact as possible and add CPE_VENDOR/CPE_PRODUCT only when strictly needed.

My thinking was to minimize the "when needed" cases as I thought it
likely applied a majority of the time too. Thought it may minimize
workloads such as yours while making more ports correct by default
leaving only a few of the related cases needing such adjustment.
Something is still needed since its not enabled until USES+=cpe comes
into play.

To bring some numbers to the table we currently have around 3200 ports with USES=cpe and round 550 ports with USES=cpe + USE_GITHUB=yes. So this change
can only affects less than 20% of ports with CPE data.

From those 550 we currently have around 140 where we don't need to set any CPE_* variables so the defaults are matching (basically PORTNAME == CPE_*).

Changing CPE_VENDOR=GH_ACCOUNT and CPE_PRODUCT=GH_PROJECT would bring us
to around 190 ports where we wouldn't need to set any explicit CPE_* variables.

Actually only setting CPE_VENDOR=GH_ACCOUNT but leaving CPE_PRODUCT=PORTNAME
as default is even slightly better at around 195 ports.

So the positive effect would be around 50 ports with one or two lines less.
It really does not seem to be a big win but yes, technically it would be a better default.

Beware some of those numbers were generated by a script which was generated
by an LLM but you shouldn't trust anyone's statistics anyway.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2