We do this probing in NSS because we can't guarantee that the softoken implementation matches the libssl implementation version. Yeah, strange world we live in, right?
The probe is a little ugly, because there isn't a straight function you can call that says "this algorithm is supported": This is where we filter out algorithms that we don't like: https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/sslgrp.c#76 If you trace this down, it basically ends up with the code that creates a key pair in that group: https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/ssl3ecc.c#439 As you say, conditioning on version is easy enough. On Thu, Feb 8, 2018 at 4:13 AM, Andrew Cagney <andrew.cag...@gmail.com> wrote: > On 7 February 2018 at 11:45, Andrew Cagney <andrew.cag...@gmail.com> wrote: >> On 7 February 2018 at 10:41, Franziskus Kiefer <fkie...@mozilla.com> wrote: >>> You should probably try to detect this at runtime. >>> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail >>> (or do something else) if it doesn't. > > If SEC_OID_CURVE25519 was a #define then a build time test would be > easy. Alas, it's an enum. > So without sucking in autoconf, is there some official proxy for this. > If all else fails there should be a version number in the header. > >>> At runtime you could try using SEC_OID_CURVE25519 (with your own define to >>> 355) and have a fallback if NSS gives you an error on using it. > > While NSS has what I'll loosely describe as its ABI guarantee and this > magic should work. I'd rather to not go there. > > I'm more comfortable with building against version X and only accept > version >=X at runtime. > > Andrew > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
