Date: Wed, 8 Jul 2026 19:15:47 +0200
From: Christoph Berg <myon@debian.org>
To: Diego <mrstephenamell@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: libpq: decouple the .pgpass lookup port from the connection port
Message-ID: <ak6FwxXWcBTvvpPo@msg.df7cb.de>
References: <001a6f1d-4adb-42b2-8bf6-44154ed0ab97@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <001a6f1d-4adb-42b2-8bf6-44154ed0ab97@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ak6FwxXWcBTvvpPo%40msg.df7cb.de>
Precedence: bulk

Re: Diego
> Why the port wildcard is not enough
> -----------------------------------
> 
> One can write the entry with a wildcard port:
> 
>     db.example.com:*:appdb:alice:secret
> and it does match the tunnel. But the wildcard over-matches: a single
> local forwarding port (say 54321, or even a fixed local port reused for
> several tunnels at different times) ends up matching every server reached
> through that port,

If you are giving the correct remote name to libpq, the rule won't
match several different hosts. If you don't care about that part, you
don't need anything extra and could just match on localhost:54321 (or
localhost:*).

> so the same password line can be applied to different
> servers. That is precisely the kind of "password sent to the wrong
> server" situation the 2018 host fix was trying to avoid. The wildcard
> trades safety for convenience; it is not a substitute for matching the
> real server port.

Don't use a wildcard, put :54321 in.

TBH I don't see why yet more connection parameters are required when
the problem is already solved by setting the hostname/hostaddr
correctly. (The part that remains when doing that can be avoided by
not reusing ports I think. You should do that anyway for general
sanity.)

>     - pgpassport / passfileport (it only affects the password file)

Is this proposal just a giant buildup for a "PG passport" joke? :)

Christoph