tiff: Add jbig PACKAGECONFIG and clarify CVE-2022-1210

We never depended upon libjbig so this was never present. Add the
PACKAGECONFIG to make this explict.

CVE-2022-1210 is an issue in libjbig so we don't have a problem there,
mark as such.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 4 ++++
 1 file changed, 4 insertions(+)

On 5/28/22 03:05, Richard Purdie wrote:
> We never depended upon libjbig so this was never present. Add the
> PACKAGECONFIG to make this explict.
>
> CVE-2022-1210 is an issue in libjbig so we don't have a problem there,
> mark as such.

But what if I am a user or have a customer that needs that enabled? Now 
that issue is masked if I run the CVE checking tools , I will have a 
false sense of security.

I understand that Redhat or Suse can make statements like that  as they 
provide install-able  binaries but for a Project that starts from build 
your own DISTRO, should the community take on this responsibility?

- armin

>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>   meta/recipes-multimedia/libtiff/tiff_4.3.0.bb | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> index c5e964ec8c1..7a5e4816a6e 100644
> --- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> +++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
> @@ -32,6 +32,9 @@ CVE_CHECK_IGNORE += "CVE-2015-7313"
>   # caused by 3079627e and fixed by b4e79bfa.
>   CVE_CHECK_IGNORE += "CVE-2022-1622 CVE-2022-1623"
>   
> +# Issue is in jbig which we don't enable
> +CVE_CHECK_IGNORE += "CVE-2022-1210"
> +
>   inherit autotools multilib_header
>   
>   CACHED_CONFIGUREVARS = "ax_cv_check_gl_libgl=no"
> @@ -40,6 +43,7 @@ PACKAGECONFIG ?= "cxx jpeg zlib lzma \
>                     strip-chopping extrasample-as-alpha check-ycbcr-subsampling"
>   
>   PACKAGECONFIG[cxx] = "--enable-cxx,--disable-cxx,,"
> +PACKAGECONFIG[jbig] = "--enable-jbig,--disable-jbig,jbig,"
>   PACKAGECONFIG[jpeg] = "--enable-jpeg,--disable-jpeg,jpeg,"
>   PACKAGECONFIG[zlib] = "--enable-zlib,--disable-zlib,zlib,"
>   PACKAGECONFIG[lzma] = "--enable-lzma,--disable-lzma,xz,"
>
> 
>

On Sat, 2022-05-28 at 11:07 -0700, akuster wrote:
> 
> On 5/28/22 03:05, Richard Purdie wrote:
> > We never depended upon libjbig so this was never present. Add the
> > PACKAGECONFIG to make this explict.
> > 
> > CVE-2022-1210 is an issue in libjbig so we don't have a problem there,
> > mark as such.
> 
> But what if I am a user or have a customer that needs that enabled? Now 
> that issue is masked if I run the CVE checking tools , I will have a 
> false sense of security.
> 
> I understand that Redhat or Suse can make statements like that  as they 
> provide install-able  binaries but for a Project that starts from build 
> your own DISTRO, should the community take on this responsibility?

This is the same as any of the other decisions we make for
CVE_CHECK_IGNORE. If you bbappend and/or change the configs of recipes,
you need to do some further due diligence.

The fact there isn't a PACKAGECONFIG for it at least suggests it isn't
being used.

What is the alternative? We just list this as unpatched for OE-Core and
let everyone have to look it up for themselves?

Cheers,

Richard

On 5/28/22 12:43, richard.purdie@linuxfoundation.org wrote:
> On Sat, 2022-05-28 at 11:07 -0700, akuster wrote:
>> On 5/28/22 03:05, Richard Purdie wrote:
>>> We never depended upon libjbig so this was never present. Add the
>>> PACKAGECONFIG to make this explict.
>>>
>>> CVE-2022-1210 is an issue in libjbig so we don't have a problem there,
>>> mark as such.
>> But what if I am a user or have a customer that needs that enabled? Now
>> that issue is masked if I run the CVE checking tools , I will have a
>> false sense of security.
>>
>> I understand that Redhat or Suse can make statements like that  as they
>> provide install-able  binaries but for a Project that starts from build
>> your own DISTRO, should the community take on this responsibility?
> This is the same as any of the other decisions we make for
> CVE_CHECK_IGNORE. If you bbappend and/or change the configs of recipes,
> you need to do some further due diligence.
>
> The fact there isn't a PACKAGECONFIG for it at least suggests it isn't
> being used.
Maybe.
>
> What is the alternative? We just list this as unpatched for OE-Core and
> let everyone have to look it up for themselves?

The first two ideas that come to mind are:
1) Make the PACKAGECONFIG = CVE # and a note in the recipe to provide a 
clue.
2) Create some sort of frame work to warn if that pkg config is enabled.

- armin
>
> Cheers,
>
> Richard
>
>

On Tue, 2022-05-31 at 07:10 -0700, akuster wrote:
> 
> On 5/28/22 12:43, richard.purdie@linuxfoundation.org wrote:
> > On Sat, 2022-05-28 at 11:07 -0700, akuster wrote:
> > > On 5/28/22 03:05, Richard Purdie wrote:
> > > > We never depended upon libjbig so this was never present. Add the
> > > > PACKAGECONFIG to make this explict.
> > > > 
> > > > CVE-2022-1210 is an issue in libjbig so we don't have a problem there,
> > > > mark as such.
> > > But what if I am a user or have a customer that needs that enabled? Now
> > > that issue is masked if I run the CVE checking tools , I will have a
> > > false sense of security.
> > > 
> > > I understand that Redhat or Suse can make statements like that  as they
> > > provide install-able  binaries but for a Project that starts from build
> > > your own DISTRO, should the community take on this responsibility?
> > This is the same as any of the other decisions we make for
> > CVE_CHECK_IGNORE. If you bbappend and/or change the configs of recipes,
> > you need to do some further due diligence.
> > 
> > The fact there isn't a PACKAGECONFIG for it at least suggests it isn't
> > being used.
> Maybe.

I did check and there is no recipe for jbig2-kit in the layer index
which is what tiff would use. 

> > What is the alternative? We just list this as unpatched for OE-Core and
> > let everyone have to look it up for themselves?
> 
> The first two ideas that come to mind are:
> 1) Make the PACKAGECONFIG = CVE # and a note in the recipe to provide a 
> clue.
> 2) Create some sort of frame work to warn if that pkg config is enabled.

I did document it in the recipe. The recipe name on the dependency the
PACKAGECONFIG would add will break as things stand too so I'd hope
someone would notice if they were trying to enable it.

Cheers,

Richard