On Thu, 28 Aug 2014 17:30:02 -0300, "Carlos H. Cantu"
<lis...@warmboot.com.br> wrote:
> So far, there is no official way to hide procedures and triggers
> source code (protecting intelectual property). The technique of
> updating system tables writing "null" to the source code is used by a
> lot of people, since it seems to be the only way to have some kind of
> protection (ok, BLR can be "understood", but this would required more
> efforts than usually normal people are willing to do).
>
> Problem is that this technique will not work anymore in Firebird 3.
> Since there is still no official way to protect/hide the source code,
> I suggest that the rdb$procedures and rdb$triggers should not become
> readonly until we have an official way to deal with this problem.
>
> I think this is a critical decision that should be discussed now,
> otherwise we can expect lots of mad users when FB 3 is released.
Personally I don't see the point. I also wonder how many people actually
use this loophole; you say "a lot". In my vocabulary that means more than
two; or in other words: it is not a solid basis for a decision.
Your source code is already protected by intellectual property laws. And
although not trivial, deriving the code (or at least an equivalent) from
the blr is possible; meaning that nulling the source code is just a stop
gap. People who really want to get your code and have no qualm breaking the
law, can get to your code. That people abuse a loophole to hide their
source code, is IMHO no reason to officially support it as it just
proliferates the false notion that it offers real protection.
That said, if we want to 'fix' this, there are better solutions (although
still a stop gap). For example SQL Server has:
CREATE { PROC | PROCEDURE } [schema_name.] procedure_name [ ; number ]
[ { @parameter [ type_schema_name. ] data_type }
[ VARYING ] [ = default ] [ OUT | OUTPUT | [READONLY]
] [ ,...n ]
[ WITH <procedure_option> [ ,...n ] ]
[ FOR REPLICATION ]
AS { [ BEGIN ] sql_statement [;] [ ...n ] [ END ] }
[;]
<procedure_option> ::=
[ ENCRYPTION ]
...
Specifying WITH ENCRYPTION will hide the source code for non privileged
users and store it in some obfuscated format
(http://msdn.microsoft.com/en-us/library/ms187926.aspx):
"Indicates that SQL Server will convert the original text of the CREATE
PROCEDURE statement to an obfuscated format. The output of the obfuscation
is not directly visible in any of the catalog views in SQL Server. Users
who have no access to system tables or database files cannot retrieve the
obfuscated text. However, the text will be available to privileged users
who can either access system tables over the DAC port or directly access
database files. Also, users who can attach a debugger to the server process
can retrieve the decrypted procedure from memory at runtime. For more
information about accessing system metadata, see Metadata Visibility
Configuration."
We might also want to consider introducing SELECT rights at column level
(although, again, that can be circumvented).
Mark
------------------------------------------------------------------------------
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
