Re: Oid registry - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Oid registry
Date
Msg-id m2haql7u84.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Oid registry  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: pg_reorg in core?
Next
From: Peter Eisentraut
Date:
Subject: ldap_err2string