Re: [PoC] Federated Authn/z with OAUTHBEARER

On Wed, Mar 5, 2025 at 6:08 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> ktruss shows absolutely no syscall activity on the authorization
> server during the failing test, because Curl's talking to something
> else. sockstat confirms that I completely forgot to listen on IPv6 in
> the test server. Dual stack sockets only work from the IPv6
> direction...
>
> There must be some law of conservation of weirdness, where the
> strangest failure modes have the most boring explanations. I'll work
> on a fix.

Heh, wow, that was confusing :-) Actually I'm still confused (why
passing sometimes then?) but I'm sure all will become clear with your
patch...

> On Mon, Mar 3, 2025 at 8:11 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > I think that is telling us that a non-blocking socket can be in a
> > state that is not yet connected enough even to tell you its local
> > address? That is, connect() returns without having allocated a local
> > address, and does that part asynchronously too? I don't know what to
> > think about that yet...
>
> That is also really good to know, though. So that EINVAL message
> might, in the end, be completely unrelated to the bug? (Curl doesn't
> worry about the error, looks like, just prints it to the debug
> stream.)

Yeah. I wonder if it only happens if the connection is doomed to fail
already, or something. But I don't plan to dig further if it's
harmless (maybe curl shouldn't really do that, IDK).