On 11/20/24 9:18 PM, Bruce Momjian wrote:
> On Fri, Nov 15, 2024 at 06:28:42PM -0500, Jonathan Katz wrote:
>> We're scheduling an out-of-cycle release on November 21, 2024 to address two
>> regressions that were released as part of the November 14, 2024 update
>> release[1]. As part of this release, we will issue fixes for all supported
>> versions (17.2, 16.6, 15.10, 14.15, 13.20), and for 12.22, even though
>> PostgreSQL 12 is now EOL.
>>
>> A high-level description of the regressions are as follows.
>>
>> 1. The fix for CVE-2024-10978 prevented `ALTER USER ... SET ROLE ...` from
>> having any effect[2]. This will be fixed in the upcoming release.
>>
>> 2. Certain PostgreSQL extensions took a dependency on an Application Build
>> Interface (ABI) that was modified in this release and caused them to
>> break[3]. Currently, this can be mitigated by rebuilding the extensions
>> against the updated definition.
>>
>> Please follow all standard guidelines for commits ahead of the release.
>> Thanks for your help in assisting with this release,
>
> I want to point out a complexity of this out-of-cycle release. Our
> 17.1, etc. releases had four CVEs:
>
> https://www.postgresql.org/message-id/173159332163.1547975.13346191756810493274@wrigleys.postgresql.org
>
> so when we decided to remove the downloads and encourage people to wait
> for the 17.2 etc. releases, we had the known CVEs in Postgres releases
> with no recommended way to fix them.
>
> I am not sure what we could have done differently, but I am surprised we
> didn't get more complaints about the security situation we put them in.
The announcement[1] specified the issues and advised waiting if users
were impacted by them directly (and tried to be as specific as possible)
and gave guidance to prevent help users avoid upgrading and then ending
up in a situation where they're broken, regardless if they're impacted
by the CVE or not (e.g. they don't have PL/Perl installed).
That said, while it's certainly advisable to upgrade based on having
CVEs in a release, many upgrade patterns are determined by the CVE
score[2]. For example, a HIGH score (7.0 - 8.9 - our highest for this
release was 8.8; 3 of them were less than 5.0) often dictates upgrading
within 14-30 days of announcing the CVE, and lower scores having more
time. This could be why people didn't complain, particularly because we
got the announcement out 36 hours after the release, and stated the
updates would be available within the next week.
Thanks,
Jonathan
[1]
https://www.postgresql.org/about/news/out-of-cycle-release-scheduled-for-november-21-2024-2958/
[2] https://www.first.org/cvss/v3.1/specification-document
