* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique:

# Alternative solutions:
If we really want to distinguish the case when we don't produce any affected >packages but the source contains the vulnerability (a build with different >flags might result in an affected package), we can create a new tag to show >this: not-affected-build-artifacts.

This. Just marking the CVE as not-affected does not distinguish between
deb and deb-src, that are still part of (and shipped by) Debian.

Cheers,
Gian Piero.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 3 Apr 2024 at 17:04, Gian Piero Carrubba <[email protected]> wrote:

* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique:

# Alternative solutions:
If we really want to distinguish the case when we don't produce any affected >packages but the source contains the vulnerability (a build with different >flags might result in an affected package), we can create a new tag to show >this: not-affected-build-artifacts.

This. Just marking the CVE as not-affected does not distinguish between
deb and deb-src, that are still part of (and shipped by) Debian.

On the proposed solution I also mention that we can use the "(free text comment)" section to indicate that, while sticking to "not-affected", this would simplify things as no new value is needed. But parsing the cases where only the sources contain the vulnerable code might be a bit harder.

I'm curious though as to what is the usecase of that, no other Linux distribution specifies the case where only the source carries the vulnerability.

What would be the need for this as a user? If this is a need you have, could you clarify it, please?

Regards,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

I've done some small updates to the proposal, mostly improving readability and making my suggestion more clear.

v2 below:

I would like to propose something which will lower the amount
of reported false-positive CVEs to our users by about 20%.

# tl;dr
We don't have a unique way of stating that a CVE does not affect us when we don't build the affected package's feature or hardening blocks exploits.
This leads to our users being required to manually distinguish which CVEs affect them and which don't.

I propose we mark those cases as not-affected.

Alternatively, I mention an option to create a new state to indicate that the resulting package is not affected due to the build options. I also explain why that's not my prefered approach.

# Problem statement
The possible outcomes of a CVE assessment in our security-tracker are[0]:

<no-dsa> | <unfixed> | <undetermined> | <not-affected> | <itp> | <ignored> | <postponed>

We also have the following severity levels [0]:

SEVERITY_LEVEL : (unimportant) | (low) | (medium) | (high)

"unimportant" being defined as:

unimportant: This problem does not affect the Debian binary package, e.g., a vulnerable source file, which is not built, a vulnerable file in doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't matter on Debian). All "non-issues in practice" fall also into this category, like issues only "exploitable" if the code in question is setuid root, exploits which only work if someone already has administrative privileges or similar. This severity is also used for vulnerabilities in packages which are not covered by security support.

We have a problem in the way we assess CVEs when the generated package is not affected (but the source code contains the vulnerability). Our current process is to set "no-dsa" and lower the severity to "unimportant", although it's also possible that in some cases people are making use of "ignored", which represents "won't fix".

The result is that "unimportant/no-dsa" CVEs can mean two things:
1) We are affected but we the severity is too low, eg.: packages not covered by security support, the CVE is considered a non-issue by our security-team but we are still affected...

2) We are definitely not affected since we don't build that feature of the software or we have hardening in place which prevents this from being exploited.

This leads to our users, who are interested in knowing which CVEs affect their systems, having to check the notes of every CVE on security-tracker to filter-out the false-positives.

