On Sat, Sep 16, 2017 at 5:15 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: >>> So, we have one failure for chkpass on OpenBSD, because OpenBSD crypt() >>> doesn't support the traditional two-character salt format. > >>> Option: > >>> - Use the resultmap features to make this an expected failure on OpenBSD. > >>> - Fix the module to work on OpenBSD. This would involve making a >>> platform-specific modification to use whatever advanced salt format they >>> want. > >>> - Replace the entire module with something that does not depend on crypt(). > >> Or (4) drop the module's regression test again. > > Noting that mandrill is showing yet a different failure, one that I think > is inherent to chkpass: > > CREATE TABLE test (i int, p chkpass); > INSERT INTO test VALUES (1, 'hello'), (2, 'goodbye'); > + WARNING: type chkpass has unstable input conversion for "hello" > + LINE 1: INSERT INTO test VALUES (1, 'hello'), (2, 'goodbye'); > + ^ > + WARNING: type chkpass has unstable input conversion for "goodbye" > + LINE 1: INSERT INTO test VALUES (1, 'hello'), (2, 'goodbye'); > + ^ > > I'm starting to think that (4) might be the best avenue. Or we could > consider > > (5) drop contrib/chkpass altogether, on the grounds that it's too badly > designed, and too obsolete crypto-wise, to be useful or supportable.
crypt() uses the 7 lowest characters, which makes for 7.2e16 values, so I would be fine with (5), then (4) as the test suite is not portable. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
