Re: sha1, sha2 functions into core?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sha1, sha2 functions into core?
Дата
Msg-id 11890.1345504092@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sha1, sha2 functions into core?  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: sha1, sha2 functions into core?
Re: sha1, sha2 functions into core?
Список pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On 08/20/2012 01:33 PM, Andrew Dunstan wrote:
>> But there is absolutely no evidence that we are making it less useful.
>> Postgres is designed top be extensible and we've just enhanced that.
>> pgcrypto makes use of that. If we cen leverage that to make Postgres
>> available to more people then why would we not do so?

> O.k. that is valid a valid argument. Let me counter.

> Everybody else does it, why don't we? PostgreSQL is extensible, modular 
> and programmable, why are we limiting those features by not including 
> them in core? Contrib, whether we like it or not, is not core.

Nonsense.  By that argument, all the sweat we've expended on
extensibility was wasted effort, and everything should be in core.

pg_crypto's functionality is perfectly fine where it is.  The fact that
there might be some contexts where people actively don't want the
functionality in core is just a small extra reason not to be in a hurry
to merge it --- but even without that, I'd vote against this on overall
project management grounds.  We should be looking to push decouplable
bits of functionality *out* of core, not bring them back in.

The only reason I can see for pushing more crypto into core is
if we needed to stop using MD5 for the core password authentication
functionality.  While that might come to pass eventually, I am aware of
no evidence whatever that SHAn, per se, is an improvement over MD5 for
password auth purposes.  Moreover, as Josh just mentioned, anybody who
thinks it might be insufficiently secure for their purposes has got
plenty of alternatives available today (SSL certificates, PAM backed
by whatever-you-want, etc).

TBH, I think if we do anything at all about this in the near future,
it'll be window dressing to shut up the people who heard once that MD5
was insecure and know nothing about it beyond that --- but if Postgres
uses MD5 for passwords, it must be insecure.  So I tend to agree with
Andrew that we should wait till the NIST competition dust settles; but
what I'll be looking for afterwards is which algorithm has the most
street cred with the average slashdotter.

Also, as I mentioned upthread, we need to do more than just drop in
a new hashing algorithm.  MD5 is far from being the weakest link
in what we're doing today.
        regards, tom lane



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

Предыдущее
От: Phil Sorber
Дата:
Сообщение: Re: PATCH: psql boolean display
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: PATCH: psql boolean display