[Swan-dev] nss: Set NSS_PKCS11_2_0_COMPAT to ensure using the compat interface for now.
andrew.cagney at gmail.com
Tue May 12 01:12:53 UTC 2020
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
- 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
More information about the Swan-dev