Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uCTQS-00FZW6-1F for pgsql-hackers@arkaria.postgresql.org; Wed, 07 May 2025 01:18:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uCTQR-00Ancp-41 for pgsql-hackers@arkaria.postgresql.org; Wed, 07 May 2025 01:18:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uCTQQ-00Ancf-QC for pgsql-hackers@lists.postgresql.org; Wed, 07 May 2025 01:18:18 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uCTQO-000Vc2-0G for pgsql-hackers@postgresql.org; Wed, 07 May 2025 01:18:17 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5471IBVM3227093; Tue, 6 May 2025 21:18:11 -0400 From: Tom Lane To: Thomas Munro cc: Andrew Dunstan , PostgreSQL-development , Jacob Champion Subject: Re: disabled SSL log_like tests In-reply-to: <3058990.1746485124@sss.pgh.pa.us> References: <984fca80-85a8-4c6f-a5cc-bb860950b435@dunslane.net> <2199758.1744901785@sss.pgh.pa.us> <1ce11d3f-624c-4003-a032-1b10cc138305@dunslane.net> <2814408.1745005558@sss.pgh.pa.us> <2859105.1745015195@sss.pgh.pa.us> <1120735.1745350422@sss.pgh.pa.us> <3058990.1746485124@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 05 May 2025 18:45:24 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3227091.1746580691.1@sss.pgh.pa.us> Date: Tue, 06 May 2025 21:18:11 -0400 Message-ID: <3227092.1746580691@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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