Re: [HACKERS] Removal of plaintext password type references
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Removal of plaintext password type references |
Дата | |
Msg-id | CAB7nPqR3qbbABubQky+8q=xJO=L6TzQ5qZLCdKk4dTv7KoGaUg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Removal of plaintext password type references (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Removal of plaintext password type references
|
Список | pgsql-hackers |
On Wed, May 10, 2017 at 10:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: >> Also note that changing the signature check_password_hook_type would >> break any external modules that use the hook. Removing >> PASSWORD_TYPE_PLAINTEXT will do that too, because any password hook >> function would use that constant (see e.g. contrib/passwordcheck). If we >> were to change the signature, I'd actually like to simplify it by >> removing the password_type parameter altogether. The hook function can >> call get_password_type() on the password itself to get the same >> information. But it's not worth changing the API and breaking external >> modules for that. Ahah. I just had the same thought before reading this message. > FWIW, I think we've never hesitated to change hook signatures across major > versions if there was a good reason for it. It seems actually rather > unlikely that an external module interested in check_password_hook would > not need to know about the SCRAM changes, so this case seems like it's > easily justifiable. My modules break every couple of months (utility hook is the last one in date), and usually fixes are no big deals. Removing password_type is in this category, and as long as compilation fails properly people will be able to notice problems easily. -- Michael
В списке pgsql-hackers по дате отправления: