From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, mikael(dot)kjellstrom(at)gmail(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~? |
Date: | 2024-04-15 05:04:12 |
Message-ID: | Zhy1TEzG7ivcQWp7@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 12, 2024 at 02:42:57PM +0200, Daniel Gustafsson wrote:
>> On 10 Apr 2024, at 09:31, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> 2. Move to 1.1.1. I understand this has to do with the fork-safety of pg_strong_random(), and it's not an API change but a behavior change. Let's make this association clearer in the code. For example, add a version check or assertion about this into pg_strong_random() itself.
> 0005 moves the fork safety init inline with calling pg_strong_random, and
> removes it for everyone else. This allows 1.1.0 to be supported as we
> effectively are at the 1.1.0 API level, at the cost of calls for strong random
> being slower on 1.1.0. An unscientific guess based on packaged OpenSSL
> versions and the EOL and ELS/LTS status of 1.1.0, is that the number of
> production installs of postgres 17 using OpenSSL 1.1.0 is close to zero.
It is only necessary to call RAND_poll once after forking. Wouldn't
it be OK to use a static flag and use the initialization once?
>> * src/port/pg_strong_random.c
>>
>> I would prefer to remove pg_strong_random_init() if it's no longer
>> useful. I mean, if we leave it as is, and we are not removing any
>> callers, then we are effectively continuing to support OpenSSL
>> <1.1.1, right?
>
> The attached removes pg_strong_random_init and instead calls it explicitly for
> 1.1.0 users by checking the OpenSSL version.
>
> Is the attached split in line with how you were thinking about it?
If I may, 0001 looks sensible here. The bits from 0003 and 0004 could
be applied before 0002, as well.
--- a/src/backend/postmaster/fork_process.c
+++ b/src/backend/postmaster/fork_process.c
@@ -110,9 +110,6 @@ fork_process(void)
close(fd);
}
}
-
- /* do post-fork initialization for random number generation */
- pg_strong_random_init();
Perhaps you intented this diff to be in 0005 rather than in 0002?
With 0002 applied, only support for 1.0.2 is removed, not 1.1.0 yet.
pg_strong_random(void *buf, size_t len)
{
int i;
+#if (OPENSSL_VERSION_NUMBER <= 0x10100000L)
+ /*
+ * Make sure processes do not share OpenSSL randomness state. This is not
+ * requred on LibreSSL and no longer required in OpenSSL 1.1.1 and later
+ * versions.
+ */
+ RAND_poll();
+#endif
s/requred/required/. Rather than calling always RAND_poll(), this
could use a static flag to call it only once when pg_strong_random is
called for the first time. I would not mind seeing this part entirely
gone with the removal of support for 1.1.0.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-04-15 05:19:40 | Re: wal_consistemcy_checking clean on HEAD |
Previous Message | jian he | 2024-04-15 05:03:30 | Re: sql/json remaining issue |