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 <[email protected]> wrote: > > New commits: > commit 65a497959a0e1ca615341109eaad5e75723839d6 > Author: Paul Wouters <[email protected]> > 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
