Do not match RFC 5114 groups without q as it is significant

[t8m]

This should fix the no-caching build failure on master.

[paulidale]

Repo is frozen which prevents merging.

[slontis]

I am happy for this to go in to fix the build, but it is really ignoring the original problem...
i.e the decoder was doing something different to the import/export.

I do not see why if you have a p and g that match RFC5114 you would not be able to fill in the q.
If you were using this in an exchange and the q was not provided then wouldnt it make sense to be able to fill it in.
For ffdhe this is actually required in TLS as it only transmits p,g. So the only way to validate is to assume that if there is no q then it is the named group. I dont see why the same logic does not apply to any dh named group?

[t8m]

In the first place I'd like to see the RFC5114 groups to die completely.

[slontis]

Yep I agree, but backwards compatibility is still there..

I have a PR coming with a one liner to fix the decoding issue..

basically a single call to

dh_cache_named_group(dh);

is required inside dh_cb() in dh_asn1.c

The dhx one calls set0_pqg() which sets the nid if it is a named group..
The dh one (where the ASN1 only contains p & g) doesnt set the nid..

So this was one of the case(s) where building q if you have p & g is correct.

[mattcaswell]

Pushed.