Re: Internal key management system

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Internal key management system
Дата
Msg-id 11430.1581181677@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Internal key management system  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Internal key management system  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
>> On February 8, 2020 7:08:26 AM PST, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>>>> I don't think it's very likely we'll ever merge any openssl code into
>>>> our repository, e.g. because of licensing. But we already have AES
>>>> implementation in pgcrypto - why not to use that? I'm not saying we
>>>> should make this depend on pgcrypto, but maybe we should move the AES
>>>> library from pgcrypto into src/common or something like that.

>> The code uses functions exposed by openssl, it doesn't copy there code.

> Sure, I know the code is currently calling ooenssl functions. I was
> responding to Masahiko-san's message that we might eventually merge this
> openssl code into our tree.

No.  This absolutely, positively, will not happen.  There will never be
crypto functions in our core tree, because then there'd be no recourse for
people who want to use Postgres in countries with restrictions on crypto
software.  It's hard enough for them that we have such code in contrib
--- but at least they can remove pgcrypto and be legal.  If it's in
src/common then they're stuck.

For the same reason, I don't think that an "internal key management"
feature in the core code is ever going to be acceptable.  It has to
be an extension.  (But, as long as it's an extension, whether it's
bringing its own crypto or relying on some other extension for that
doesn't matter from the legal standpoint.)

            regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Index Skip Scan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Marking some contrib modules as trusted extensions