# Proposed solution
I propose that we start setting CVEs to not-affected also when the following is true for all officially supported architectures:
* We don't ship the affected source package.
* We don't build the affected feature.
* We have hardening which makes the exploit impossible (only in the cases when � there's no doubt about it).

If we still want to flag the cases where a build with different flags might change that assertion, we can use the "(free text comment)" section of the NOTES[0] to
mention it.

Effectively this proposal means I would push an MR updating the documentation at [0] and start changing those CVEs to not-affected. I'm not asking for anyone to do the work.

# Stats
As a way of sampling the impact of this issue, I've done a high-level check on how many sets of affected package-CVE we have in our debian:stable docker image[1].

Out of the 82 affected package/CVE pairs, 15 were clear cases of our packages not being affected.

Out of the rest of those, the majority are other cases where we are reporting non-issues, but those require a deeper investigation so I don't want to assume they also fall under this case.

So 18% of the reported affected packages are false-positives. Based on what I've seen, I believe this is a fair estimate to extrapolate.

I've listed some examples to this issue at [2].

# Alternative solution
If using the "free text comment"[0] is not a good enough way of stating that only the source contains the vulnerable code:

## A1) Add a new sub-state "only-source-vulnerable", to be used in addition to "not-affected"

## A2) Add a new mutually exclusive state to the set: "not-affected-build-artifacts"

I don't like these approaches because they increase the complexity of our process
(a new state is more costly than a free text mention) where there's not a clear benefit/motivation. What's the value in saying the sources carry the vulnerable code? If someone does their own modified build of a package, all bets are off and that's not an official package.

It should also be mentioned that identifying cases where only the source-code is vulnerable will never be done perfectly due to how easy it is to miss a bundled library which is not used. For example, rsync bundles zlib and we do not set rsync as affected for all zlib CVEs (rsync does not use the bundled lib), would we like otherwise to be the case?

Coming up with a new state is confusing as systems/people reading that might end up parsing it as "affected". So I prefer A1 over A2.

This being said, the non-preferred alternatives are still better than the current situation IMHO.

[0] https://security-team.debian.org/security_tracker.html#summary-of-tracker-syntax
�"ignored" and "postponed" are sub-states, supposed to be used together with "no-dsa".
[1] $ grype debian:stable
[2] https://security-tracker.debian.org/tracker/CVE-2011-3374
[2] https://security-tracker.debian.org/tracker/CVE-2022-0563
[2] https://security-tracker.debian.org/tracker/CVE-2017-18018
[2] https://security-tracker.debian.org/tracker/CVE-2019-19882
[2] https://security-tracker.debian.org/tracker/CVE-2023-28320


Cheers,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

Just wondering if the Security team could spend some time availiating my proposal.

Feedback from others is always welcomed too, but in order to go ahead I would like to understand where the team stands.

Cheers,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

I've written another revision of my proposal, this is version 3 of it, the previous ones are on this email thread on [email protected].

I did get some feedback from the Security Team privately, it wasn't
anything confidential, it's just that some members of the team only
noticed my proposal after I sent it to the private mailing list, and the biggest part of the feedback was that they wanted some time to think about it.

This time I'm cc'ing the team's mailing list as well, so replies will show up here.

Not much has changed in this version, but it should be better than the
previous one, this is more of a chance to get feedback from the team
again.

********************************************************************************

## A proposal to significantly reduce reported false-positives (no affected-code shipped) - version 3

I would like to propose something which will lower the amount of reported false-positive CVEs to our users by about 20%.

********************************************************************************

## tl;dr
Debian over-reports on numbers of affected CVEs, the main reason is that we don't have a unique way of stating that a CVE does not affect Debian when we don't build the affected package's feature (or hardening blocks
exploits). In these cases, we mark the CVEs as affecting our packages because the source-code contains the vulnerable code (the binary package doesn't).

This leads to ourselves and our users being required to manually distinguish which CVEs affect them and which don't anytime there's a need to look at the data. It's effectively noise and we end up reporting the binary packages as affected when that's not true (both on the OVAL files and on the security-tracker json file we generate).

I propose we mark those cases as not-affected.

Alternatively, I mention an option to create a new state to indicate that the resulting package is not affected due to the build options, but that the source-code contains the vulnerability. I also explain why that's not my prefered approach.

********************************************************************************

## Problem statement
The possible outcomes of a CVE assessment in our security-tracker are[0]:

<no-dsa> | <unfixed> | <undetermined> | <not-affected> | <itp> | <ignored> | <postponed>

We also have the following severity levels [0]:

SEVERITY_LEVEL : (unimportant) | (low) | (medium) | (high)

"unimportant" being defined as:

unimportant: This problem does not affect the Debian binary package, e.g., a vulnerable source file, which is not built, a vulnerable file in doc/foo/examples/, PHP Safe mode bugs, path disclosure (doesn't matter on Debian). All "non-issues in practice" fall also into this category, like issues only "exploitable" if the code in question is setuid root, exploits which only work if someone already has administrative privileges or similar. This severity is also used for vulnerabilities in packages which are not covered by security support.

We have a problem in the way we assess CVEs when the generated package is not affected but the source code contains the vulnerability. Our current process
is to set "no-dsa" and lower the severity to "unimportant", although it's also possible that in some cases people are making use of "ignored", which represents "won't fix".

The result is that "unimportant/no-dsa" CVEs can mean two things:
1) We are affected but we the severity is too low, eg.: packages not covered by security support, the CVE is considered a non-issue by our security-team but we are still affected...

2) We are definitely not affected since we don't build that feature of the software or we have hardening in place which prevents this from being exploited.

This leads to our users, who are interested in knowing which CVEs affect their systems, having to check the notes of every CVE on security-tracker to filter-out the false-positives.

Besides that, we also struggle with this ourselves, as someone who
would like to fix CVEs will have to filter-out these false-positives themselves.

Considering the broad usage of Debian (especially on containers), being able to correctly mark these cases as not affecting the binary packages will have a huge impact on all of the industry.

