Good. Some questions.
If the key is wrong, the engine will return horrible, useless gook. It
would be possible to check for ascii/utf-8, but this would defeat other
uses of the mechanism. So return horrible, useless gook.
Internal use is a very interesting case. In Carlo's case, this never
happens, so it isn't an issue. But if he, for example, were to cause the
BLR version to be encrypted, then the object could not be loaded by the
engine without the key. But there's a catch, or rather a class of catches.
All "internal" fields would either need to be encrypted with the same key
or the engine would have to use some heuristic to identify an encrypted
versus plaintext BLR field. This is a major problem if there are system
defined triggers or procedures. Obviously this would take more thought
even if it is eventually found sound. A practical result, however, is that
Carlos could require his customers to have a key to run the application,
though somebody who would steal (or loan or giveaway) the application might
have the sense to steal (or loan or giveaway) the key as well.
If these problems were solved, it might be possible (with some work) to
allow all metadata names to be encrypted, effectivity obfuscating a schema.
But whether this would be feasible, practical, or even worth the effort, I
couldn't say, and please don't consider this part of the proposal.
But, unless additional work is done, the simple answer is that if you
encrypt the BLR version it won't work at all without the key.
On Monday, September 1, 2014, Dimitry Sibiryakov <s...@ibphoenix.com> wrote:
> 01.09.2014 13:50, James Starkey wrote:
> > Selecting the source without the key would return hex or base64 gook.
> With the key, the
> > procedure source.
>
> What will happen if the key is wrong?
> What to do if the engine have to read the field for internal needs? For
> example, how to
> execute a procedure or a trigger with encrypted BLR/source?
>
> --
> WBR, SD.
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
--
Jim Starkey
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
