Re: Oid registry

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Oid registry
Дата
Msg-id m2haql7u84.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: Oid registry  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Given your previous comments, perhaps we could just start handing out
>> Oids (if there is any demand) numbered, say, 9000 and up. That should
>> keep us well clear of any existing use.
>
> No, I think you missed my point entirely: handing out OIDs at the top
> of the manual assignment range is approximately the worst possible
> scenario.  I foresee having to someday move FirstBootstrapObjectId

If that's the only problem, there's an easy way out by registering from
the top of the Oid range down to some constant up over there.

Now it seems like the problem here is that we both want the extension to
be managed as disconnected as possible from PostgreSQL, and at the same
time we want to be able to trust them from within the backend with it
being the only trusted authority.

I'm not security oriented enough to devise a working scheme here, but it
makes me think about some "shared secret" or GnuPG signature. Is it
possible to automatically verify that an extension's ID card (containing
some type's OID, name, etc) has been signed with PostgreSQL's own
private key, without ever having to ship that key in the backend code
nor binary?

To me it's all about how to setup a distributed network of trust…

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support



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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: pg_reorg in core?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: ldap_err2string