crashes when connecting over TLS using OpenSSL v3.2

[cbortz]

Describe the bug

Commands such as psql and pg_dump crash when connecting with TLS using openssl v3.2+. The error is:

pg_dump: error: connection to server at "<REDACTED URL>" (<REDACTED IP>), port <REDACTED PORT> failed: FATAL:  no PostgreSQL user name specified in startup packet
connection to server at "<REDACTED URL>" (<REDACTED IP>), port <REDACTED PORT> failed: FATAL:  no PostgreSQL user name specified in startup packet
pg_dump(62804,0x1d7ef1000) malloc: *** error for object 0x2a: pointer being freed was not allocated
pg_dump(62804,0x1d7ef1000) malloc: *** set a breakpoint in malloc_error_break to debug

Steps to reproduce

1. Install openssl v3.2+ (using MacOS, I installed via homebrew)
2. Install postgres via asdf-postgres
3. attempt to connect to a secure postgres URL using a connection string with the username and password included in the URL

Expected behavior

A successful connection to the server (or a successful dump is using pg_dump)

Additional context

A temporary workaround is downgrading to openssl 3.1.x. I have personally confirmed that this works (but introduces some other issues).

The PostgreSQL package for Homebrew (MacOS) had a similar issue that they patched:

• Homebrew issue outlining the buggy behavior
• Pull request with the patches

There was also a thread on postgresql.org: SSL tests fail on OpenSSL v3.2.0

Their fix references compatibility issues with libpq as well.

[smashedtoatoms]

I deal with more issues with openssl on Mac for every project I maintain than any other technology. I postponed adding support for openssl for years on this library because of it. The fact that the errors being thrown are unallocated pointers not being freed does not give me high hopes that openssl 3.2 is ready for primetime. That release triggered a bunch of untested regressions that the Postgres team is working through.

I don't have a Mac right now, nor the time, to chase down patching random libpq memory issues caused by openssl and missed in Postgres regression tests. In that thread you posted, they still need to settle on a solution, but when they do, they will mainline it. I don't have the time to maintain a patch in the build until then. I'd recommend using 3.1 until they get it sorted out. If you want to submit a PR that manages a patched version of Postgres in this library, I would consider it. However, in my experience, managing patches like that becomes an incredibly time-consuming task that causes more problems than it fixes.

My apologies for not jumping right on this. It's 100% temporary problems with things outside of this library, and I don't want to shim this library to accommodate them unless they become permanent problems and we have no choice. I am going to keep this issue open and keep an eye on it though, and if it drags on, I'll have to figure something out. Sorry again. I feel bad for not being able to drop everything and work on this, but I just don't have the time.

[cbortz]

Hey @smashedtoatoms thanks for the thoughtful response.

I feel bad

Please don't; I totally get it! 😁 Thank you for the project, and your consideration. Cheers!

[smashedtoatoms]

Thanks @cbortz!

[IDDT]

Started getting the same error with psql on latest Arch Linux - failed: FATAL: no PostgreSQL user name specified in startup packet.

[smashedtoatoms]

Started getting the same error with psql on latest Arch Linux - failed: FATAL: no PostgreSQL user name specified in startup packet.

Why do you think this is related? Are you getting the same error, or the error you posted above, or both? Can you provide some more detail? I haven't seen the error you posted associated with this issue. I have seen that error message when the client isn't sending a username correctly. Can you verify that you're connecting correctly? My reason for pushing back on this is the error you provided is possibly a common Postgres usage issue involving nonexisting Postgres users that can be caused by any number of misconfigurations, not an openssl/build bug in Postgres, which is what this ticket is tracking. I don't want to conflate things unless it's another symptom of the same problem.

https://hatchjs.com/no-postgresql-user-name-specified-in-startup-packet/

[IDDT]

This is a valid concern, but I double checked the username and password. I assumed the error is the same from the details provided by the original poster. Distro-packaged psql connects without an issue. Attaching the full log for clarity.

[user@arch ~]$ pacman -Q openssl
openssl 3.2.0-1
[user@arch ~]$ asdf current postgres
postgres        16.1            /home/user/.tool-versions
[user@arch ~]$ PGPASSWORD=$REDSHIFT_PASS /home/user/.asdf/shims/psql --username=$REDSHIFT_USER --dbname=hal --host=127.0.0.1 --port 5439
psql: error: connection to server at "127.0.0.1", port 5439 failed: FATAL:  no PostgreSQL user name specified in startup packet
connection to server at "127.0.0.1", port 5439 failed: FATAL:  no PostgreSQL user name specified in startup packet
double free or corruption (out)
Aborted (core dumped)
[user@arch ~]$ PGPASSWORD=$REDSHIFT_PASS /bin/psql --username=$REDSHIFT_USER --dbname=hal --host=127.0.0.1 --port 5439
Null display is "(null)".
Line style is unicode.
Border style is 2.
psql (16.1, server 8.0.2)
WARNING: psql major version 16, server major version 8.0.
         Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, compression: off)
Type "help" for help.

hal=# \q

[smashedtoatoms]

Ahh, I see! Ok, thanks!

[cbortz]

@smashedtoatoms Just a heads up that Postgres versions 15.6 and 16.2 have been released and claims fixes for OpenSSL v3.2 compatibility.

Fix incompatibility with OpenSSL 3.2 (Tristan Partin, Bo Andreson)

I've had one co-worker verify this for 15.6

• https://www.postgresql.org/docs/release/15.6/
• https://www.postgresql.org/docs/release/16.2/

[smashedtoatoms]

Thanks for the heads up @cbortz