Date: Tue, 1 Mar 2022 08:31:19 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>,
	samay sharma <smilingsamay@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Proposal: Support custom authentication methods using hooks
Message-ID: <20220301133119.GR10577@tamriel.snowman.net>
References: <1737574.1645753674@sss.pgh.pa.us>
 <54dc198b56a87e31e9625405383f04a8c6589b8b.camel@j-davis.com>
 <1905579.1645810764@sss.pgh.pa.us>
 <2718414dc095b716e59e126c03af343997d14c7b.camel@j-davis.com>
 <1980351.1645816239@sss.pgh.pa.us>
 <9004b18218eae293f1ee888e49d13d8a6b02810d.camel@j-davis.com>
 <20220228204634.GM10577@tamriel.snowman.net>
 <2738622.1646083128@sss.pgh.pa.us>
 <20220228214255.GO10577@tamriel.snowman.net>
 <Yh28j5PoG+mtAnSH@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3VJSuQsIgdmXj2/q"
Content-Disposition: inline
In-Reply-To: <Yh28j5PoG+mtAnSH@paquier.xyz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://www.postgresql.org/message-id/20220301133119.GR10577%40tamriel.snowman.net>
Precedence: bulk


--3VJSuQsIgdmXj2/q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Mon, Feb 28, 2022 at 04:42:55PM -0500, Stephen Frost wrote:
> > Keeping it around will just push out the point at which everyone will
> > finally be done with it, as there's really only two groups: those who
> > have already moved to scram, and those who won't move until they want to
> > upgrade to a release that doesn't have md5.
>=20
> FWIW, I am not sure if we are at this point yet.  An extra reason to
> remove it would be that it is a support burden, but I don't have seen
> in recent memory any problems related to it that required any deep
> changes in the way to use it, and its code paths are independent.

Ongoing reports that there's a known vulnerability aren't great to have
to deal with.  We can at least point people to scram but that's not
great.

> The last time I played with this area is the recent error handling
> improvement with cryptohashes but MD5 has actually helped here in
> detecting the problem as a patched OpenSSL would complain if trying to
> use MD5 as hash function when FIPS is enabled.

Having to continue to deal with md5 as an algorithm when it's known to
be notably less secure and so much so that organizations essentially ban
its use for exactly what we're using it for, in fact, another reason to
remove it, not a reason to keep it.  Better code coverage testing of
error paths is the answer to making sure that our error handling behaves
properly.

Thanks,

Stephen

--3VJSuQsIgdmXj2/q
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJiHiAnAAoJEO1sijiDR2RVs5EP/ipjvX1a1sRuaiPLx4mZXwbv
m6KgsqKYtVvyBuSJ53hyyAImlgfm32EjY4iC0ZxpLqb7kr+uwlkOBjAiqq9ifWVj
T9X4iBC5H9Jyn34rGMincxFH2DaEP3E03yOeS+S3/V/H46ow6PKLuZCwP2TvyiQo
HjYULi7xK0asGbJsvSaxKGkmny6O1orjNkqtRkItn9eR18ZOAbChPqc0Ym7PrGVg
JivlOOeilkh4K4oUJaU1F5dWyCY/h1At/EoEVOiG/c/hpQGeTI+zeQ6qbTaD0xYz
d7iuxef4x7B4V6HMhdJd1exaVL88d1PV+H3TsQjh40JsHzxDcnJrqlHOVHnmv1u6
g0xWwo5My3I1EmMasvM6zNBpmjF13NB0TY6NZL3jResW+xMPic2+v9uQTX7PkCZE
ZJQgFaxhn8i4NVkUfoKcUIXS+GRK/B5FDWvdslPtlB/tO1FpecK5EgHriHg5uV3R
8W+dhZMQoPBR5EMiZCd/fKgkBosLajkZCg8k2uFSdkvgUWN2Gecl61CU6IyaClhR
JSGZE86go0LuWfE+poPOFMQUPNB/2+86ToBKw6XklOEeEg3rJj+t4nV09St7mCc7
kxbjtQwnS/1xGyCJgokkpR/C3QUt0ZH9mtHdEfmLNjGOk1BLyenfb+ZgXGv6T9Kb
2UtVZwQ/muoWq9F2GZXG
=aLoL
-----END PGP SIGNATURE-----

--3VJSuQsIgdmXj2/q--