I wrote:
> Yeah, I see that too. But I also see three failures in 002_scram.pl,
> which presumably were there before e0f373ee. (Tested on OpenBSD 7.6
> and 7.7.) The buildfarm's OpenBSD animals haven't caught this
> because they don't run this test suite :-(.
I dug into this with gdb, and it seems like it's an omission in
LibreSSL's RSA-PSS support. We're requesting a signature algorithm
with code 2054, which in their source is SIGALG_RSA_PSS_RSAE_SHA512,
and that leads them to this sigalgs[] table entry in
lib/libssl/ssl_sigalgs.c:
{
.value = SIGALG_RSA_PSS_RSAE_SHA512,
.key_type = EVP_PKEY_RSA,
.md = EVP_sha512,
.security_level = 5,
.flags = SIGALG_FLAG_RSA_PSS,
},
The problem is that the private key has key_type EVP_PKEY_RSA_PSS
which is not equal to EVP_PKEY_RSA, so ssl_sigalg_pkey_ok() in the
same file rejects this entry as not compatible. In fact, there
are *no* entries in sigalgs[] that can match a PSS private key
according to ssl_sigalg_pkey_ok(). So while perhaps
SIGALG_RSA_PSS_RSAE_SHA512 is the wrong thing for us to request,
I do not see a right thing.
Looking around a little more, there are places like
SSL_get_signature_type_nid() that do things like this:
*nid = sigalg->key_type;
if (sigalg->key_type == EVP_PKEY_RSA &&
(sigalg->flags & SIGALG_FLAG_RSA_PSS))
*nid = EVP_PKEY_RSA_PSS;
So it seems like this might be a simple oversight in
ssl_sigalg_pkey_ok(), which doesn't make any such correction:
if (sigalg->key_type != EVP_PKEY_id(pkey))
return 0;
Anyone know anything about where to submit LibreSSL bugs?
regards, tom lane
