Re: Adding deprecation notices to pgcrypto documentation

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Adding deprecation notices to pgcrypto documentation
Дата
Msg-id BCBF510A-97D9-41AF-BFC2-8DEDF5EBD199@yesql.se
обсуждение исходный текст
Ответ на Re: Adding deprecation notices to pgcrypto documentation  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Adding deprecation notices to pgcrypto documentation  (Nathan Bossart <nathandbossart@gmail.com>)
Re: Adding deprecation notices to pgcrypto documentation  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
> On 4 Mar 2024, at 23:49, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Mon, Mar 04, 2024 at 10:03:13PM +0100, Daniel Gustafsson wrote:
>> Cleaning out my inbox I came across this which I still think is worth doing,
>> any objections to going ahead with it?
>
> I think the general idea is reasonable, but I have two small comments:
>
> * Should this be a "Warning" and/or moved to the top of the page?  This
>  seems like a relatively important notice that folks should see when
>  beginning to use pgcrypto.

Good question.  If we do we'd probably need to move other equally important
bits of information from "Security Limitations" as well so perhaps it's best to
keep it as is for now, or putting it under Notes.

> * Should we actually document the exact list of algorithms along with
>  detailed reasons?  This list seems prone to becoming outdated.

If we don't detail the list then I think that it's not worth doing, doing the
research isn't entirely trivial as one might not even know where to look or
what to look for.

I don't think this list will move faster than we can keep up with it,
especially since it's more or less listing everything that pgcrypto supports at
this point.

Looking at this some more I propose that we also remove the table of hash
benchmarks, as it's widely misleading.  Modern hardware can generate far more
than what we list here, and it gives the impression that these algorithms can
only be broken with brute force which is untrue.  The table was first published
in 2008 and hasn't been updated since.

Attached is an updated patchset.

--
Daniel Gustafsson


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?
Следующее
От: Nazir Bilal Yavuz
Дата:
Сообщение: Re: Change prefetch and read strategies to use range in pg_prewarm ... and raise a question about posix_fadvise WILLNEED