Hi,
On Fri, Apr 26, 2024 at 08:32:21PM +0200, Cyrille Bollu wrote:
>
>
> Le vendredi 26 avril 2024 à 12:50 -0300, Santiago Ruano Rincón a
> écrit :
> > Hi Cyrille!
> >
> > El 25/04/24 a las 15:00, Cyrille Bollu escribió:
> > > Hi Santiago,
> > >
> > > Here's some follow up :-)
> > >
> > > Bes
Le vendredi 26 avril 2024 à 12:50 -0300, Santiago Ruano Rincón a
écrit :
> Hi Cyrille!
>
> El 25/04/24 a las 15:00, Cyrille Bollu escribió:
> > Hi Santiago,
> >
> > Here's some follow up :-)
> >
> > Best regards,
> >
> > Cyrille
> >
> > Le mardi 16 avril 2024 à 12:52 -0300, Santiago Ruano R
Hi Cyrille!
El 25/04/24 a las 15:00, Cyrille Bollu escribió:
> Hi Santiago,
>
> Here's some follow up :-)
>
> Best regards,
>
> Cyrille
>
> Le mardi 16 avril 2024 à 12:52 -0300, Santiago Ruano Rincón a écrit :
> > Hi Cyrille,
> >
> > El 16/04/24 a las 16:09, Cyrille Bollu escribió:
> > > Hi S
Hi Santiago,
Here's some follow up :-)
Best regards,
Cyrille
Le mardi 16 avril 2024 à 12:52 -0300, Santiago Ruano Rincón a écrit :
> 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
> >
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 yo
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 contri
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.
>
> D
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 enou
Hi Ola,
As being discussed with Salvatore, there is not enough evidence to
conclude there is not any issue present on the freeimage side. 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 tracki
Hi again
I also think we should close #947478 but since I guess that should be
done by the regular Debian security team I do not want to do that
without you telling me that it is ok. I have not checked later
releases, but I think it should apply there too.
Cheers
// Ola
On Mon, 15 Apr 2024 at 2
Hi Santiago and Salvatore
Now I realize what I did wrong. I should have put openjpeg on a line later.
Do you want me to fix that or do you want to do that yourself?
This is my proposal if I change only for buster.
ola@tigereye:~/git/security-tracker$ git diff
diff --git a/data/CVE/list b/data/C
>Cyrille, would you mind submitting your update to MITRE instead?
Done
Le lundi 15 avril 2024 à 10:29 -0300, Santiago Ruano Rincón a écrit :
> Hi,
>
> Cyrille, thank you for checking this. However, I don't think the
> contact
> address you had sent the email is correct.
> CVE is maintained by MI
Hi,
Cyrille, thank you for checking this. However, I don't think the contact
address you had sent the email is correct.
CVE is maintained by MITRE (not NIST). And there exist several CNAs that
could issue CVE IDs for specific products/domains.
According to https://www.cve.org/CVERecord?id=CVE-2019
Hi Cyrille
Thank you very much.
I'll update the security tracker accordingly.
// Ola
On Sun, 14 Apr 2024 at 12:24, Cyrille Bollu wrote:
> Hi,
>
> I've performed a more thoroughful investigation and have informed NIST
> that the offending line is actually to be found in openjpeg between
> vers
Hi,
I've performed a more thoroughful investigation and have informed NIST
that the offending line is actually to be found in openjpeg between
version 2.0.0 up to (excluding) 2.1.0.
Debian Buster isn't affected as it uses version 2.3.0-2+deb10u2.
Hereunder copy of the email I've sent ot NIST.
B
Thank you for your help!
On Sat, 13 Apr 2024 at 09:56, Cyrille wrote:
>
> I don’t know anything about your procedures, but I don’t see why we wouldn’t…
>
> I would also contact NIST (or whoever is in charge of the CVE database; I
> can’t remember by heart who it is) to let them know this, so the
I don’t know anything about your procedures, but I don’t see why we wouldn’t…
I would also contact NIST (or whoever is in charge of the CVE database; I can’t
remember by heart who it is) to let them know this, so they update the CVE’s
vulnerable configurations. I’ll try to do that next week, but
Hi Cyrille
On Fri, 12 Apr 2024 at 16:32, Cyrille Bollu wrote:
>
> Hi Ola,
>
> Thank you for your help.
>
> So, IIUC:
>
> 1. CVE-2019-12214 shouldn't be assigned to freeimage in Debian Buster;
> 2. CVE-2019-12214 might be assigned to source package openjpeg2 or
> openjpeg (the later doesn't seem t
Hi Santiago
Yes that is better. This was just a reply to Cyrille telling that the
package in buster does not have that directory.
// Ola
On Fri, 12 Apr 2024 at 16:24, santiago wrote:
>
> Hi,
>
> El 12/04/24 a las 12:00, Ola Lundqvist escribió:
> > Hi Cyrille
> >
> > See below.
> >
> > On Fri, 1
Hi Ola,
Thank you for your help.
So, IIUC:
1. CVE-2019-12214 shouldn't be assigned to freeimage in Debian Buster;
2. CVE-2019-12214 might be assigned to source package openjpeg2 or
openjpeg (the later doesn't seem to be available in Buster though)
Cyrille
Le vendredi 12 avril 2024 à 12:00 +020
Hi,
El 12/04/24 a las 12:00, Ola Lundqvist escribió:
> Hi Cyrille
>
> See below.
>
> On Fri, 12 Apr 2024 at 10:44, Cyrille Bollu wrote:
> >
> >
> > >Thank you! Do you mean that freeimage copy in those files during the
> > >build process?
> >
> > If you download the tarball at
> > https://freeim
Hi Cyrille
See below.
On Fri, 12 Apr 2024 at 10:44, Cyrille Bollu wrote:
>
>
> >Thank you! Do you mean that freeimage copy in those files during the
> >build process?
>
> If you download the tarball at
> https://freeimage.sourceforge.io/download.html you'll find that the,
> once unzipped, it con
>Thank you! Do you mean that freeimage copy in those files during the
>build process?
If you download the tarball at
https://freeimage.sourceforge.io/download.html you'll find that the,
once unzipped, it contains a 'Source/LibOpenJPEG' folder that contains
about the same files as
https://github.
Hi Cyrille
Thank you! Do you mean that freeimage copy in those files during the
build process?
If you could update the notes for this CVE it would be nice. I started
but realized that I had more questions and then it is better if you do
it who knows the answer.
No hurry since this is for a postpo
FTR,
I did a small analysis, and that's for sure that CVE-2019-12214 relates
to code from openjpeg: Looking at the content of folder "LibOpenJpeg"
in freeimage 'source code show exactly the same files as in
https://github.com/uclouvain/openjpeg/tree/master/src/lib/openjp2
However, since freeimage
25 matches
Mail list logo