I'm not being over-optimistic here, a lot of effort ends up being spent on generating CVE reports and then having to justify why each one is not fixed.

Whether the requirements around CVE fixing are right or wrong is a story of its own, but we have the potential to make ourselves and our users' lives easier with this.

********************************************************************************

## Proposed solution
I propose that we start setting CVEs to "not-affected" when the following is true for all officially supported architectures:
* We don't ship the affected source package.
* We don't build the affected feature.
* We have hardening which makes the exploit impossible (only in the cases when
there's no doubt about it).

If we still want to flag the cases where a build with different flags might change that assertion, we can use the "(free text comment)" section of
the NOTES[0] to
mention it.

In other words, we keep tracking source packages for our assessments,
the difference is that when the built package is not-affected, our
assessment will be "not-affected" for that release.


Effectively this proposal means I would push an MR updating the
documentation [0] and start changing those CVEs to not-affected. I'm
not asking for anyone
to do the work.

As a point of reference, I'm not aware of anyone else evaluating CVEs
like we currently do today, the expectation around this is that "not-affected" is used if it's impossible to exploit the installed package. If someone performs their own build of a package with different flags, that's not officially supported by us anymore.

********************************************************************************

# Stats
As a way of sampling the impact of this issue, I've done a high-level check on how many sets of affected package-CVE we have in our debian:stable docker image[1].

Out of the 82 affected package/CVE pairs, 15 were clear cases of our packages not being affected.

Out of the rest of those, the majority are other cases where we are reporting non-issues, but those require a deeper investigation so I don't want to assume they also fall under this case.

So 18% of the reported affected packages are false-positives. Based on what I've seen, I believe this is a fair estimate to extrapolate.

I've listed some examples to this issue at [2].

I'm confident this is the main reason for us to be over-reporting the number of affected CVEs for our releases, the second one being that we tend to not double check if older releases are affected if the CVE is not important [6].

********************************************************************************

## Alternative solution
If using the "free text comment"[0] is not a good enough way of stating that only the source contains the vulnerable code:

## A1) Add a new sub-state "only-source-vulnerable", to be used in
addition to "not-affected"

## A2) Add a new mutually exclusive state to the set: "not-affected-build-artifacts"

I don't like these approaches because they increase the complexity of
our process,
a new state is more costly than a free text mention, where there's not a clear benefit/motivation.
What's the value in saying the sources carry the vulnerable
code? If someone does their own modified build of a package, all bets are off and that's not an official package.

This also means we would have to modify:
1) The code that generates the OVAL files [3];
2) The code that generates security-tracker json [4];
3) The git hook that validates the contents of the tracking file [5].
The amount of code we need to modify is not an argument on whether
it's the right thing to do or not, but at some point the
implementation cost outweighs the benefit, and it's not clear to me
what's the benefit.

It should also be mentioned that identifying cases where only the source-code is vulnerable will never be done perfectly due to how easy it is to miss a bundled library which is not used. For example, rsync bundles zlib and we do not set rsync as affected for all zlib CVEs (rsync does not use the bundled lib), would we like otherwise to be the case?

Then comparing A1 with A2:
Coming up with a new state is confusing as systems/people reading that might end up parsing it as "affected". So I prefer A1 over A2 if my prefered
option is not chosen.

This being said, the non-preferred alternatives are still better than the current situation IMHO.

********************************************************************************

[0] https://security-team.debian.org/security_tracker.html#summary-of-tracker-syntax
"ignored" and "postponed" are sub-states, supposed to be used
together with "no-dsa".
[1] $ grype debian:stable
[2] https://security-tracker.debian.org/tracker/CVE-2011-3374
[2] https://security-tracker.debian.org/tracker/CVE-2022-0563
[2] https://security-tracker.debian.org/tracker/CVE-2017-18018
[2] https://security-tracker.debian.org/tracker/CVE-2019-19882
[2] https://security-tracker.debian.org/tracker/CVE-2023-28320
[3] https://www.debian.org/security/oval/
[4] https://security-tracker.debian.org/tracker/data/json
[5] https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/ab5ceb2e9d531c73d59bb26d67505d24eec16c22/bin/check-syntax
[6] I've seen a few cases where the vulnerability didn't exist in the
versions we shipped in oldstable or oldoldstable but we didn't check
it due to the low severity, so we report as "affected" to be on the
safe side.
I have fixed a few cases of this myself, but I have some
ideas on how to automate some of it by comparing it with other
distros. This is something I plan to work on, but only after solving
the issue on this proposal.
All of this being said, I think Debian is exceptionally good, and
still a reference for the industry, with regards to identifying the
exact range of affected versions of a software and publishing that for
everyone to see in the security-tracker.

