Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10 - Mailing list pgsql-general

On 11/22/24 10:00, Matthias Apitz wrote:
> El día viernes, noviembre 22, 2024 a las 05:52:34 +0100, Laurenz Albe escribió:
>
>> On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote:
>>> Currently, my environment is running PostgreSQL 15.0. I understand that version
>>> 15.9 contains the fix for CVE-2024-10979, as mentioned in the release notes.
>>> Given that I am not using the PL/Perl extension in my environment, I wanted to ask:
>>>   * Is it still mandatory to upgrade specifically to version 15.9, or would
>>>     remaining on version 15.0 suffice in this case?
>>> I appreciate your guidance on whether this upgrade is necessary, considering the
>>> specifics of my setup.
>> If you don't use PL/Perl, you are not affected by that security vulnerability.
>>
>> I wonder what you mean by "mandatory".
>>
>> We won't fine or punish you if you don't update PostgreSQL, but perhaps it
>> would make your employer unhappy.  If you stay on 15.0, you will be subject to
>> thirteen other security vulnerabilities (if I counted right), and you may end
>> up with corrupted GIN and BRIN indexes.  Additionally, you will be subject to
>> countless known bugs that have been fixed since.
>>
>> You should *always* update to the latest minor release shortly after it is
>> released.  Everything else is negligent.
> Laurenz, et all,
>
> The company I'm working for is producer of a Library Management System
> with C/C++ written servers on Linux, using ESQL/C and DBI interfaces of
> PostgreSQL (and older version Sybase too) and the software is deployed
> to 100++ customer installations, sometimes with limited own IT know how.
>
> "You should *always* update ..." is nice to say, but in the described land
> not easy to do. For the two released versions of our software (V7.2 and
> V7.3) and the current version in development (V7.3-SP1) we plan the
> following migrations of the server and client side of PostgreSQL:
>
> under development: V7.3-SP1 (we will not support 15.9 as cluster in SP1)
>      used ESQL/C 15.9 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      15.1  --> 16.5
>      16.2  --> 16.5
>
> released: V7.3 (we will not support 15.9 as cluster in V7.3)
>      used ESQL/C 15.1 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      15.1  --> 16.5
>      16.2  --> 16.5
>
> released: V7.2 (we will not support 15.9 as cluster in V7.2)
>      used ESQL/C 11.4 (i.e. PostgreSQL client side)
>      migrate the used cluster/database 'from' --> 'to'
>      13.1  --> 16.5
>      16.2  --> 16.5

Why not decouple client libs from the server ? i.e. psql works great 
with many versions greater than its own. And certainly with same major 
versions. You could retain the same client libs and just upgrade the 
PgSQL server to the highest minor version of the major version that you 
support.

Granted, I am coming from JDBC/psql land but still those restrictions 
above just seem too much.

Of course SQL correctness from version to version (such as "trailing 
junk", standard_conforming_strings, etc ..) and performance are tasks 
that has to be done, you can't skip those. But IMHO the server version 
in the general case is independent or should be independent from the 
app. We recently migrated from 10.23 -> 16.4 with slight bruises (almost 
6+ months preparation by me and 3-4 months preparation from the dept team).

Just my 5 cents.

>
> Especially the version V7.2 (released in 2021) can't be updated on the
> client side, the cluster will be migrated to 16.5. I assume that
> CVE-2024-10979 affects the server side, and not the client side.
>
> Any further comments on this?
>
> Thanks
>
>     matthias
>