upgrade to netbox 3.10 - failure to connect to postgreSQL

[jcralbino]

Hello Team,

I have seen an issue during an upgrade process from 3.0.9 to 3.0.10.

As in 3.0.10 the psycopg2-binary v2.9.2 is introduced an error connecting to the postgreSQL

Downgrading this to psycopg2-binary v2.9.1 solved the issue in the
release details
i see this:

• Wheel package compiled against OpenSSL 1.1.1l and PostgreSQL 14.1 (ticket Query server error: cannot switch EUI versions using copy constructor #1388).

Has this been an issue seen by other also?

[candlerb]

I am running netbox 3.0.10, on Ubuntu 20.04, python 3.8, openssl 1.1.1f, and with postgres 12.9 (all standard out-of-box)

root@netbox3:~# cd /opt/netbox
root@netbox3:/opt/netbox# . venv/bin/activate
(venv) root@netbox3:/opt/netbox# pip list | grep psyco
psycopg2-binary               2.9.2
(venv) root@netbox3:/opt/netbox#

I don't see any problem with this version of psycopg2.

What is it that you do that causes the problem? What exact error do you see? What OS are you on?

[candlerb]

ISTM that if you're in an environment that requires FIPS, then enabling MD5 is not a great idea. Did you find Netbox requires MD5 for some other reason apart from Postgres login? If MD5 is being used for postgres authentication, it's clearly being "used for security".

Fortunately, Postgres 10+ supports scram-sha-256 which you can use instead of md5.

Netbox 3.1 will require a minimum of postgres 10, so at that point it would make sense to update the documentation to show this instead of md5 auth. Of course you can switch now, as long as your postgres server is 10 or later.

[candlerb]

BTW, I just upgraded my home system to scram-sha-256 to ensure this works, and it does. Useful blog here.

[amk1969]

The use of MD5 in django is for caching, not security. There I have it enabled. Could it happen that psycopg2-binary 2.9.2 would make use of a cipher/hash that is not allowed by FIPS while version 2.9.1 does not have any issue?

The server is new installed version 13.3 but I took some settings from former one so will have to check what is setup there. Thanks for the useful pointer. The server has also FIPS enabled so I would assume no one should be able to connect with MD5. Is it possible that postgres library before version 14 does not obey FIPS?

[candlerb]

Could it happen that psycopg2-binary 2.9.2 would make use of a cipher/hash that is not allowed by FIPS while version 2.9.1 does not have any issue?

I was thinking the other way round: that your 2.9.2 didn't allow MD5 while your 2.9.1 does. However, it's just speculation, since I don't know really what's different between 2.9.1 and 2.9.2 on your system. 2.9.2 works fine for me, with md5 auth as well as scram-sha-256.

I don't imagine the postgres library knows anything about FIPS. That is, I think it would be up to someone to release a FIPS-certified postgres client library, if there were such a thing.

[amk1969]

The difference between 2.9.1 and 2.9.2 on all systems is bump of Openssl version as well as postgres client version. I find it is possible that one of them would add FIPS support, leading to no MD5 anymore. Still I would expect something relevant logged except "error sending password". I will know more tomorrow once I have a look at the sql server.

[amk1969]

It is confirmed that the MD5 hashing at the server side was the culprit. After changing to scram-sha-256 as suggested by user candlerb
yesterday the connection works also with recent version of psycopg2. It is the postgres library version 14 inside psycopg2 that brought FIPS support to the client: https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.6.5

Thanks for all help.