Re: how do I test if NSS supports an algorithm at build time?

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 <[email protected]> wrote:
> On 7 February 2018 at 11:45, Andrew Cagney <[email protected]> wrote:
>> On 7 February 2018 at 10:41, Franziskus Kiefer <[email protected]> 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
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto