Jim, your latest posting does not help the current situation. It only complicates the discussion unnecessarily.
The immediate problem, and the only one that needs immediate discussion on this list, is how to re-instate the functionality in the initial release of FB3. The problem was identified early enough that a quick fix can be made. The justification has been made that it is needed. All that is needed *right now* is a decision on which solution to provide. Therefore the vote should continue. You recent post is more appropriate for the architecture list. It conflates the immediate problem with a larger problem. The larger problem is how to provide application developers a way to protect part of their application which is stored as data in the database from the prying eyes of database users. That, in turn, is part of an even larger problem of how to protect *any* data stored in the database from prying eyes. But the immediate problem is how to prevent FB3 from being released with reduced functionality that will create problems for the current developer community. The solution can be short term. But it is important to get on with a solution s the release schedule is not delayed unduly. Discussion of the larger issues can be done afterwards. On the architecture list. On 2014-08-31 18:04, firebird-devel-requ...@lists.sourceforge.net wrote: > From: James Starkey <j...@jimstarkey.net> > Subject: Re: [Firebird-devel] Hiding source code of procedures and > triggers will not work in FB 3 > > Let's try another tack on this problem. What is the best possible way > to > solve it if schedule were not a problem? And is this a special case of > a > more general problem? > > Here's an idea to get the creative juices working: Suppose the > database > parameter block were extended with a composite containing quadruples of > <schema, table, field, key>, and if given, instances of the given field > would be encrypted and/or descripted with the given key. This would be > robust, defensible security for any field and would be easy to > implement in > both database tools and the database engine, and would have no impact > on > system tables, the API, or transmission layers. Carlos would be happy, > the > hard-security guys would be happy, and the mechanism would generalize > to > user as well as system tables. > > This is a starter solution. There must be many more lurking out there. ------------------------------------------------------------------------------ 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
