Excuse me, but the requirement is to make the source unreadable. Carlos
listed five ways this could be done. I came up with a sixth that is less
code, less instrusive, and more general than the others, and you say it is
unhelpfull. Why is this?
Decent engineering requires that you understand the problem and consider
all possibities, not just the first few.
The requirement is that the source be unreadable, not that it be set to
null. No additional code is a huge plus.
My proposal would require code in the engine to recognize and parse a DPB
parameter and if found post a block to the attachent and referenced field
blocks. On field reference if there are any encryption blocks, check for
one of the current attachment and if so encrypt or decrypt using the given
key. The DDL tool, in turn, would require a new switch like --source-key
which would add the necessary DPB parameters. The only charge to Carlos's
application is adding the switch to his build scripts.
Selecting the source without the key would return hex or base64 gook. With
the key, the procedure source.
Nobody has argued that this doesn't work, is difficult to implement, or
doesn't meet the requirement.
The argument, in fact, shiftered suddenly from whether Carlos's problem
needs a solution to which of a small number of possibilites is best.
Surely the project has time to consider other possibilities when yesterday
folks were arguing that Carlos should just pound sand.
Adding pre-deprecated DDL commands strikes me as a short sighted crude hack.
The proper way to do engineering is to find the best possible solution,
consider the cost and schedule implications, then, if necessary implement
and extensible subset to address the immediate problem at hand. The worst
way to do engineering is to fall in love with you first idea. But even
worse is to reject other ideas out of hand because they don't conform to
your preconceived idea of a solution (generally called the "stick your head
in the sand" school of engineering).
I'm terribly sorry if you find exposure to new ideas offensive, but I'm
afraid you'll just have to learn to deal with it.
On Sunday, August 31, 2014, Saunders, Rich <greym...@mykolab.com> wrote:
> I got errors returns from the email server so I'm re-sending:
>
> 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.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
