Search Postgresql Archives

Re: CVE-2024-10979 Vulnerability Impact on PostgreSQL 11.10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux