Is there or will there be an encrypted catalog?
My concern is the visibility of scripts.

Although I haven't tried it yet, I assume when the catalog is read into memory, scripts in
memory will be visible.
(Optional precompiling scripts would make things more difficult for hackers.)


dave m

Dave,

<< Is there or will there be an encrypted catalog? >>

There is the ability in EDB to optionally compress and/or encrypt the
catalog, but we don't have it surfaced as of right now.  The basic issue is
that, if the user has access to the files themselves, they can simply do
more damage by simply deleting them if they want to.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

>>The basic issue is that, if the user has access to the files themselves,
>>they can simply do more damage by simply deleting them if they want to.


That's not the security to which I was referring. I am thinking about reverse engineering,
and making it as difficult as possible. That's why I briefly mentioned plain text scripts
being visible even in memory.  Some time ago I looked at Firebird. As I recall, the answer
to the visibility of scripts was not to give the user access to the gdb and to wait for a
future version. Suffice it to say that this was not a "selling point."


Dave M

Dave,

<< That's not the security to which I was referring.  >>

That may be so, but it's the only security that matters.  If a user can get
to the database files and read the SQL text there, then it really doesn't
matter whether the SQL text is visible in-memory.  Also, pre-compiled
storage in the catalog is not really an option because it is more
space-consuming than plain text and is very inflexible to future changes in
the way the SQL is compiled.

<< I am thinking about reverse engineering, and making it as difficult as
possible. That's why I briefly mentioned plain text scripts being visible
even in memory. >>

There's no way to prevent the SQL text from being read while it is
in-memory.   The only way around this is to use the C/S access in EDB, which
would mean that SQL objects are only read into memory on the ElevateDB
Server.

--
Tim Young
Elevate Software
www.elevatesoft.com