[meta-security,kirkstone,v2] tpm2-tss: upgrade to 3.2.2 to fix CVE-2023-22745

Changelog:
  3.2.2
    A buffer overflow in tss2-rc as CVE-2023-22745.
    The drv layer in tss2-rc should have been the policy layer.
    Spec deviation in Fapi_GetDescription caused description to be NULL when it should be empty string.
    This is API breaking but considered a bug since it deviated from the FAPI spec.
    FAPI: undefined reference to curl_url_strerror when using curl less than 7.80.0.
  3.2.1
    Makefile.am: make all EXTRA_DIST includes unconditional to fix pristine tars
    Fix usage of NULL pointer if Esys_TR_SetAuth is calles with ESYS_TR_NONE.
    Store VERSION into the release tarball.
    fapi: fix usage of policy_nv with a TPM nv index.
    Tss2_Sys_Flushcontext: flushHandle was encoded as a handleArea handle and not as parameter one, this affected the contents of cpHash.
    linking tcti for libtpms against tss2-tctildr. It should be linked against tss2-mu.
    build: Remove erroneous trailing comma in linker option. Bug #2391.
    esys: fix allow usage of HMAC sessions for Esys_TR_FromTPMPublic.
    test: build with opaque FILE structure like in musl libc.
    Usage of a second profile in a path was not possible because the default profile was always used.
    FAPI: Fix provisioning if auth value for storage hierarchy was set.
    FAPI: Fix recreation of EK.
    FAPI: Fix usage of lockout auth value in Fapi_Provison.
    FAPI: Fix loading of key in policy execution.
    FAPI: Fix Fapi_ChangeAuth updates on hierarchy objects not being reflected across profiles.
    Esys_PCR_SetAuthValue: remembers the auth like other SetAutg ESAPI functions.
    tests: esys-pcr-auth-value.int moved to destructive tests.
    FAPI: Fix double free if keystore is corrupted.
    Spec deviation in Fapi_GetDescription caused description to be NULL when it should be empty string.
        This is API breaking but considered a bug since it deviated from the FAPI spec.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../tpm2-tss/{tpm2-tss_3.2.0.bb => tpm2-tss_3.2.2.bb}  | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
 rename meta-tpm/recipes-tpm2/tpm2-tss/{tpm2-tss_3.2.0.bb => tpm2-tss_3.2.2.bb} (91%)

Hi Peter

On 08.05.23 at 16:50, Peter Marko via lists.yoctoproject.org wrote:
> Changelog:
>    3.2.2
>      A buffer overflow in tss2-rc as CVE-2023-22745.
>      The drv layer in tss2-rc should have been the policy layer.
>      Spec deviation in Fapi_GetDescription caused description to be NULL when it should be empty string.
>      This is API breaking but considered a bug since it deviated from the FAPI spec.
>      FAPI: undefined reference to curl_url_strerror when using curl less than 7.80.0.
>    3.2.1
>      Makefile.am: make all EXTRA_DIST includes unconditional to fix pristine tars
>      Fix usage of NULL pointer if Esys_TR_SetAuth is calles with ESYS_TR_NONE.
>      Store VERSION into the release tarball.
>      fapi: fix usage of policy_nv with a TPM nv index.
>      Tss2_Sys_Flushcontext: flushHandle was encoded as a handleArea handle and not as parameter one, this affected the contents of cpHash.
>      linking tcti for libtpms against tss2-tctildr. It should be linked against tss2-mu.
>      build: Remove erroneous trailing comma in linker option. Bug #2391.
>      esys: fix allow usage of HMAC sessions for Esys_TR_FromTPMPublic.
>      test: build with opaque FILE structure like in musl libc.
>      Usage of a second profile in a path was not possible because the default profile was always used.
>      FAPI: Fix provisioning if auth value for storage hierarchy was set.
>      FAPI: Fix recreation of EK.
>      FAPI: Fix usage of lockout auth value in Fapi_Provison.
>      FAPI: Fix loading of key in policy execution.
>      FAPI: Fix Fapi_ChangeAuth updates on hierarchy objects not being reflected across profiles.
>      Esys_PCR_SetAuthValue: remembers the auth like other SetAutg ESAPI functions.
>      tests: esys-pcr-auth-value.int moved to destructive tests.
>      FAPI: Fix double free if keystore is corrupted.
>      Spec deviation in Fapi_GetDescription caused description to be NULL when it should be empty string.
>          This is API breaking but considered a bug since it deviated from the FAPI spec.
>
> Signed-off-by: Peter Marko <peter.marko@siemens.com>


Thanks for the patch!
However, we'd need you to add one thing to your git configuration, so 
that your patches are given an "Author" field which matches your 
"Signed-off-by" information. See 
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Fixing_your_From_identity 
for details.

Don't hesitate to send a patch test directly to me, if you wish.
Thanks again,
Michael.

Hi Michael,

Unfortunately, my corporate email server does not support me in this.
I have sent you a test email after explicitly configuring this in git, but I think it won't do anything better.
Last patch to yocto mailing list had to be sent by my colleague as the server has bounced it.
https://lists.yoctoproject.org/g/yocto/message/59488
Now it seems to accepts it with wrong "From:" field, not sure what has changed meanwhile.

Very interesting is that I have sent dozens of patches to meta-oe or oe-core without issue, just the yocto mailing list is broken for me.
I'm hoping you can accept the patch also like this, otherwise I can again ask Andrej to send it for me.

Sorry for the trouble,
  Peter

-----Original Message-----
From: Michael Opdenacker <michael.opdenacker@bootlin.com> 
Sent: Tuesday, May 9, 2023 9:53
To: Marko, Peter (ADV D EU SK BFS1) <Peter.Marko@siemens.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] [meta-security][kirkstone][PATCH v2] tpm2-tss: upgrade to 3.2.2 to fix CVE-2023-22745

> Thanks for the patch!
> However, we'd need you to add one thing to your git configuration, so that your patches are given an "Author" field which matches your "Signed-off-by" information. See https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Fixing_your_From_identity
for details.
>
> Don't hesitate to send a patch test directly to me, if you wish.
> Thanks again,
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

Hi Peter,

Thanks for your efforts.

On 09.05.23 at 10:33, Marko, Peter wrote:
> Hi Michael,
>
> Unfortunately, my corporate email server does not support me in this.
> I have sent you a test email after explicitly configuring this in git, but I think it won't do anything better.
> Last patch to yocto mailing list had to be sent by my colleague as the server has bounced it.
> https://lists.yoctoproject.org/g/yocto/message/59488
> Now it seems to accepts it with wrong "From:" field, not sure what has changed meanwhile.


Oops, that's bad if your server refuses a custom "From:" field, because 
that's the workaround we're using.

The test message you sent to me didn't have an additional "From:" field 
at the beginning of the body, which is what git can use to get a correct 
"Author" field.

>
> Very interesting is that I have sent dozens of patches to meta-oe or oe-core without issue, just the yocto mailing list is broken for me.


I see this. Previously, your message didn't have "via 
lists.yoctoproject.org". It could be that your corporate server turned 
on DMARC recently.

> I'm hoping you can accept the patch also like this, otherwise I can again ask Andrej to send it for me.


Well, Andrej seems to have the same problem too :}
I guess that's it's more important to let you send your own patches. 
It's just that our busy maintainer will have to manually edit the author 
field in your commits.

Cheers
Michael.