How to handle postgresql82-client vulnerability

[Amitabh Kant]

On Fri, Apr 13, 2012 at 5:41 PM, Matthew Seaman <matthew at freebsd.org> wrote:

> On 13/04/2012 12:23, Carmel wrote:
> > I am working on an older machine that has "postgresql-client-8.2.23"
> > installed. I have the following information regarding the program:
> >
> > $ pkg_info -R postgresql-client-8.2.23
> > Information for postgresql-client-8.2.23:
> >
> > Required by:
> > koffice-kde4-2.3.3_7
> > postgresql-libpqxx-3.0.2
> >
> > Attempting to build the program produces this error:
> >
> > ===>  postgresql-client-8.2.23 is forbidden: Vulnerable
> http://www.postgresql.org/about/news/1377/.
> > *** Error code 1
> >
> > Stop in /usr/ports/databases/postgresql82-client.
>
> postgresql-8.2 is out of support upstream.  It's only still in the ports
> because no one has realised it's past its expiry date and removed it yet.
>
> Given the unfixed security problems, you should upgrade to a newer
> version ASAP.
>
> > I cannot find anything in the UPDATING or MOVED files that details how
> > to deal with this. Would something like:
> >
> >       portupgrade -o databases/postgresql90-client postgresql82-client
> >
> > be the proper way to handle this problem? Would I then have to rebuild
> > koffice-kde4-2.3.3_7 and postgresql-libpqxx-3.0.2 to insure that
> everything works correctly?
>
> Correct, as far as dealing with the ports goes.  Yes, you will have to
> recompile anything that links against libpq.so.X, which is probably more
> than shows up in the output of 'pkg_info -R' -- you can use the lib_chk
> script from bsdadminscripts to find everything that needs to be rebuilt.
>  Or just 'portmaster -r databases/postgresql90-client'
>
> However, there is no guarantee that you can just start up postgresql90
> and expect it to work with the postgresql82 data directory. (Although
> why not postgresql91 rather than 90? There's no good reason not to use
> the latest release.)
>
> As the ports don't support installing several versions of postgresql
> simultaneously, or encode the postgres version into the PGDATA path
> (which is a fairly standard approach on various other unixoid
> environments) you won't be able to use pg_upgrade easily.
>
> Given that in-place updates are not feasible, you should dump the
> contents of your database cluster and then reload it into a newly
> created cluster using the latest version.  The PG documentation
> recommends using the client from the version you are updating to for
> creating the dumps, or else they may not reload cleanly.  In fact, there
> are changes between 8.x and 9.0 to do with the encoding of non-ascii
> character data which are quite likely to cause difficulties for you.
> Note that you can install an updated client on a different box and dump
> remotely as a relatively simple way of using a new client to access an
> older DB.
>
> Ideally you should create a brand new DB cluster on a separate system,
> so you can have as many goes at pulling the data over from your original
> database as you need to get it right without destroying the originals.
> If you lack the resources to do that, then better make sure you've got
> good backups.
>
>        Cheers,
>
>        Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil.
> PGP: http://www.infracaninophile.co.uk/pgpkey
>
>
 You will have to perform a dump & restore to move from 8.2.x to 9.0.x
(might as well move up to 9.1.x). The data directory compatibility is
not guaranteed across major version.

Amitabh