Cheers,


--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

On Wed, 4 Sept 2024 at 12:47, Emilio Pozuelo Monfort <[email protected]> wrote:

One issue I see with using not-affected for this is that not-affected effectively marks all older versions as that. However, in this case, a source could be affected (e.g. in bookworm) and then in sid we've stopped building the
affected files. If we mark sid as not-affected, then all older suites would be
marked as such too, which would be wrong/confusing. Perhaps in situations like
that, we could mark the sid version as fixed in x.y version, leaving the older
suites open until they are triaged (fix released, or marked as no-dsa etc).

I think that's sensible, if a more complete solution is needed for this use case, we could change the parsing logic to allow this to happen as well.

In general though, I think this is sensible.

Thank you Emilio,

2 months have passed since my last email, so I would like to ping the security team for feedback on this.

To confirm the expectations from this change, I've recently scanned a debian minimal image for CVEs and found out:

18 out of 67 affected packages/CVE are false positives due to this issue, this represents 26% of false-positives

7 out out 33 unique affecting CVEs are false positives due to this issue, this represents 21% of false-positives.

Depending on whether you care more about unique affecting CVE IDs or affected packages (a single CVE can affect multiple packages), the number of false-positives is either 21% or 26%.

I'm using a container just as a sampling source here, it is a specially good way of sampling this because a lot of important and highly downloaded docker containers are based on the Debian images.

Take the two most downloaded container images from dockerhub as an example: memcached and nginx. Memcached was pulled 12,377,951,846 times and nginx 12,035,807,525. Both of them are based on Debian, the impact of false-positives is considerable.

One of the false-positives is a specially interesting case: https://security-tracker.debian.org/tracker/CVE-2019-19882Quoting a part of it:

shadow 4.8, in certain circumstances affecting at least Gentoo, Arch Linux, and Void Linux, allows local...

That's a CVE which was created for Gentoo, Arch Linux, and Void Linux. They have all fixed this already, but Debian ends up "stuck" with it, we report ourselves as affected for something we can't fix. While the affected distros fixed it and the other non-affected distros marked as not-affected, we are the only ones still left with the CVE.

Regards,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Samuel,

On Tue, Oct 29, 2024 at 07:06:23PM +0000, Samuel Henrique wrote:

Hello everyone,

On Wed, 4 Sept 2024 at 12:47, Emilio Pozuelo Monfort <[email protected]> wrote:

One issue I see with using not-affected for this is that not-affected effectively marks all older versions as that. However, in this case, a source
could be affected (e.g. in bookworm) and then in sid we've stopped building the
affected files. If we mark sid as not-affected, then all older suites would be
marked as such too, which would be wrong/confusing. Perhaps in situations like
that, we could mark the sid version as fixed in x.y version, leaving the older
suites open until they are triaged (fix released, or marked as no-dsa etc).

I think that's sensible, if a more complete solution is needed for this use case, we could change the parsing logic to allow this to happen as well.

In general though, I think this is sensible.

Thank you Emilio,

2 months have passed since my last email, so I would like to ping the security
team for feedback on this.

To confirm the expectations from this change, I've recently scanned a debian minimal image for CVEs and found out:

18 out of 67 affected packages/CVE are false positives due to this issue, this
represents 26% of false-positives

7 out out 33 unique affecting CVEs are false positives due to this issue, this
represents 21% of false-positives.

Depending on whether you care more about unique affecting CVE IDs or affected packages (a single CVE can affect multiple packages), the number of false-positives is either 21% or 26%.

I'm using a container just as a sampling source here, it is a specially good way of sampling this because a lot of important and highly downloaded docker containers are based on the Debian images.

Take the two most downloaded container images from dockerhub as an example: memcached and nginx. Memcached was pulled 12,377,951,846 times and nginx 12,035,807,525. Both of them are based on Debian, the impact of false-positives
is considerable.

As mentioned in an earlier message: What I would love to see is to
actually have a substate which makes the situation clear, and still
beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

One of the false-positives is a specially interesting case: https://security-tracker.debian.org/tracker/CVE-2019-19882Quoting a part of it:

shadow 4.8, in certain circumstances affecting at least Gentoo, Arch Linux, and Void Linux, allows local...

That's a CVE which was created for Gentoo, Arch Linux, and Void Linux. They have all fixed this already, but Debian ends up "stuck" with it, we report ourselves as affected for something we can't fix. While the affected distros fixed it and the other non-affected distros marked as not-affected, we are the
only ones still left with the CVE.

