At 01:19 PM 5/30/00 -0400, Dalton Calford wrote:

>Hi Jim,
>
>> Problem: gbak will need the key (or whatever) to access the restriction
>> portion of the database. Unless we can come up with something tricky,
>> this means giving the key to the system administrator, who is the one
>> we're trying to protect the data from.
>
>Since the programmer will have access to the source of GBAK, they can
>make the change to gbak to include the key without telling the local
>administrator the key.
>

Unfortunately, under the InterBase Public license, the application
developer is obligated to publish his source changes to gbak, not
only giving the key to the entire world, but advertising the change.

>
>Is there any extensions to ODBC that would support a encryption
>mechinism?
>

Odbc has a SQLSetConnectOption() that will allow virtually anything
to be passed in. The value parameter, however, can be either a
a 32 bit value or a pointer to anything, so pumping this across
various interface layers is impossible.

Once we have the entire InterBase community trained in the fine
points of system architecture, we're going to try to teach the
ODBC community the rudamentary basics of software sanitation.
It's not going to be pretty.

Jim Starkey