[Swan-dev] nss: Set NSS_PKCS11_2_0_COMPAT to ensure using the compat interface for now.

[Andrew Cagney]

EWWW NSS EWWWW,
I've a fuzzy memory that GCM_PARAMS was broken once before ...

Can I suggest:
- moving the #define to lib/libswan/ike_alg_encrypt_nss_gcm_ops.c
before any includes - since that is the only file that uses
CK_GCM_PARAMS
- try pointing the AES_GCM code at
lib/libswan/ike_alg_encrypt_nss_aead_ops.c; it might just drop in ...

On Mon, 11 May 2020 at 20:34, Paul Wouters <paul at vault.libreswan.fi> wrote:
>
> New commits:
> commit 65a497959a0e1ca615341109eaad5e75723839d6
> Author: Paul Wouters <pwouters at redhat.com>
> Date:   Mon May 11 20:29:19 2020 -0400
>
>     nss: Set NSS_PKCS11_2_0_COMPAT to ensure using the compat interface for now.
>
>     This might resolve the issue seen in https://github.com/libreswan/libreswan/issues/334
>
>     As per conversation with Bob:
>
>         The issue is building with nss 3.52, If you build with 3.51 and run with
>         3.52 you won't run into the issue.  It's the default for the definition
>         of CK_GCM_PARAMS. The spec and the released headers were different from
>         OASIS. In that case, the header is authoritative and we used the spec NSS
>         needs to move the new definition, but doing so will break things that
>         compile with NSS. To get around it you can add -DNSS_PKCS11_2_0_COMPAT
>         or include it in your .c file
>
>         Long term, you'll actually want to move the the AEAD interface.
>         There's a new PKCS #11 interface that allows you to operate multiple AEAD
>         operations on a single key. It allows token IV generation. I added new
>         wrappers in 3.52 to handle the differences between tokens and mechanism