Can it be that in this case the "unimportant" part of the CVE was
ignored? In this case even if it would have been still unfixed, it was
marked from the beginning as unimportant. What I have seen often here
was that scannings were not taking into account that the whole CVE was classified unimportant.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

I'll merge my replies to Moritz and Salvatore into a single email.

Moritz,

On Tue, 29 Oct 2024 at 19:15, Moritz M�hlenhoff <[email protected]> wrote:

I'm also in favour of changing the tracking. The current procedure addresses a
fringe use case (supporting rebuilds of source packages) in an incomplete manner
and leaves too much room for confusion.

Right, so as a part of this change, we need to make sure we always allow older releases to still be marked as affected or any other status.

I assume all the code that needs to be updated for this lives under the security-tracker package, right?

Salvatore,

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to
actually have a substate which makes the situation clear, and still
beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

Can it be that in this case the "unimportant" part of the CVE was
ignored?

It did show up as unimportant in my report, but it was still marked as affecting.

In this case even if it would have been still unfixed, it was
marked from the beginning as unimportant. What I have seen often here
was that scannings were not taking into account that the whole CVE was classified unimportant.

I've realized that by the time I sent my email it had already been updated in the tracker to not-affected (I used scan results from roughly 1 week before the email), happy coincidence but we were claiming to be affected for 5 years until then.

This CVE is now marked as fixed in our tracker as the upstream version we ship mitigated that (even though Debian was never really affected). So a new scan today for oldstable/stable will have this as a fixed CVE and there's no false-positive, at least for oldstable and newer.

It is still marked as affecting buster and older releases and so users might think they are fixing something through the upgrade: https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/abda8e71a6c2e45c8219c9fb86792fb4da2468cb

Freexian's security tracker to show that buster and olders are still affected per the current process: https://deb.freexian.com/extended-lts/tracker/CVE-2019-19882

Thank you for the feedback so far!

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Salvatore,

On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <[email protected]> wrote:

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to
actually have a substate which makes the situation clear, and still
beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

Could you check if the suggestion above addresses your concern?

Cheers,


--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Samuel,

On Wed, Nov 27, 2024 at 11:28:50PM +0000, Samuel Henrique wrote:

Hello Salvatore,

On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <[email protected]> wrote:

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to actually have a substate which makes the situation clear, and still beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

Could you check if the suggestion above addresses your concern?

Not yet, but I will try to schedule a bit of time in the next weeks
for security-tracker stuff and have a look at this.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Salvatore,

On Sun, 1 Dec 2024 at 14:08, Salvatore Bonaccorso <[email protected]> wrote:

On Wed, Nov 27, 2024 at 11:28:50PM +0000, Samuel Henrique wrote:

On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <[email protected]> wrote:

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to actually have a substate which makes the situation clear, and still beeing technically correct. I was envisioning something which would be a substate like we have for the substate of no-dsa (ignored, postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

Could you check if the suggestion above addresses your concern?

Not yet, but I will try to schedule a bit of time in the next weeks
for security-tracker stuff and have a look at this.

Just checking if you would have time to look into this.

Thank you,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello everyone,

On Sun, 2 Mar 2025 at 20:26, Samuel Henrique <[email protected]> wrote:

Just checking if you would have time to look into this.

Sending another ping, this proposal is now 1 year old.

For clarity, I'm not requesting the team to do any work here. I can work on the changes, I just need a decision on the solution.

Personally, I have it as a high priority to cut down those 20% false-positive CVEs reported for Debian containers, since a lot of official containers are based on us, but this will also help non-container users.

I'm hoping that sending this is fine, but let me know if I should have waited more than a month from the previous message.

Regards,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Apr 13, 2025 at 04:06:38PM +0100, Samuel Henrique wrote:

Hello everyone,

On Sun, 2 Mar 2025 at 20:26, Samuel Henrique <[email protected]> wrote:

Just checking if you would have time to look into this.

Sending another ping, this proposal is now 1 year old.

For clarity, I'm not requesting the team to do any work here. I can work on the
changes, I just need a decision on the solution.

Personally, I have it as a high priority to cut down those 20% false-positive CVEs reported for Debian containers, since a lot of official containers are based on us, but this will also help non-container users.

I'm hoping that sending this is fine, but let me know if I should have waited more than a month from the previous message.

Yes it's fine that you do a ping on things which are of a priority for
you. And just to be clear, the security-tracker is very important to
me as well, in particular to enable our work ;-)

I believe the changes should go in the direction I tried to hilight,
or more concretely have a "nonissue" state, which still reflects
correctly that the issue is there, but without any (practical) impact.
That will make for instance moot the unimportant severity which only
can be applied as whole to a source entry, but not to individual suite
entries.

