Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1reg9p-00CmwO-Iq for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Feb 2024 18:56:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1reg9n-00G1NO-J4 for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Feb 2024 18:56:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1reg9n-00G1NF-96 for pgsql-hackers@lists.postgresql.org; Mon, 26 Feb 2024 18:56:55 +0000 Received: from mail-qv1-xf32.google.com ([2607:f8b0:4864:20::f32]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1reg9k-001ETw-IC for pgsql-hackers@lists.postgresql.org; Mon, 26 Feb 2024 18:56:54 +0000 Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-68fff2b2984so9158636d6.2 for ; Mon, 26 Feb 2024 10:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1708973810; x=1709578610; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=M3hQG0gFSxO/rV8/apxsAMI07Wbpqe2XvAE6bOHoPIg=; b=L3Uj97Fcvdzv3nkcxEzds4YvJn+4QHip2C8ZPqnkXzKEFELuW9SGa/sjit2c2EEXsQ xuhabIx+l8jeEG8WQHA3ZJgfslfIGc/5HPq8x3CGytNHbYlG7U49HDT01i2V19v5FhaZ a8MAw/Ob5IoIIzvETaN+6kZz2LH6qzCuGpns+unk6yugZpeJMUHuKp97n/A2HUqpGl04 nZCqZ1qh9YTbQv1bfzWDdwhmC81H/Xz07FiaONw7VYigeEMZRdlJV7QsaYKkEzfig8KX tuYaYTEfIAwqsQQqD4RyJ3empixgxT7ShzjGY+TGpYlWj0vOX2VjEFkQAnj0j/5naP2j alFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708973810; x=1709578610; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=M3hQG0gFSxO/rV8/apxsAMI07Wbpqe2XvAE6bOHoPIg=; b=fy/YR7YHXQI2tck2u1Lp/d+fnSRrhjtfujOVEXF6q1jUVPgXpiRX/I6S33TkNfWmy6 sJJTbO9W5+iSniMQ4cNFrwbtR/jnZaRs+8CVWCMr1PO+9BpvpOSm21XMjQVcxRpXjSWH JUEfrbmHjMtZaqIC1TL+8XMJAbR2c/kkLb7zSoxX8guBO1n+7dckvBTVwO6hkoB0lSNZ hjvgEAS3tJ1sNMYJ8rLbHRAvYgcnNMNjO7PBY87mdtqM3oghluQPnf/y+mOqNE/kC2X/ PZNImONaGox55QexPJza2dyVS/WRwgus3xf/aqbau7oM1Xc6RXoGSVQjOLxHmEqrlXFS YkZg== X-Gm-Message-State: AOJu0YwZs6xIym3hAwCDu32fslh6PwGUEdGHHrCnuOQ++AcAy4KW87L5 nupO7afcFLgKLqq56PPS87BpMS32s0dCXoiGcT6IwDx5X8gecU6K0U/9gtFfyN0o0S3B/xHywbP NDSFSY1rd5jElxgc7ebwhixZhtyZrbNCuQpb7gXT3GdZCBFxWUcyn X-Google-Smtp-Source: AGHT+IGMBm8MnSBmGcW3YeOJDWLxpDQS7jiRLX9ypP3IhF8L1GFrKUmL2erNYZ3BmPykKerHC8JKieoTmnMbPzSRKBQ= X-Received: by 2002:a05:6214:301c:b0:68d:129e:f5c1 with SMTP id ke28-20020a056214301c00b0068d129ef5c1mr9815729qvb.45.1708973810530; Mon, 26 Feb 2024 10:56:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jacob Champion Date: Mon, 26 Feb 2024 10:56:39 -0800 Message-ID: Subject: Re: Refactor SASL exchange in preparation for OAuth Bearer To: Daniel Gustafsson Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Feb 23, 2024 at 2:30=E2=80=AFAM Daniel Gustafsson = wrote: > > The attached two patches are smaller refactorings to the SASL exchange an= d init > codepaths which are required for the OAuthbearer work [0]. Regardless of= the > future of that patchset, these refactorings are nice cleanups and can be > considered in isolation. Another goal is of course to reduce scope of th= e > OAuth patchset to make it easier to review. Thanks for pulling these out! They look good overall, just a few notes belo= w. In 0001: > + * SASL_FAILED: The exchance has failed and the connection should be s/exchance/exchange/ > - if (final && !done) > + if (final && !(status =3D=3D SASL_FAILED || status =3D=3D SASL_COMPLETE= )) Since there's not yet a SASL_ASYNC, I wonder if this would be more readable if it were changed to if (final && status =3D=3D SASL_CONTINUE) to match the if condition shortly after it. In 0002, at the beginning of pg_SASL_init, the `password` variable now has an uninitialized code path. The OAuth patchset initializes it to NULL: > +++ b/src/interfaces/libpq/fe-auth.c > @@ -425,7 +425,7 @@ pg_SASL_init(PGconn *conn, int payloadlen) > int initialresponselen; > const char *selected_mechanism; > PQExpBufferData mechanism_buf; > - char *password; > + char *password =3D NULL; > SASLStatus status; > > initPQExpBuffer(&mechanism_buf); I'll base the next version of the OAuth patchset on top of these. Thanks! --Jacob