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