I have not gone to all details of your proposal, but the high level
view is IMHO as described in short above. For instance for the zlib
isues that would then move the entries from the ignored (which is a
substate of a no-dsa and apparently comercial security scanner are not
willing to parse or adapt to) to the more narrowed down and specified
substate of nonissue. In particular such a vunerability state could
exactly reflect as well per suite entry in case the state changes
between them.

Hope this clarifies that you are not beeing ignored (heh ;-) no punt
intended here :)), which is as well quite important to me to let you
know.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Salvatore,

On Sun, 13 Apr 2025 at 16:32, Salvatore Bonaccorso <[email protected]> wrote:

I have not gone to all details of your proposal, but the high level
view is IMHO as described in short above. For instance for the zlib
isues that would then move the entries from the ignored (which is a
substate of a no-dsa and apparently comercial security scanner are not willing to parse or adapt to) to the more narrowed down and specified substate of nonissue. In particular such a vunerability state could
exactly reflect as well per suite entry in case the state changes
between them.

You mentioned this previously, which is a fair point. I believe one of the alternatives would work, what do you think?

Quoting from that email:
On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <[email protected]> wrote:

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to
actually have a substate which makes the situation clear, and still
beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

I think there wasn't a confirmation after this email.

Hope this clarifies that you are not beeing ignored (heh ;-) no punt
intended here :)), which is as well quite important to me to let you
know.

Definitely, I didn't mean to suggest that it's not as important to you as well, and thank you for replying!

Regards,

--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Samuel,

On Sun, Apr 13, 2025 at 04:47:38PM +0100, Samuel Henrique wrote:

Hello Salvatore,

On Sun, 13 Apr 2025 at 16:32, Salvatore Bonaccorso <[email protected]> wrote:

I have not gone to all details of your proposal, but the high level
view is IMHO as described in short above. For instance for the zlib
isues that would then move the entries from the ignored (which is a substate of a no-dsa and apparently comercial security scanner are not willing to parse or adapt to) to the more narrowed down and specified substate of nonissue. In particular such a vunerability state could
exactly reflect as well per suite entry in case the state changes
between them.

You mentioned this previously, which is a fair point. I believe one of the alternatives would work, what do you think?

Quoting from that email:
On Sat, 2 Nov 2024 at 20:02, Samuel Henrique <[email protected]> wrote:

On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso <[email protected]> wrote:

As mentioned in an earlier message: What I would love to see is to actually have a substate which makes the situation clear, and still beeing technically correct. I was envisioning something which would be
a substate like we have for the substate of no-dsa (ignored,
postponed).

This sounds like the solution proposal A2, quoting it:

## A2) Add a new mutually exclusive state to the set:

"not-affected-build-artifacts"

Would this be aligned to what you're looking for?

