Re: Remove support for nvidia-cuda-toolkit?
Hi Done now. See https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/116 // Ola On Mon, 15 Apr 2024 at 23:59, Roberto C. Sánchez wrote: > > On Mon, Apr 15, 2024 at 11:32:14PM +0200, Ola Lundqvist wrote: > > Hi Roberto > > > > Got it. I will assess. I guess also the popularity of the package > > counts in this case. > > > Yes, the popularity of a package is a factor in the process of making an > EOL decision. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Re: freeimage and CVE-2019-12214
Hi Cyrille, El 16/04/24 a las 16:09, Cyrille Bollu escribió: > Hi Santiago, > > >It is not a question of trust. It is a problem of lack of strong > >evidence that the issue is no longer there in freeimage or openjepg2. > >We cannot rely only on CVE description to track the issues. > > I think you'd be right to not trust my analysis too lightly since it's > my first contribution here. And, not knowing your practices at all, I > might easily have overlooked things indeed. And thanks for you help! > That being said, I'm not sure I agree with you that we lack "strong > evidence that the issue is no longer there in freeimage or openjepg2". > > Reading your sentence, I understand that there are 2 things to be > proven: > > 1. That the freeimage package (in Debian Buster, FWR Debian LTS) is not > affected by this vulnerability; > 2. That the openjpeg2 package (in Debian Buster, FWR Debian LTS) is not > affected by this vulnerability > > As I believe these 2 concerns have been addressed, I'm wondering if you > are thinking of something else...? [...] Sorry if I was not verbose and clear enough in my previous messages. You are correct about saying that you have addressed these two hypothesis, but the problem is the information available to verify them relies *only* on the CVE description and its currently only reference: https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/ With a strong evidence I was thinking about a reproducer, confirmation from upstreams, or a stack trace, as Hugo mentioned in the note he added in the security-tracker: https://security-tracker.debian.org/tracker/CVE-2019-12214 Other than the available descriptions, how can be 100% sure the code refactoring made with openjpeg2 2.1.0-1 clearly fixes the out-of-bound access? We are only assuming the issue is in an embedded copy of openjpeg2, and there is a commit that could have fixed it. I would like to insist that we prefer to be wrong on the safe side, keeping an issue open (rather than claiming it is fixed without a more clear evidence) and continue to track it. However, I would like to mention *I* think it was worth to inform MITRE about the code mentioned in the CVE description was found in an embedded copy of openjpeg2 in freeimage (So thank you for that!). But it is likely that the security team has a different opinion about this. I hope this brings some light to the issue. > I hope my questions are not totally off-topic and that they bring > something to the discussion. Your questions are completely on-topic. Thank you for asking! Cheers, -- Santiago
Re: debian-backports missing packages
hi, I was told by formorer that there will be announcement about this change later today, as well as an update to the documentation. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Kinda weird that we’re all gonna experience climate change as a series of short, apocalyptic videos until eventually it’s your phone that’s recording. (@shocks) signature.asc Description: PGP signature
Re: freeimage and CVE-2019-12214
Hi Santiago, >It is not a question of trust. It is a problem of lack of strong >evidence that the issue is no longer there in freeimage or openjepg2. >We cannot rely only on CVE description to track the issues. I think you'd be right to not trust my analysis too lightly since it's my first contribution here. And, not knowing your practices at all, I might easily have overlooked things indeed. That being said, I'm not sure I agree with you that we lack "strong evidence that the issue is no longer there in freeimage or openjepg2". Reading your sentence, I understand that there are 2 things to be proven: 1. That the freeimage package (in Debian Buster, FWR Debian LTS) is not affected by this vulnerability; 2. That the openjpeg2 package (in Debian Buster, FWR Debian LTS) is not affected by this vulnerability As I believe these 2 concerns have been addressed, I'm wondering if you are thinking of something else...? Let me now summarize why I believe these 2 concerns have been addressed: 1. Regarding Debian's freeimage package === I believe that proof has been made that Debian's freeimage package in Buster is using the openjpeg2's system libraries, hence that this CVE cannot be assigned to this package. Don't you agree? 2. Regarding Debian's openjpeg2 package == The vulnerability is reported in function j2k_read_ppm_v3 in file j2k.c. That function has been completely removed from this file. In such case, I wonder how this CVE would still apply to this library. Am I missing something? I hope my questions are not totally off-topic and that they bring something to the discussion. Best regards, Cyrille Le lundi 15 avril 2024 à 18:32 -0300, Santiago Ruano Rincón a écrit : > Hi, > > El 15/04/24 a las 21:47, Ola Lundqvist escribió: > > Hi Santiago > > > > On Mon, 15 Apr 2024 at 21:10, Santiago Ruano Rincón > > wrote: > > > > > > Hi Ola, > > > > > > As being discussed with Salvatore, there is not enough evidence > > > to > > > conclude there is not any issue present on the freeimage side. > > > > Do I understand correctly that the evidence that Cyrille provided > > is not enough? > > > From the different inputs available, *I* would add this issue as > affecting openjpeg2 for being able to track it there too. And I would > wait for the response by MITRE. I have not confirmed Salvatore or the > Securiy Team shares that opinion, though. > > I don't have at hand anything that clearly tells me the issue is no > longer present after openjpeg2 2.1.0-1. > > > > We need > > > to be on the safe side, like *always*, and with marking freeimage > > > as > > > we would stop tracking the issue. > > > To stay on the safe side, we need to keep tracking the issue. > > > > If we do not trust that analysis from Cyrille, I agree with you. > > It is not a question of trust. It is a problem of lack of strong > evidence that the issue is no longer there in freeimage or openjepg2. > We > cannot rely only on CVE description to track the issues. > > > > Hugo mentioned this refactoring commit that *could* have fixed > > > the issue: > > > https://github.com/uclouvain/openjpeg/commit/c887df12a38ff1a2721d0c8a93b74fe1d02701a2 > > > Ref: > > > https://sourceforge.net/p/freeimage/discussion/36111/thread/e06734bed5/#b887/4639 > > > But without any reproducer, it is hard to conclude the issue was > > > fixed. > > > > Yes without a reproducer we cannot tell with absolute certainty, > > unless we create a new reproducer. > > And marking a package as by an issue requires to have > absolute certainty. > > > > One possibility would be to mark it as , but not as > > > . > > > > That is a possibility, yes. Is this what you propose then? > > If you propose to create a new reproducer; so I would not mark it as > :-) > > > > wouldn't make sense since the reported > > > hasn't shared any more information in five years. > > > > That was new to me. I thought we did not issues purely > > because we have not more info. > > But I agree with you that ignoring really old things for which we > > have > > no more info makes sense. > > I was not aware that it was an ok thing to do. > > The above was a suggestion made by Salvatore and I cannot talk for > the > security team. This is just one possible action. My understanding, > for > this kind of cases, is marking it as where there is > **really** > nothing else we can do, while still tracking the issue. But if you > are > able to reproduce the issue, or provide more information, leaving it > as > open (until we can conclude something different) makes equally sense. > > HTH, > > -- Santiago >
Re: debina-backports missing packages
Varghese Paul (2024-04-15): I am encountering an issue with the Buster-backports repository. It seems that the repository does not have a Release file, which is preventing package management tools from retrieving updates or installing new packages from this source. On 16.04.24 07:57, Cyril Brulebois wrote: https://lists.debian.org/debian-devel-announce/2024/03/msg3.html http://archive.debian.org/debian/dists/buster-backports/ On 16.04.24 08:45, Matus UHLAR - fantomas wrote: Thanks for info, I just encountered this problem too. I would expect this to be posted to debian-backports-announce as well. https://lists.debian.org/debian-backports-announce/ Or, because this will affects buster (which is currently in LTS stage) immediately after packages are removed from main archive, perhaps even debian-lts-announce. I'm Cc:ing this to debian-lts if people are interested in such announce -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. He who laughs last thinks slowest.
