pgBackrest Error : authentication method 10 not supported

On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:

Hello,

I am getting an error message " authentication method 10 not supported"
while trying to create stanza on postgres14 after upgrading postgres from
v.10 to Postgres v.14.

I am using pgbackrest version: v.43 and the scram-sha-256 for hba
authentication.

This sounds like your libpq is too old, and is not related to backrest
itself.

Make sure you have libpq of at least version 10 as well, and not just the
server. (Exact package name will of course depend on what distribution
you're on, which you didn't specify)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

I have pgbackrest v.43 installed on the same server where we are running
postgres v14.6 that is upgraded from postgres v.10.2

ls /opt/PostgreSQL-14/lib/

libecpg.a libecpg_compat.so.3.14 libpgcommon.a
libpgport_shlib.a libpgtypes.so.3.14 libpq.so.5.14
libecpg_compat.a libecpg.so libpgcommon_shlib.a
libpgtypes.a libpq.a pkgconfig
libecpg_compat.so libecpg.so.6 libpgfeutils.a
libpgtypes.so libpq.so postgresql
libecpg_compat.so.3 libecpg.so.6.14 libpgport.a
libpgtypes.so.3 libpq.so.5

Thanks,

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net> wrote:

On Thu, Feb 2, 2023 at 7:46 AM Daulat <daulat.dba@gmail.com> wrote:

I have pgbackrest v.43 installed on the same server where we are
running postgres v14.6 that is upgraded from postgres v.10.2

ls /opt/PostgreSQL-14/lib/

libecpg.a libecpg_compat.so.3.14 libpgcommon.a
libpgport_shlib.a libpgtypes.so.3.14 libpq.so.5.14
libecpg_compat.a libecpg.so libpgcommon_shlib.a
libpgtypes.a libpq.a pkgconfig
libecpg_compat.so libecpg.so.6 libpgfeutils.a
libpgtypes.so libpq.so postgresql
libecpg_compat.so.3 libecpg.so.6.14 libpgport.a
libpgtypes.so.3 libpq.so.5

You've still not said which distribution you've installed on, so it's hard
to say. But no distribution installs into /opt/ by default that I'm aware
of. My guess if you installed backrest from a different source than
wherever you installed your postgres from, and therefor it's using those
libraries. Perhaps backrest is using the actual default operating system
install, and your postgres is a non-standard one?

//Magnus

Thanks for your quick reply.

uname -a
.amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64
GNU/Linux

Postgres and pgBackrest installed from source

curl -LO
https://github.com/pgbackrest/pgbackrest/archive/release/2.43.tar.gz
wget https://ftp.postgresql.org/pub/source/v14.6/postgresql-14.6.tar.gz

Thanks

On Thu, Feb 2, 2023 at 2:57 PM Magnus Hagander <magnus@hagander.net> wrote:

Confidential

Hello All

We are testing a upgrade from pg11 to pg14 and have some issues to overcome. One of these is that we have upgraded pgsodium to the latest and there is a functional change - this question is not about sodium BTW.

So here is a sample bit of code that I will use to explain the issue - this would usually be params passed in, but I have hard coded one particular case that does not need the decryption. The code below would return decrypted data if the key is supplied (non 0) otherwise return null. This code used to work because the secret box call would allow null params. It no longer does. When the key is 0, the data passed in would be null.

LEFT JOIN lateral (
SELECT
CASE
WHEN (0 > 0) THEN
convert_from(crypto_secretbox_open, 'utf8')::JSON
ELSE
NULL
END AS edata
FROM
crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)
where (0>0)
) enc ON true

The issue is that, even when the key is 0, the select is still run (its part of a lateral join) and what we need to achieve is to effectively have a conditional where we only run the select if the key > 0 otherwise we return null - I have a brain freeze on this! I am sure there is an easy solution, but right now I can't see it.

Thx in advance

Z

On Thu, Feb 2, 2023 at 12:38 PM Daulat <daulat.dba@gmail.com> wrote:

Thanks for your quick reply.

uname -a
.amzn1.x86_64 #1 SMP Sun Nov 27 06:09:45 UTC 2022 x86_64 x86_64 x86_64
GNU/Linux

Postgres and pgBackrest installed from source

curl -LO
https://github.com/pgbackrest/pgbackrest/archive/release/2.43.tar.gz
wget https://ftp.postgresql.org/pub/source/v14.6/postgresql-14.6.tar.gz

If you install from source, you have to manually configure our backrest
install to use the libraries from your manual installed postgres. By
default it will use the libraries that are part of your distribution, which
clearly are not updated. You'll be able to see that by running ldd on the
pgbackrest binary, you'll see how it uses the system libpq.9

IIRC, but not verified, in meson you can do that by setting LIBRARY_PATH
before you configure it.