Yes the A2 would go in the direction we are thingking, internally we
have said to it a new "nonissue" state, which can apply as well at
suite entry levels (this was not possible with the unimportant severiy
as major drawback). The nonissue (or not-affected-build-artifacts as
you call it, but we can decide on a name once developing) state would
be a new state so we can cover exactly for instance the zlib case,
several curl cases were a feature is not enabled in a given suite, say
bookworm not, but above are. So as a purely example:

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might ...)
- curl 8.11.0-1 (bug #1086804)
[bookworm] - curl 7.88.1-10+deb12u9
[bullseye] - curl <ignored> (curl is not built with HSTS support)

Would become

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might ...)
- curl 8.11.0-1 (bug #1086804)
[bookworm] - curl 7.88.1-10+deb12u9
[bullseye] - curl <nonissue> (curl is not built with HSTS support)

Or

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
- doas <removed>
[bullseye] - doas <no-dsa> (Minor issue)
- opendoas <unfixed> (bug #1034185)
[trixie] - opendoas <not-affected> (Addressed via Linux kernel change)
[bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

would become

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
- doas <removed>
[bullseye] - doas <no-dsa> (Minor issue)
- opendoas <unfixed> (bug #1034185)
[trixie] - opendoas <nonissue> (Addressed via Linux kernel change)
[bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

Similarly we could handle CVE-2016-2568, CVE-2016-2781, CVE-2023-28339
in better ways than workaround.

Thos are just examples, and I think you have a more complete list (can
you share the CVEs so we can see how that would map into such a
state?)

I think there wasn't a confirmation after this email.

Indeed, there were enough other things do do and that one had little
less priority (in terms of point of view obviously, everyone has it's
own priority list).

Hope this clarifies that you are not beeing ignored (heh ;-) no punt intended here :)), which is as well quite important to me to let you
know.

Definitely, I didn't mean to suggest that it's not as important to you as well,
and thank you for replying!

Ack, done now.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Salvatore, sorry about the late reply, I was in MiniDebConf Macei�.

On Thu, 1 May 2025 at 06:24, Salvatore Bonaccorso <[email protected]> wrote:

Yes the A2 would go in the direction we are thingking, internally we
have said to it a new "nonissue" state, which can apply as well at
suite entry levels (this was not possible with the unimportant severiy
as major drawback). The nonissue (or not-affected-build-artifacts as
you call it, but we can decide on a name once developing) state would
be a new state so we can cover exactly for instance the zlib case,
several curl cases were a feature is not enabled in a given suite, say bookworm not, but above are. So as a purely example:

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <ignored> (curl is not built with HSTS support)

Would become

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <nonissue> (curl is not built with HSTS support)

Or

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <not-affected> (Addressed via Linux kernel change)
� � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

would become

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <nonissue> (Addressed via Linux kernel change)
� � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

Similarly we could handle CVE-2016-2568, CVE-2016-2781, CVE-2023-28339
in better ways than workaround.

Thos are just examples, and I think you have a more complete list (can
you share the CVEs so we can see how that would map into such a
state?)

I'm currently traveling and don't have access to the list I previously checked (will only reach that PC close to June).

But I think "nonissue" will work perfectly, at least as long as we also define that <nonissue> will always result in the security-tracker (web UI, json) and OVAL file (or alternatives we might generate in the future) showing the package's binaries as "not-affected". Is this in line with what you discussed?

I'm asking because "nonissue" has a broader definition compared to "not-affected-build-artifacts", and if "nonissue" is used for questionable CVEs (e.g.: CVEs for elfutils or without security impact), then we can't end up in a situation where "nonissue" is not evaluated as "not-affected", as this defeats the whole purpose of the solution.


Thank you,


--
Samuel Henrique <samueloph>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear security team,

El 10/05/25 a las 16:14, Samuel Henrique escribi�:

Hello Salvatore, sorry about the late reply, I was in MiniDebConf Macei�.

On Thu, 1 May 2025 at 06:24, Salvatore Bonaccorso <[email protected]> wrote:

Yes the A2 would go in the direction we are thingking, internally we
have said to it a new "nonissue" state, which can apply as well at
suite entry levels (this was not possible with the unimportant severiy
as major drawback). The nonissue (or not-affected-build-artifacts as
you call it, but we can decide on a name once developing) state would
be a new state so we can cover exactly for instance the zlib case,
several curl cases were a feature is not enabled in a given suite, say bookworm not, but above are. So as a purely example:

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <ignored> (curl is not built with HSTS support)

Would become

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <nonissue> (curl is not built with HSTS support)

Or

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <not-affected> (Addressed via Linux kernel change)
� � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

would become

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <nonissue> (Addressed via Linux kernel change) � � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

Similarly we could handle CVE-2016-2568, CVE-2016-2781, CVE-2023-28339
in better ways than workaround.

Thos are just examples, and I think you have a more complete list (can
you share the CVEs so we can see how that would map into such a
state?)

I'm currently traveling and don't have access to the list I previously checked
(will only reach that PC close to June).

But I think "nonissue" will work perfectly, at least as long as we also define
that <nonissue> will always result in the security-tracker (web UI, json) and OVAL file (or alternatives we might generate in the future) showing the package's binaries as "not-affected". Is this in line with what you discussed?

I'm asking because "nonissue" has a broader definition compared to "not-affected-build-artifacts", and if "nonissue" is used for questionable CVEs
(e.g.: CVEs for elfutils or without security impact), then we can't end up in a
situation where "nonissue" is not evaluated as "not-affected", as this defeats
the whole purpose of the solution.

[snip]

Would you be OK if we track the above proposal on a salsa issue in, https://salsa.debian.org/security-tracker-team/security-tracker/-/issues?
If you are OK, I could volunteer to file the issue. But I'd be happy if
Samuel files it too.

As you are aware, the Debian LTS team is planning to hold a sprint
during DebCamp 25. And if the above proposal is beneficial for you too
(I think this would help us in the context of LTS and ELTS), it would be
great to include it in the "target issues" to be addressed in the
context of the sprint.

Best,

-- Santiago

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQR+lHTq7mkJOyB6t2Un3j1FEEiG7wUCaCeB9AAKCRAn3j1FEEiG 7wnpAP9881P7bWMOnqXAU0hzcckbtf8N2n/Nnd1FlLTrrrdOsgD/TdSKIfIPU6ER GFY9NOOQFMVXYbY5RW9pFkZQDP+u+wM=
=uBRF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Santiago,

On Fri, May 16, 2025 at 03:20:36PM -0300, Santiago Ruano Rinc�n wrote:

Dear security team,

El 10/05/25 a las 16:14, Samuel Henrique escribi�:

Hello Salvatore, sorry about the late reply, I was in MiniDebConf Macei�.

On Thu, 1 May 2025 at 06:24, Salvatore Bonaccorso <[email protected]> wrote:

Yes the A2 would go in the direction we are thingking, internally we
have said to it a new "nonissue" state, which can apply as well at
suite entry levels (this was not possible with the unimportant severiy
as major drawback). The nonissue (or not-affected-build-artifacts as
you call it, but we can decide on a name once developing) state would
be a new state so we can cover exactly for instance the zlib case, several curl cases were a feature is not enabled in a given suite, say bookworm not, but above are. So as a purely example:

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <ignored> (curl is not built with HSTS support)

Would become

CVE-2024-9681 (When curl is asked to use HSTS, the expiry time for a subdomain might �...)
� � � � - curl 8.11.0-1 (bug #1086804)
� � � � [bookworm] - curl 7.88.1-10+deb12u9
� � � � [bullseye] - curl <nonissue> (curl is not built with HSTS support)

Or

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <not-affected> (Addressed via Linux kernel change)
� � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

would become

CVE-2023-28339 (OpenDoas through 6.8.2, when TIOCSTI is available, allows privilege es ...)
� � � � - doas <removed>
� � � � [bullseye] - doas <no-dsa> (Minor issue)
� � � � - opendoas <unfixed> (bug #1034185)
� � � � [trixie] - opendoas <nonissue> (Addressed via Linux kernel change)
� � � � [bookworm] - opendoas <ignored> (Minor issue, will be addressed via kernel change which isn't in 6.1 yet)

Similarly we could handle CVE-2016-2568, CVE-2016-2781, CVE-2023-28339
in better ways than workaround.

Thos are just examples, and I think you have a more complete list (can you share the CVEs so we can see how that would map into such a
state?)

I'm currently traveling and don't have access to the list I previously checked
(will only reach that PC close to June).

But I think "nonissue" will work perfectly, at least as long as we also define
that <nonissue> will always result in the security-tracker (web UI, json) and
OVAL file (or alternatives we might generate in the future) showing the package's binaries as "not-affected". Is this in line with what you discussed?

I'm asking because "nonissue" has a broader definition compared to "not-affected-build-artifacts", and if "nonissue" is used for questionable CVEs
(e.g.: CVEs for elfutils or without security impact), then we can't end up in a
situation where "nonissue" is not evaluated as "not-affected", as this defeats
the whole purpose of the solution.

[snip]

Would you be OK if we track the above proposal on a salsa issue in, https://salsa.debian.org/security-tracker-team/security-tracker/-/issues?
If you are OK, I could volunteer to file the issue. But I'd be happy if Samuel files it too.

As you are aware, the Debian LTS team is planning to hold a sprint
during DebCamp 25. And if the above proposal is beneficial for you too
(I think this would help us in the context of LTS and ELTS), it would be great to include it in the "target issues" to be addressed in the
context of the sprint.

Given during development there will be needed review, maybe subtask
etc ... yes I agree that we can start tracking the tasks around the
nonissue state as issue in the tracker.

So to move it outside of a mail thread directly to the salsa.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, May 18, 2025 at 06:43:37PM +0200, Salvatore Bonaccorso wrote:

Hi Santiago,

On Fri, May 16, 2025 at 03:20:36PM -0300, Santiago Ruano Rinc�n wrote:

Would you be OK if we track the above proposal on a salsa issue in, https://salsa.debian.org/security-tracker-team/security-tracker/-/issues? If you are OK, I could volunteer to file the issue. But I'd be happy if Samuel files it too.

As you are aware, the Debian LTS team is planning to hold a sprint
during DebCamp 25. And if the above proposal is beneficial for you too
(I think this would help us in the context of LTS and ELTS), it would be great to include it in the "target issues" to be addressed in the
context of the sprint.

Given during development there will be needed review, maybe subtask
etc ... yes I agree that we can start tracking the tasks around the
nonissue state as issue in the tracker.

So to move it outside of a mail thread directly to the salsa.

For the sake of completeness, here is the issue that Samuel has written: https://salsa.debian.org/security-tracker-team/security-tracker/-/issues/32

Regards,

-Roberto

--
Roberto C. S�nchez

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)