, 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
> 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 wrote:
> On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso wrote:
> > As mentioned in
Hello everyone,
On Sun, 2 Mar 2025 at 20:26, Samuel Henrique 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
Hello Salvatore,
On Sun, 1 Dec 2024 at 14:08, Salvatore Bonaccorso wrote:
> On Wed, Nov 27, 2024 at 11:28:50PM +0000, Samuel Henrique wrote:
> > On Sat, 2 Nov 2024 at 20:02, Samuel Henrique wrote:
> > > On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso
> > > wrote:
Hello Salvatore,
On Sat, 2 Nov 2024 at 20:02, Samuel Henrique wrote:
> On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso 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
> &g
219c9fb86792fb4da2468cb
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
t, 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
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
https://youtu.be/XzNVVILVyUM
Cheers,
--
Samuel Henrique
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
tion 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
ge. I am confident that it would be a valuable addition to the
> Debian repositories. :-)
I see that sergiodj has already uploaded this one, replying here so it won't
look like it's pending.
Thank you for contributing!
--
Samuel Henrique
this but I'm sending this email so we can "close" this
request.
--
Samuel Henrique
On Wed, 3 Apr 2024 at 17:04, Gian Piero Carrubba 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 th
74
[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
15 matches
Mail list logo