//Magnus

On Thu, Feb 2, 2023 at 2:57 PM Magnus Hagander <magnus@hagander.net>
wrote:

On Thu, Feb 2, 2023 at 7:46 AM Daulat <daulat.dba@gmail.com> wrote:

I have pgbackrest v.43 installed on the same server where we are
running postgres v14.6 that is upgraded from postgres v.10.2

ls /opt/PostgreSQL-14/lib/

libecpg.a libecpg_compat.so.3.14 libpgcommon.a
libpgport_shlib.a libpgtypes.so.3.14 libpq.so.5.14
libecpg_compat.a libecpg.so libpgcommon_shlib.a
libpgtypes.a libpq.a pkgconfig
libecpg_compat.so libecpg.so.6 libpgfeutils.a
libpgtypes.so libpq.so postgresql
libecpg_compat.so.3 libecpg.so.6.14 libpgport.a
libpgtypes.so.3 libpq.so.5

You've still not said which distribution you've installed on, so it's
hard to say. But no distribution installs into /opt/ by default that I'm
aware of. My guess if you installed backrest from a different source than
wherever you installed your postgres from, and therefor it's using those
libraries. Perhaps backrest is using the actual default operating system
install, and your postgres is a non-standard one?

//Magnus

On Tue, Jan 31, 2023 at 7:32 PM Magnus Hagander <magnus@hagander.net>
wrote:

On Tue, Jan 31, 2023 at 2:58 PM Daulat <daulat.dba@gmail.com> wrote:

Hello,

I am getting an error message " authentication method 10 not
supported" while trying to create stanza on postgres14 after upgrading
postgres from v.10 to Postgres v.14.

I am using pgbackrest version: v.43 and the scram-sha-256 for hba
authentication.

This sounds like your libpq is too old, and is not related to backrest
itself.

Make sure you have libpq of at least version 10 as well, and not just
the server. (Exact package name will of course depend on what distribution
you're on, which you didn't specify)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 02/02/2023 13:54 CET Zahir Lalani <zahirlalani@oliver.agency> wrote:

Confidential

Hello All

We are testing a upgrade from pg11 to pg14 and have some issues to overcome.
One of these is that we have upgraded pgsodium to the latest and there is a
functional change – this question is not about sodium BTW.

So here is a sample bit of code that I will use to explain the issue – this
would usually be params passed in, but I have hard coded one particular case
that does not need the decryption. The code below would return decrypted data
if the key is supplied (non 0) otherwise return null. This code used to work
because the secret box call would allow null params. It no longer does. When
the key is 0, the data passed in would be null.

LEFT JOIN lateral (
SELECT
CASE
WHEN (0 > 0) THEN
convert_from(crypto_secretbox_open, 'utf8')::JSON
ELSE
NULL
END AS edata
FROM
crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)
where (0>0)
) enc ON true

The issue is that, even when the key is 0, the select is still run (its part
of a lateral join) and what we need to achieve is to effectively have a
conditional where we only run the select if the key > 0 otherwise we return
null – I have a brain freeze on this! I am sure there is an easy solution,
but right now I can’t see it.

Looks similar to a post from a few days ago:
/messages/by-id/CAALojA-nHoxDr7B2k0e1-EtGMPsGPZiCVeS_ds0aHG0SEOrPxg@mail.gmail.com

I don't know pgsodium but the query optimizer will evalute crypto_secretbox_open
if the function is immutable and is called with constant arguments.

How is the key and the data passed to this query? Is it a prepared statement or
is the query generated on the fly for specific key and data that is already
known? In the latter case you can handle the case expression with two different
queries (one with crypto_secret_box and one without) depending on whether a key
exists or not.

--
Erik

PS: Please don't hijack threads on this mailing list.

Zahir Lalani <ZahirLalani@oliver.agency> writes:

LEFT JOIN lateral (
SELECT
CASE
WHEN (0 > 0) THEN
convert_from(crypto_secretbox_open, 'utf8')::JSON
ELSE
NULL
END AS edata
FROM
crypto_secretbox_open(coalesce(null, '')::bytea, coalesce(null, '')::bytea,0)
where (0>0)
) enc ON true

The issue is that, even when the key is 0, the select is still run (its part of a lateral join) and what we need to achieve is to effectively have a conditional where we only run the select if the key > 0 otherwise we return null - I have a brain freeze on this! I am sure there is an easy solution, but right now I can't see it.

Is crypto_secretbox_open marked IMMUTABLE? I think recent PG versions
are capable of folding this all to a constant if so, whereas older
ones might not have. If you care about when/whether crypto_secretbox_open
runs, then it must have side-effects, so it shouldn't be IMMUTABLE.

regards, tom lane