Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. There is also the common work around of inserting SYSDBA into the roles table to prevent sysdba from connecting to the database. This functionality is also being removed by locking off the system tables. FB 3 is already working on stronger user authentication methods - sysdba in newer versions of firebird does not necessarily mean the same as it did in earlier releases. On disk and over the wire encryption are also being worked on if not implemented. So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. This would not only answer the current problems of hiding the source code, it would still allow authorized developers to check the source for version comparisons. It would also provide functionality which is provided by other database engines and which would simplify the DBA's job. - GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the database level. All metadata in the database will be visible/invisible to *public (or whoever you define)*. - GRANT VIEW DEFINITION ON OBJECT :: object_name TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION ON OBJECT :: object_name TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the object level. All metadata for the object will be visible/invisible to *public*. If the object is a table, all the columns, indexes, statistics, and constraints of the table will be visible to the *public*. This behaviour also applies to GRANT VIEW DEFINITION ON ASSEMBLY and other similar GRANT statements. Obviously the encryption/decryption part would wait for later versions of FB so as to not hold up on the release, but, for now, the behaviour could be implemented. I believe such functionality for hiding columns/tables is available in the redsoft version of firebird. The extension to the parser could be provided now, while the hiding of an objects source would delete the source until the encryption process is properly thought through. On 3 September 2014 07:44, Carlos H. Cantu lis...@warmboot.com.br wrote: I think we already reached a point where core developers can hit the hammer in what will be the chosen solution of this problem in FB 3. I would be satisfied with either relaxing rules in rdb$triggers/procedures, or with new syntax, or with last Jim's proposal of SET statement. I'll leave this to you (core developers) decide what one is more adequate for the time being. Another option (maybe not so simple) could be a flag in the database header that would tell Firebird if the source should be kept or not. The flag could be set with gfix, as we already do with forced writes, etc. About the other proposals, they can be discussed again for future releases, after FB 3 is finally out. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
04.09.2014 16:49, Dalton Calford wrote: So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. No, they couldn't unless Firebird is run in controlled environment which is not the case of topic starter. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dalton, it's theoretically impossible to hide something with system privileges and without encryption on an open source product. All that's necessary is for someone to compile a version without checks. Now, it is true that we're only trying to protect the source from people too ignorant or lazy to decompile the BLR, but these people probably aren't too ignorant or lazy to download a security crippled version of the product. We are, in short, between a marshmallow and a soft place. On 9/4/2014 10:49 AM, Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. There is also the common work around of inserting SYSDBA into the roles table to prevent sysdba from connecting to the database. This functionality is also being removed by locking off the system tables. FB 3 is already working on stronger user authentication methods - sysdba in newer versions of firebird does not necessarily mean the same as it did in earlier releases. On disk and over the wire encryption are also being worked on if not implemented. So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. This would not only answer the current problems of hiding the source code, it would still allow authorized developers to check the source for version comparisons. It would also provide functionality which is provided by other database engines and which would simplify the DBA's job. * GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the database level. All metadata in the database will be visible/invisible to *public (or whoever you define)*. * GRANT VIEW DEFINITION ON OBJECT :: object_name TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION ON OBJECT :: object_name TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the object level. All metadata for the object will be visible/invisible to *public*. If the object is a table, all the columns, indexes, statistics, and constraints of the table will be visible to the *public*. This behaviour also applies to GRANT VIEW DEFINITION ON ASSEMBLY and other similar GRANT statements. Obviously the encryption/decryption part would wait for later versions of FB so as to not hold up on the release, but, for now, the behaviour could be implemented. I believe such functionality for hiding columns/tables is available in the redsoft version of firebird. The extension to the parser could be provided now, while the hiding of an objects source would delete the source until the encryption process is properly thought through. On 3 September 2014 07:44, Carlos H. Cantu lis...@warmboot.com.br mailto:lis...@warmboot.com.br wrote: I think we already reached a point where core developers can hit the hammer in what will be the chosen solution of this problem in FB 3. I would be satisfied with either relaxing rules in rdb$triggers/procedures, or with new syntax, or with last Jim's proposal of SET statement. I'll leave this to you (core developers) decide what one is more adequate for the time being. Another option (maybe not so simple) could be a flag in the database header that would tell Firebird if the source should be kept or not. The flag could be set with gfix, as we already do with forced writes, etc. About the other proposals, they can be discussed again for future releases, after FB 3 is finally out. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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 -- 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 -- Slashdot TV. Video for Nerds. Stuff that matters.
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
If the on disk file is encrypted as stated in my discussion, and the sysdba is limited or prevented from connecting as also stated, then this will run on a non-controlled environment. The question is, what level of encryption is needed? You can encrypt the entire database, certain pages of the database or specific defined files of a database.Each of these levels can in turn be encrypted with a different key. For example, you may want the entire database to be encrypted - the only way to open the database is by using a custom embedded fb client, or passing the master key with the connection string. Then, when trying to open a data page that has a different encryption key, the user would either have to provide it or not connect.You can have private/public keys, or any one of many known secure methods of protecting the on disk files while having it in a non-controlled environment. This is all part of the encryption/decryption/authentication methods that have been discussed for years. My proposal was to implement a standard ddl method to address the needs that also provides new functionality. I also stated that this can be done immediately without the application of the new encryption/authorization layers by just using the same DDL to actually delete the source code. ie - take away the need for touching the system tables while providing a way of getting the same job done. On 4 September 2014 10:57, Dimitry Sibiryakov s...@ibphoenix.com wrote: 04.09.2014 16:49, Dalton Calford wrote: So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. No, they couldn't unless Firebird is run in controlled environment which is not the case of topic starter. -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. Part of the problem is the timing. How much do the Firebird developers really want to implement right now before v3.0 release. Another part is that application developers need an overlap between the removal of the old feature and the introduction of the new - because this allows the migration to be done in a more controlled manner. Hence my previous suggestion that option 4 is the best way to go _now_ - if that is viable. Any improvement/replacement features should be discussed separately. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. [...] So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. [...] The core requirement, as I understand it, is to prevent legitimate customers (who possess a copy of the database that they access from a Firebird server running on their own machine) from extracting the source code. [Cutting this short, because Jim has already covered the point I was going to make about replacing the server to extract the data and/or keys.] -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Hi Jim, If the on disk database is encrypted, and the end user is only provided enough credential keys to see what the application developer wants them to see, then, the information remains secure. The assumption on my part is that some elements of the database such as the DDL descriptions, source and other elements are NOT for end user consumption. There is no reason for a end user to have the keys to decrypt that information. BUT, from a developers standpoint, once they say that that information is to be encrypted and invisible to the end user, they do not have to continuously worry about deleting source code or their comments. They don't have to alter their deployment scripts and if they are not sure what version the end user has, they can use a custom embedded engine tool to connect directly to the database to review the actual database comments and source to confirm that the appropriate patches have been applied. What it does mean, is that if someone tries to connect to a database that is fully encrypted and their client does not securely pass the decryption key to the server, the server will just come back with an error about the database being corrupt or some other agreed upon error message. On 4 September 2014 11:04, Jim Starkey j...@jimstarkey.net wrote: Dalton, it's theoretically impossible to hide something with system privileges and without encryption on an open source product. All that's necessary is for someone to compile a version without checks. Now, it is true that we're only trying to protect the source from people too ignorant or lazy to decompile the BLR, but these people probably aren't too ignorant or lazy to download a security crippled version of the product. We are, in short, between a marshmallow and a soft place. On 9/4/2014 10:49 AM, Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. There is also the common work around of inserting SYSDBA into the roles table to prevent sysdba from connecting to the database. This functionality is also being removed by locking off the system tables. FB 3 is already working on stronger user authentication methods - sysdba in newer versions of firebird does not necessarily mean the same as it did in earlier releases. On disk and over the wire encryption are also being worked on if not implemented. So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. This would not only answer the current problems of hiding the source code, it would still allow authorized developers to check the source for version comparisons. It would also provide functionality which is provided by other database engines and which would simplify the DBA's job. - GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the database level. All metadata in the database will be visible/invisible to *public (or whoever you define)*. - GRANT VIEW DEFINITION ON OBJECT :: object_name TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION ON OBJECT :: object_name TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the object level. All metadata for the object will be visible/invisible to *public*. If the object is a table, all the columns, indexes, statistics, and constraints of the table will be visible to the *public*. This behaviour also applies to GRANT VIEW DEFINITION ON ASSEMBLY and other similar GRANT statements. Obviously the encryption/decryption part would wait for later versions of FB so as to not hold up on the release, but, for now, the behaviour could be implemented. I believe such functionality for hiding columns/tables is available in the redsoft version of firebird. The extension to the parser could be provided now, while the hiding of an objects source would delete the source until the encryption process is properly thought through. On 3 September 2014 07:44, Carlos H. Cantu lis...@warmboot.com.br wrote: I think we already reached a point where core developers can hit the hammer in what will be the chosen solution of this problem in FB 3. I would be satisfied with either relaxing rules in rdb$triggers/procedures, or with new
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Sep 4, 2014, at 11:17 AM, Geoff Worboys wrote: Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. Part of the problem is the timing. How much do the Firebird developers really want to implement right now before v3.0 release. Speaking of the v3 .0 release, who updates 3.0 Beta 1 release dates? August 31 has come and gone: http://tracker.firebirdsql.org/secure/Dashboard.jspa Are there really just 5 unresolved issues delaying the beta release? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Hi Geoff, If you notice at the end of my first posting, I said the encryption/decryption/authorization could wait for later implementation and the new DDL statements that happen to deal with the rdb$source fields would just delete the source - ie provide the same functionality. The existing behaviour could also remain with the comment that it will be deprecated in favour of the new syntax. If redsoft did not already have such security implementations already in place I would consider it to be out of the question, but, since redsoft has already performed most of this work, I am surprised it has not already made it's way back into the core product. On 4 September 2014 11:17, Geoff Worboys ge...@telesiscomputing.com.au wrote: Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. Part of the problem is the timing. How much do the Firebird developers really want to implement right now before v3.0 release. Another part is that application developers need an overlap between the removal of the old feature and the introduction of the new - because this allows the migration to be done in a more controlled manner. Hence my previous suggestion that option 4 is the best way to go _now_ - if that is viable. Any improvement/replacement features should be discussed separately. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. [...] So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. [...] The core requirement, as I understand it, is to prevent legitimate customers (who possess a copy of the database that they access from a Firebird server running on their own machine) from extracting the source code. [Cutting this short, because Jim has already covered the point I was going to make about replacing the server to extract the data and/or keys.] -- Geoff Worboys Telesis Computing Pty Ltd -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
I don't necessarily disagree with you, but what you suggest requires major design, buy in, and implementation, none of which are remotely possible in the available time. Encryption is all about key management which is not simple and if isn't correctly designed and implemented, is useless. It also requires encrypted links to pass keys, which is another issue. Given the amount of discussion required to decide that Carlos has a problem worth addressing, the idea of an encryption infrastructure could be resolved in a few days is hopeless given that even after a decade or two, even SSL is riddled with problems. On 9/4/2014 11:17 AM, Dalton Calford wrote: Hi Jim, If the on disk database is encrypted, and the end user is only provided enough credential keys to see what the application developer wants them to see, then, the information remains secure. The assumption on my part is that some elements of the database such as the DDL descriptions, source and other elements are NOT for end user consumption. There is no reason for a end user to have the keys to decrypt that information. BUT, from a developers standpoint, once they say that that information is to be encrypted and invisible to the end user, they do not have to continuously worry about deleting source code or their comments. They don't have to alter their deployment scripts and if they are not sure what version the end user has, they can use a custom embedded engine tool to connect directly to the database to review the actual database comments and source to confirm that the appropriate patches have been applied. What it does mean, is that if someone tries to connect to a database that is fully encrypted and their client does not securely pass the decryption key to the server, the server will just come back with an error about the database being corrupt or some other agreed upon error message. On 4 September 2014 11:04, Jim Starkey j...@jimstarkey.net mailto:j...@jimstarkey.net wrote: Dalton, it's theoretically impossible to hide something with system privileges and without encryption on an open source product. All that's necessary is for someone to compile a version without checks. Now, it is true that we're only trying to protect the source from people too ignorant or lazy to decompile the BLR, but these people probably aren't too ignorant or lazy to download a security crippled version of the product. We are, in short, between a marshmallow and a soft place. On 9/4/2014 10:49 AM, Dalton Calford wrote: I still argue that we should take the opportunity to not only fix this issue, but to improve the FB product functionality. The core requirement is to stop non-authorized users from viewing source code. The current process is to delete the source code from the database. There is also the common work around of inserting SYSDBA into the roles table to prevent sysdba from connecting to the database. This functionality is also being removed by locking off the system tables. FB 3 is already working on stronger user authentication methods - sysdba in newer versions of firebird does not necessarily mean the same as it did in earlier releases. On disk and over the wire encryption are also being worked on if not implemented. So, a database can theoretically have some items that are encrypted on the database owners security authorization that even SYSDBA can not see, nor can they decrypt since the on disk records are encrypted using the database owners encryption key vs the regular users encryption key. So, DDL statements such as GRANT VIEW which is used by MS SQL for metadata security could be applied to FB. This would not only answer the current problems of hiding the source code, it would still allow authorized developers to check the source for version comparisons. It would also provide functionality which is provided by other database engines and which would simplify the DBA's job. * GRANT VIEW DEFINITION TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the database level. All metadata in the database will be visible/invisible to *public (or whoever you define)*. * GRANT VIEW DEFINITION ON OBJECT :: object_name TO public [WITH DECRYPTION KEY privatekey]; REVOKE VIEW DEFINITION ON OBJECT :: object_name TO public [WITH ENCRYPTION KEY privatekey]; This statement will override metadata-visibility limitations at the object level. All metadata for the object will be visible/invisible to *public*. If the object is a table, all the columns, indexes, statistics, and constraints of the table will be
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
04.09.2014 19:25, Tom Coleman wrote: Speaking of the v3.0 release, who updates 3.0 Beta 1 release dates? Me. August 31 has come and gone: I know. Are there really just 5 unresolved issues delaying the beta release? Yes, around that number. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dalton Calford wrote: [...] What it does mean, is that if someone tries to connect to a database that is fully encrypted and their client does not securely pass the decryption key to the server, the server will just come back with an error about the database being corrupt or some other agreed upon error message. Well, Jim already mentioned encrypted links being necessary, but that's not the end of it. Once you no longer control the host on which encryption and decryption is performed, all bets are off. For example: The customer is running the server, yes? The server is compiled from Firebird open source, yes? The remote developer sometimes connects to do maintenance, yes? So the customer inserts a small debugging line into the code to write out the key used by the developer when they access the database remotely. Recompile and slip it in to start instead of the original Firebird server. Too easy. The application developer may add some obscurity to it all if they build their own Firebird server with a few changes to make it less easy for the customer to simply replace. I can tell a customer how to make their databases secure for themselves - and I don't need any encryption added to Firebird to do it. But I can't protect myself from my customer unless I keep control of the server. If redsoft have done it, I'd be interested to hear how. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Hi Geoff, You must have missed the part about the developer using a custom embedded tool ie, not going through the server but touching the database directly. Using custom embedded tools for such work is quite common and if the developer leaves that tool in the clients control when they are not working on the system, that is their own fault.You can only provide tools assuming a base level of competence. If you don't provide the solution with the understanding that the end user has to be smart enough to use it properly, then you can extend that line of thinking to removing all cars from the roads on the basis that some users may drive impaired. If you are concerned about security, you would not connect to any element in your software stack that you are not confident of.I take it to the next level and do not run my servers on any form of microsoft product, but, not everyone maintains databases that contain private customer data. As for redsoft, the part of their software stack that I am referring to happens to be the grant visible code.I also know they have encryption implemented, but as I have not performed any security testing with their product, I can not vouch for how it is implemented or works. As I have stated in multiple posts - I am not looking for the authentication/authorization/encryption layer to be complete, just a parser change. In the same vein as COMMENT ON replaced UPDATE RDB$ SET RDB$DESCRIPTION=... . best regards That would mean that the de On 4 September 2014 12:10, Geoff Worboys ge...@telesiscomputing.com.au wrote: Dalton Calford wrote: [...] What it does mean, is that if someone tries to connect to a database that is fully encrypted and their client does not securely pass the decryption key to the server, the server will just come back with an error about the database being corrupt or some other agreed upon error message. Well, Jim already mentioned encrypted links being necessary, but that's not the end of it. Once you no longer control the host on which encryption and decryption is performed, all bets are off. For example: The customer is running the server, yes? The server is compiled from Firebird open source, yes? The remote developer sometimes connects to do maintenance, yes? So the customer inserts a small debugging line into the code to write out the key used by the developer when they access the database remotely. Recompile and slip it in to start instead of the original Firebird server. Too easy. The application developer may add some obscurity to it all if they build their own Firebird server with a few changes to make it less easy for the customer to simply replace. I can tell a customer how to make their databases secure for themselves - and I don't need any encryption added to Firebird to do it. But I can't protect myself from my customer unless I keep control of the server. If redsoft have done it, I'd be interested to hear how. -- Geoff Worboys Telesis Computing Pty Ltd -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dalton Calford wrote: [...] As I have stated in multiple posts - I am not looking for the authentication/authorization/encryption layer to be complete, just a parser change. In the same vein as COMMENT ON replaced UPDATE RDB$ SET RDB$DESCRIPTION=... . Having slept on it (which I really should have done before trying to answer the last posts - sorry), I agree that some sort of non-system-table-update solution would be better. If GRANT VIEW is the mechanism adopted by other systems then there is a reasonable argument for following that convention, although it seems a more complex solution than necessary or appropriate for the requirement. But whether this has to be done for v3.0 is another matter, although I can see the attraction of having the replacement syntax in place now, so that the old update can also be marked as deprecated now. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
I think we already reached a point where core developers can hit the hammer in what will be the chosen solution of this problem in FB 3. I would be satisfied with either relaxing rules in rdb$triggers/procedures, or with new syntax, or with last Jim's proposal of SET statement. I'll leave this to you (core developers) decide what one is more adequate for the time being. Another option (maybe not so simple) could be a flag in the database header that would tell Firebird if the source should be kept or not. The flag could be set with gfix, as we already do with forced writes, etc. About the other proposals, they can be discussed again for future releases, after FB 3 is finally out. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Another possible solution: a set statement that controls the state of the DDL engine to save source or not (defalut is save). Essentially the same as the dpb item but syntax. The positive is that it doesn't mess with the syntax of already complex declarations and needs only appear once in a script. The negative is that it is not backwards compatible and will cause a syntax error on previous versions. On Sep 2, 2014, at 1:42 AM, Dmitry Yemanov firebi...@yandex.ru wrote: 02.09.2014 01:23, Jim Starkey wrote: Whatever user application that works with the database and executes metadata upgrade scripts itself, without invoking ISQL. Do you really think there are any? Seriously? Really? I know that. Also, there are popular ISQL replacements like IBEScript. Option (1) from the list of solution being discussed, i.e. new DDL statement. You just argued that changing scripts was a bad idea. I argued that changing / recompiling the application was a bad idea. Changing the script is a not a problem. We may allow *only* setting rdb$source to NULL and *only* for SYSDBA / DBO, everything else will still be prohibited. This sounds like a whole raft of conditions. Would it have to be a literal null or would a null input parameter be ok? How about an express that turns out null? In VIO, NULL is just NULL, whatever is looked like at the SQL level. What if somebody tried to set it to something other than null? An exception: rdb$cantsetfieldtoanythingbutnullandthenonlyifyoursysdba? Throw the current exception (cannot modify system table or alike). And how about an empty but not null blob? We may allow that, but I'd rather have it rejected either (for simplicity sake). I gotta say that a table that has only one field writable and then only assignable to null and only if the user is SYSDBA is a pretty crude hack. Not quite elegant. Agreed wholeheartedly. The point was that it restores exactly what was possible prior to v3 without compromising the system tables protection and that it's easy (if not easiest) to implement. I didn't pretent it looking elegant. Dmitry -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 02/09/2014 02:42, Dmitry Yemanov wrote: Agreed wholeheartedly. The point was that it restores exactly what was possible prior to v3 without compromising the system tables protection and that it's easy (if not easiest) to implement. I didn't pretent it looking elegant. Not only the source, but the debug info should be nullable as well IMO. Adriano -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 09/01/14 01:53, Carlos H. Cantu wrote: DY What about unencrypted distributed databases? Should we care about DY hiding PSQL source also from SYSDBA / DBO? Are there real cases when it DY would be needed? Well, the currently hack makes no distinction of users, so if the idea is to maintain currently behavior, it doesn't matter who is the user, he would see no source. 1) Create an official way to make the source null DY So far I tend voting for (1), using a special syntax. +1, and we don't need to advertise it as a protection at all. This special syntax can be described as to be used by people who doesn't want to have the plain source code stored in the database (for whatever is the reason g). That's nice - but what should happen with that special syntax when BLR follows DYN? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 08/31/14 23:23, James Starkey wrote: 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. But what prevents anyone to use that present in database key to decrypt procedure code and watch it? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Sun, 31 Aug 2014 18:04:25 -0400, Tom Coleman tcole...@autowares.com wrote: I no longer write applications that do not use some form of ORM. The last time I tried to find a JPA solution that worked with Firebird I was disappointed. Could you post some more details about these problems to Firebird-java or to me directly? I am planning to spend some time on improving dialect support for Hibernate and maybe EclipseLink, but the only real problem I have seen were with blobs/clobs (a mismatch between how Jaybird describes them (as LONGVARBINARY/LONGVARCHAR) and what the Firebird dialect of Hibernate expects (as BLOB/CLOB)), and - on older versions - a mismatch in column naming. Knowing what other problems to look for would be extremely helpful. Firebird needs to catch up. Preserve whatever functionality exists now in FB3 for the benefit of current users and move on. 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Mon, 1 Sep 2014 02:48:59 +1000, Geoff Worboys ge...@telesiscomputing.com.au wrote: Hey, it's my grudge, I'll carry it as long as I want! ;-) More seriously, it didn't come into being until v2.1 did it? And was then backported to v2.0. I can imagine the same sort of thing happening with this source code deletion unless the issue is addressed now. Looks like you're right. 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 11:24, Alex Peshkoff wrote: That's nice - but what should happen with that special syntax when BLR follows DYN? Easy option - deprecate the command. A more clever one - not DROP (nullify) the source but set some flag to HIDE it instead. That flag would mean returning NULL instead of source blob for user requests, while still returning a proper source blob for internal requests. A compromise - ALTER ... HIDE SOURCE may be implemented via SET TO NULL in v3 and via the aforementioned trick starting with v4. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 09/01/14 12:18, Dmitry Yemanov wrote: 01.09.2014 11:24, Alex Peshkoff wrote: That's nice - but what should happen with that special syntax when BLR follows DYN? Easy option - deprecate the command. A more clever one - not DROP (nullify) the source but set some flag to HIDE it instead. That flag would mean returning NULL instead of source blob for user requests, while still returning a proper source blob for internal requests. A compromise - ALTER ... HIDE SOURCE may be implemented via SET TO NULL in v3 and via the aforementioned trick starting with v4. If Carlos is satisfied with such solution it's ok for me. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
That's nice - but what should happen with that special syntax when BLR follows DYN? Easy option - deprecate the command. A more clever one - not DROP (nullify) the source but set some flag to HIDE it instead. That flag would mean returning NULL instead of source blob for user requests, while still returning a proper source blob for internal requests. A compromise - ALTER ... HIDE SOURCE may be implemented via SET TO NULL in v3 and via the aforementioned trick starting with v4. Sounds like a plan. With regards, Martijn Tonies Upscene Productions http://www.upscene.com Download Database Workbench for Oracle, MS SQL Server, Sybase SQL Anywhere, MySQL, InterBase, NexusDB and Firebird! -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
James Starkey wrote: 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? [...] I'm in no position to make an assessment of this, but I am curious about your claims of less code, less intrusive. That might be true of one or two of the other options, but options 1 and 4 would seem inherently simpler. My vote in this doesn't really count (I'm not a developer and I don't use this requested feature) but it seems that both options 1 and 4 have the advantage of being familiar to those that are already doing this (so, hopefully, easy for them to adapt to as they update to v3.0). Any of the other options, and yours in particular, will require a significant change in their current code and implementation procedures. At this late stage of v3.0, it seems to me that simple and least possible change (to v3 and to the developer) should be high on the list of priorities. More sophisticated options could be assessed in detail later. Personally (assuming it's not more difficult than it sounds) I think that option 4 (Leave the rdb$procedures and rdb$triggers writable (or at list the source field)) is the best fit at this time. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 16:01, Geoff Worboys wrote: At this late stage of v3.0, it seems to me that simple and least possible change (to v3 and to the developer) should be high on the list of priorities. More sophisticated options could be assessed in detail later. Exactly for this reasons the option leave everything as is and see if these developers really cannot live without it should have highest priority, because it is the simplest. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
No, that's not even close to true. If the only fields encypted were the procedure and trigger source blobs, nothing would be inaccessible without the key except those blobs. Obviously you disagree. Please explain your logic. On Sep 1, 2014, at 9:51 AM, Dimitry Sibiryakov s...@ibphoenix.com wrote: 01.09.2014 15:22, James Starkey wrote: 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. As the result, the efforts to protect database content from stealing leads to a database that cannot be used. Security catch #1: information is either accessible or secured, but there is no way to get both. -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 01/09/2014 11:14, Jim Starkey wrote: No, that's not even close to true. If the only fields encypted were the procedure and trigger source blobs, nothing would be inaccessible without the key except those blobs. Obviously you disagree. Please explain your logic. Source text is (may be) a complement to external routines. Some routine may need it readable. Adriano -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
How can you make an assessment without taking the time to understand it? The Achilles heel of open source is the drive to be the first to kill a new idea or to kill it the deadest. It made progress at MySQL almost impossible. Even ideas as simple as stabilizing error codes across versions. Regrettably, this is why new ideas require new forks or new companies. On Sep 1, 2014, at 10:01 AM, Geoff Worboys ge...@telesiscomputing.com.au wrote: James Starkey wrote: 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? [...] I'm in no position to make an assessment of this, but I am curious about your claims of less code, less intrusive. That might be true of one or two of the other options, but options 1 and 4 would seem inherently simpler. My vote in this doesn't really count (I'm not a developer and I don't use this requested feature) but it seems that both options 1 and 4 have the advantage of being familiar to those that are already doing this (so, hopefully, easy for them to adapt to as they update to v3.0). Any of the other options, and yours in particular, will require a significant change in their current code and implementation procedures. At this late stage of v3.0, it seems to me that simple and least possible change (to v3 and to the developer) should be high on the list of priorities. More sophisticated options could be assessed in detail later. Personally (assuming it's not more difficult than it sounds) I think that option 4 (Leave the rdb$procedures and rdb$triggers writable (or at list the source field)) is the best fit at this time. -- Geoff Worboys Telesis Computing Pty Ltd -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 16:14, Jim Starkey wrote: No, that's not even close to true. If the only fields encypted were the procedure and trigger source blobs, nothing would be inaccessible without the key except those blobs. Obviously you disagree. Please explain your logic. I'm still thinking about SQL-only engine, without burden of keeping backward compatibility at BLR level. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dimitry Sibiryakov wrote: 01.09.2014 16:01, Geoff Worboys wrote: At this late stage of v3.0, it seems to me that simple and least possible change (to v3 and to the developer) should be high on the list of priorities. More sophisticated options could be assessed in detail later. Exactly for this reasons the option leave everything as is and see if these developers really cannot live without it should have highest priority, because it is the simplest. I certainly have sympathy for this view (because I don't believe the current delete-source system is worth anything much), but I've also been on the other end of this sort of logic (as I noted in a previous post). The more Firebird does this, the more of a reputation it will get for leaving users behind, and the less users will be inclined stay with or come to Firebird. Exactly how much will option 4 cost in development effort? Is it hard to do? If it's not, if we're only standing on the principle that deleting source is a waste of time, then why bother? Sure, the ideal of no-system-table-writes is a nice to have, but if it's not hard to make the exception for the source field at the moment then why not do it and end the argument ... for now. Having made that choice, the argument can then start again (but with no impact on v3 release dates) over whether deleting the source is going to be officially deprecated (in favour of something else?). If so, the announcement can be made, perhaps giving a v3.5 or v4 deadline, and application developers will have advance warning to start finding alternative solutions. Obviously, if we want those alternative solutions to be based on Firebird, it will be best if we can offer some alternative within Firebird before the feature is deprecated (so that the application developers can start their migration before the feature disappears) - whether it is the suggestion to use UDR or UDF to hide sensitive logic, or whether it's some form of obfuscation that we may even try to sell under the title of encryption. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Jim Starkey wrote: How can you make an assessment without taking the time to understand it? I understand enough to know that all of the options mean intercepting reads and/or writes to the source field. Any form of obscuring encryption you want to add to the read/write of that field is obviously in addition to that interception (along with key management etc.) - hence my assumption that it will take more code. If you can explain to me how it can take less code to do encryption, decryption and key management, than to write null to the source field the I am willing be educated. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 16:35, Geoff Worboys wrote: The more Firebird does this, the more of a reputation it will get for leaving users behind, and the less users will be inclined stay with or come to Firebird. It may sound scary, but... what other option do they really have?.. Oracle? PG? MySQL?.. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Mon, 01 Sep 2014 16:47:24 +0200, Dimitry Sibiryakov s...@ibphoenix.com wrote: 01.09.2014 16:35, Geoff Worboys wrote: The more Firebird does this, the more of a reputation it will get for leaving users behind, and the less users will be inclined stay with or come to Firebird. It may sound scary, but... what other option do they really have?.. Oracle? PG? MySQL?.. And you think that is not an option? 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Sorry, if you had been paying attention, you would have noticed that the key comes from a database parameter block parameter. Really, understand first, then shoot. I outlined the code. Maybe two, three hours. Possibly a whole day if it involves selecting an open source AES function. I described the interception. A single pointer test for zero to handle the non-encrypted case, a little more plus the encryption/decryption otherwise. The reason it is less is that it doesn't require any DDL (or making some critical system tables user writeable). My fundamental point wasn't this solution, though I think it has merit. It was that the rush to implementation excluded the possibility of better solutions. I gave one as a starting point. Surely there are some creative brains who can come up with others... On Sep 1, 2014, at 10:47 AM, Geoff Worboys ge...@telesiscomputing.com.au wrote: Jim Starkey wrote: How can you make an assessment without taking the time to understand it? I understand enough to know that all of the options mean intercepting reads and/or writes to the source field. Any form of obscuring encryption you want to add to the read/write of that field is obviously in addition to that interception (along with key management etc.) - hence my assumption that it will take more code. If you can explain to me how it can take less code to do encryption, decryption and key management, than to write null to the source field the I am willing be educated. -- Geoff Worboys Telesis Computing Pty Ltd -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 16:57, Mark Rotteveel wrote: And you think that is not an option? Yep. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 17:10, Dimitry Sibiryakov wrote: These vendors are too lazy to convert their PSQL routines into UDRs. BTW, Adriano had no problem with IDL - C++/FPC translation. I'm sure he can make PSQL - C++/FPC translator as well to offer them a help in securing their precious code. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Jim Starkey wrote: Sorry, if you had been paying attention, you would have noticed that the key comes from a database parameter block parameter. Really, understand first, then shoot. So? If you had been paying attention, you would have noticed that I didn't single key management out as the only factor. Indeed, why bother with the encryption aspect at all? It's simply unnecessary and redundant at this point - which was my fundamental point. If the aim is to avoid needing new DLL etc., then take your DPB idea and make it a boolean save source option. When an application builds their database for distribution, or when they login to apply updates to a customer database, they make sure to set this option in their connection string and away they go. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
I think that would do it. Simplest idea so far. Anybody see any problems with it? Anyone have a simpler solution? On Sep 1, 2014, at 11:35 AM, Geoff Worboys ge...@telesiscomputing.com.au wrote: Jim Starkey wrote: Sorry, if you had been paying attention, you would have noticed that the key comes from a database parameter block parameter. Really, understand first, then shoot. So? If you had been paying attention, you would have noticed that I didn't single key management out as the only factor. Indeed, why bother with the encryption aspect at all? It's simply unnecessary and redundant at this point - which was my fundamental point. If the aim is to avoid needing new DLL etc., then take your DPB idea and make it a boolean save source option. When an application builds their database for distribution, or when they login to apply updates to a customer database, they make sure to set this option in their connection string and away they go. -- Geoff Worboys Telesis Computing Pty Ltd -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 01/09/2014 12:31, Dimitry Sibiryakov wrote: 01.09.2014 17:10, Dimitry Sibiryakov wrote: These vendors are too lazy to convert their PSQL routines into UDRs. BTW, Adriano had no problem with IDL - C++/FPC translation. I'm sure he can make PSQL - C++/FPC translator as well to offer them a help in securing their precious code. How many $$ are you going to paying me? Adriano -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 18:12, Adriano dos Santos Fernandes wrote: How many $$ are you going to paying me? Nothing: I'm proud of my PSQL sources and have to will to hide them. Ask those Brazil guys Carlos was referring to. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 18:14, Dimitry Sibiryakov wrote: Nothing: I'm proud of my PSQL sources and have to will to hide them. It should be read as I have NO wish to hide them. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 19:58, Jim Starkey wrote: Anybody see any problems with it? I like neither DPB solution because it's DPB. It's not a connection string option, it's an API option. Surely not a problem for ISQL users that will support it out of the box. But most of existing user applications need to be recompiled to use the new option. Those devs who are too high level will have to wait until their underlying Firebird connectivity library is updated to support the new option. I don't call this user-friendly, sorry. IMHO, a DDL solution is much handier. And it's also implementable in a few hours. Relaxed write restriction for rdb$source is probably even easier to implement. And it doesn't require us to think about the forward compatible syntax. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 20:58, Dmitry Yemanov wrote: Relaxed write restriction for rdb$source is probably even easier to implement. But it requires a quite complex condition, no? Not just if relation is system one, throw exception, but if relation is system one, but not this and that, throw exception. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 23:28, Dimitry Sibiryakov wrote: But it requires a quite complex condition, no? Not just if relation is system one, throw exception, but if relation is system one, but not this and that, throw exception. Complex condition is: relation is X and no other field but rdb$source is modified. We already have function in VIO doing such a check for other purposes. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 23:35, Dmitry Yemanov wrote: Complex condition is: relation is X and no other field but rdb$source is modified and the new value is NULL, of course. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
What possible user applications are going to be doing procedure and trigger definitions that require the source be omitted? In all likelihood, the option will be used exactly once in the DDL utility. And what syntax are you talking about? There isn't any DPB syntax -- it's a clumplet encoded string. And what connectivity library that the DDL utility is going to be are we talking about? Think the implementation consists of a couple of lines in the DPB decode switch statement that sets a bit in the attachment object and a single conditional around the code that inserts a trigger or procedure. Five lines, max? The problem with write access to RDB$TRIGGERS and RDB$PROCEDURES (or whatever the correct names are) is that anybody with privilege can store crap, which is the reason they were to be made read-only except for the system. Your objections suggest you that don't understand the Geof's proposal. I suggest you step back and think about it a bit more. If you still have objections, please come back with more concrete example of why this has any impact on application programs whatsoever. On Monday, September 1, 2014, Dmitry Yemanov firebi...@yandex.ru wrote: 01.09.2014 19:58, Jim Starkey wrote: Anybody see any problems with it? I like neither DPB solution because it's DPB. It's not a connection string option, it's an API option. Surely not a problem for ISQL users that will support it out of the box. But most of existing user applications need to be recompiled to use the new option. Those devs who are too high level will have to wait until their underlying Firebird connectivity library is updated to support the new option. I don't call this user-friendly, sorry. IMHO, a DDL solution is much handier. And it's also implementable in a few hours. Relaxed write restriction for rdb$source is probably even easier to implement. And it doesn't require us to think about the forward compatible syntax. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
02.09.2014 00:22, James Starkey wrote: What possible user applications are going to be doing procedure and trigger definitions that require the source be omitted? Whatever user application that works with the database and executes metadata upgrade scripts itself, without invoking ISQL. And what syntax are you talking about? Option (1) from the list of solution being discussed, i.e. new DDL statement. The problem with write access to RDB$TRIGGERS and RDB$PROCEDURES (or whatever the correct names are) is that anybody with privilege can store crap, which is the reason they were to be made read-only except for the system. We may allow *only* setting rdb$source to NULL and *only* for SYSDBA / DBO, everything else will still be prohibited. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
01.09.2014 21:35, Dmitry Yemanov wrote: Complex condition is: relation is X and no other field but rdb$source is modified. We already have function in VIO doing such a check for other purposes. You are not going to simplify code, are you?.. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Sep 1, 2014, at 4:42 PM, Dmitry Yemanov firebi...@yandex.ru wrote: 02.09.2014 00:22, James Starkey wrote: What possible user applications are going to be doing procedure and trigger definitions that require the source be omitted? Whatever user application that works with the database and executes metadata upgrade scripts itself, without invoking ISQL. Do you really think there are any? Seriously? Really? And what syntax are you talking about? Option (1) from the list of solution being discussed, i.e. new DDL statement. You just argued that changing scripts was a bad idea. This sounds more like a shotgun blast than a reasoned argument. The problem with write access to RDB$TRIGGERS and RDB$PROCEDURES (or whatever the correct names are) is that anybody with privilege can store crap, which is the reason they were to be made read-only except for the system. We may allow *only* setting rdb$source to NULL and *only* for SYSDBA / DBO, everything else will still be prohibited. Ok, explain about simple again. This sounds like a whole raft of conditions. Would it have to be a literal null or would a null input parameter be ok? How about an express that turns out null? What if somebody tried to set it to something other than null? An exception: rdb$cantsetfieldtoanythingbutnullandthenonlyifyoursysdba? And how about an empty but not null blob? I gotta say that a table that has only one field writable and then only assignable to null and only if the user is SYSDBA is a pretty crude hack. Not quite elegant. Kinda sort of I painted myself in the corner and couldn't find any other way out feature. Dmitry -- 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 -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Dmitry Yemanov wrote: I like neither DPB solution because it's DPB. It's not a connection string option, it's an API option. Surely not a problem for ISQL users that will support it out of the box. But most of existing user applications need to be recompiled to use the new option. Those devs who are too high level will have to wait until their underlying Firebird connectivity library is updated to support the new option. I don't call this user-friendly, sorry. IMHO, a DDL solution is much handier. And it's also implementable in a few hours. Relaxed write restriction for rdb$source is probably even easier to implement. And it doesn't require us to think about the forward compatible syntax. And I think that last is probably the most appealing to application developers in the short term, because it should mean no change to their existing implementation scripts. That also gives more time to discuss the best way forward for Firebird - without implementing official DDL or other mechanism that we may have reason to regret/deprecate in the near future. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
02.09.2014 00:59, Dimitry Sibiryakov wrote: Complex condition is: relation is X and no other field but rdb$source is modified. We already have function in VIO doing such a check for other purposes. You are not going to simplify code, are you?.. Neither of the solutions being discussed simplifies the code, except removing of the system tables protection or leaving everything as is. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Saunders, Rich greym...@mykolab.com wrote Mon, 01 Sep 2014 04:06:24 +0400: In addition to protecting FB3 procedures, functions and triggers should also realize and reset the source code of the package body. -- Simonov Denis -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
31.08.2014 13:51, Carlos H. Cantu wrote: As pointed before, databases with procs/triggers with null source can be restored in FB 3 without any problem, but you can't erase the sources anymore. This looks inconsistent. Proposals so far: 1) Create an official way to make the source null 2) Create a way to obfuscate the source 3) Create a way to store the source encrypted 4) Leave the rdb$procedures and rdb$triggers writable (or at list the source field). 5) Create special privilege for users to be able to retrieve the source code. 6) Prohibit restoring databases without sources. It will make the behavior consistent. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 31-8-2014 13:51, Carlos H. Cantu wrote: Let's get back to the facts and try to reach a decision: We have a hack that many people uses for a long time, to make it more difficult to stole procedures/triggers source (more difficult, not impossible, since BLR can be decoded to source). They know it is not 100% safe, but so far it is the only way to avoid standard/common users (the ones who knows only how to connect to database and run select), to have access to the sources. As pointed before, databases with procs/triggers with null source can be restored in FB 3 without any problem, but you can't erase the sources anymore. This looks inconsistent. Proposals so far: 1) Create an official way to make the source null 2) Create a way to obfuscate the source 3) Create a way to store the source encrypted 4) Leave the rdb$procedures and rdb$triggers writable (or at list the source field). 5) Create special privilege for users to be able to retrieve the source code. 1, 4 and 5 seems to be the only solutions that could be done without delaying FB 3 release (core developers can confirm this). So, as delaying the release of FB 3 is not an option, for now, we should consider only possible solutions that would fit this requirement. Better approach may appear in future versions. Since this would be developed by the core-developers, I would like to ask them to vote on this matter. The feature can be listed as just that: a feature to avoid storing the source code of procedures. We don't need to announce/list it as a a feature to protect anything, so we would not need to worry if someone argues that source could be decoded from BLR. When creating/altering such objects, people would choose if they want the plain source stored or not... just that. I think I have made my opinion clear, so I won't reiterate my position. However if we want to delay a real decision, then we simply opt for 4 (Leave the rdb$procedures and rdb$triggers writable) and we do *not* communicate this as a feature/solution/workaround *at all*. And I think it would be advisable to add an explicit note to the release notes that a future version of Firebird may forbid this entirely. Mark -- Mark Rotteveel -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
James Starkey wrote: [...] Carlos has enumerated a set of acceptable possibilities, none of which is overwhelming difficult. I can see no constructive reason why his request should not be accomodated other than contempt for users. Despite my objections to the technique (that it could, quite literally, become completely - instead of just mostly - futile overnight), I do have reasons for agreeing with the above. I still haven't forgiven Firebird for the abrupt change of alias ambiguity rules from v1.5 to v2.0. The particular circumstances of the time meant that this was hugely inconvenient to one of my largest projects. Had some migration mechanism been provided the change over could have been handled on a gradual basis and the project could have stayed current with Firebird. I'd like to argue that developers have already had years to find a better solution than deleting the source, but really the only better solution is UDR, and developers need significant time to migrate. So if you want projects to stay current, you need to give them a changeover period to move to the better solution. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 31-08-2014 12:06, Geoff Worboys wrote: I'd like to argue that developers have already had years to find a better solution than deleting the source, but really the only better solution is UDR, and developers need significant time to migrate. So if you want projects to stay current, you need to give them a changeover period to move to the better solution. UDR is about integration. Anyone claiming UDR to be a replacement to PSQL or exposition of code does not understand what UDR is. Adriano -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 31-8-2014 17:06, Geoff Worboys wrote: I still haven't forgiven Firebird for the abrupt change of alias ambiguity rules from v1.5 to v2.0. The particular circumstances of the time meant that this was hugely inconvenient to one of my largest projects. Had some migration mechanism been provided the change over could have been handled on a gradual basis and the project could have stayed current with Firebird. The firebird.conf setting RelaxedAliasChecking was that migration mechanism (and it still exists if Firebird 2.5, and afaik in Firebird 3). Mark -- Mark Rotteveel -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Adriano dos Santos Fernandes wrote: On 31-08-2014 12:06, Geoff Worboys wrote: I'd like to argue that developers have already had years to find a better solution than deleting the source, but really the only better solution is UDR, and developers need significant time to migrate. So if you want projects to stay current, you need to give them a changeover period to move to the better solution. UDR is about integration. Anyone claiming UDR to be a replacement to PSQL or exposition of code does not understand what UDR is. There is still a lot of room for moving complex code out of PSQL and into external procedures. There are many things for which PSQL is not an ideal choice, just as there are things for which UDRs will not be ideal. And there do seem to be opportunities for UDRs to be used to pull out some of the sensitive logic that people are trying to protect, and even just hiding some parts of a sensitive procedure will be like a black box that may make the meaning of the rest less clear - and less easily diverted to unwanted use. But you're right, of course. I've not tried to use UDRs yet, so I can't claim to fully understand or know the limitations. And, like all new features, it will take time to learn what's possible and what's practical. -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
31.08.2014 15:51, Carlos H. Cantu wrote: We have a hack that many people uses for a long time, to make it more difficult to stole procedures/triggers source (more difficult, not impossible, since BLR can be decoded to source). They know it is not 100% safe, but so far it is the only way to avoid standard/common users (the ones who knows only how to connect to database and run select), to have access to the sources. What about unencrypted distributed databases? Should we care about hiding PSQL source also from SYSDBA / DBO? Are there real cases when it would be needed? 1) Create an official way to make the source null 2) Create a way to obfuscate the source 3) Create a way to store the source encrypted 4) Leave the rdb$procedures and rdb$triggers writable (or at list the source field). 5) Create special privilege for users to be able to retrieve the source code. See my question above. I would hate to support an object-level privilege that can be revoked from the object owner. And, given how our security works now, it won't work for SYSDBA anyway. 1, 4 and 5 seems to be the only solutions that could be done without delaying FB 3 release (core developers can confirm this). So far I tend voting for (1), using a special syntax. Dmitry -- 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
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. On Sunday, August 31, 2014, Dmitry Yemanov firebi...@yandex.ru wrote: 31.08.2014 15:51, Carlos H. Cantu wrote: We have a hack that many people uses for a long time, to make it more difficult to stole procedures/triggers source (more difficult, not impossible, since BLR can be decoded to source). They know it is not 100% safe, but so far it is the only way to avoid standard/common users (the ones who knows only how to connect to database and run select), to have access to the sources. What about unencrypted distributed databases? Should we care about hiding PSQL source also from SYSDBA / DBO? Are there real cases when it would be needed? 1) Create an official way to make the source null 2) Create a way to obfuscate the source 3) Create a way to store the source encrypted 4) Leave the rdb$procedures and rdb$triggers writable (or at list the source field). 5) Create special privilege for users to be able to retrieve the source code. See my question above. I would hate to support an object-level privilege that can be revoked from the object owner. And, given how our security works now, it won't work for SYSDBA anyway. 1, 4 and 5 seems to be the only solutions that could be done without delaying FB 3 release (core developers can confirm this). So far I tend voting for (1), using a special syntax. Dmitry -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
DY What about unencrypted distributed databases? Should we care about DY hiding PSQL source also from SYSDBA / DBO? Are there real cases when it DY would be needed? Well, the currently hack makes no distinction of users, so if the idea is to maintain currently behavior, it doesn't matter who is the user, he would see no source. 1) Create an official way to make the source null DY So far I tend voting for (1), using a special syntax. +1, and we don't need to advertise it as a protection at all. This special syntax can be described as to be used by people who doesn't want to have the plain source code stored in the database (for whatever is the reason g). []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Aug 31, 2014, at 9:39 AM, James Starkey wrote: This calls into question whether Firebird exists to serve the interests of its users or just for the amusement of certain dilantants. Jim's often prescient comments sent me to the dictionary to look this one up. Per Webster: dil·et·tante noun \ˈdi-lə-ˌtänt, -ˌtant; ˌdi-lə-ˈ\ : a person whose interest in an art or in an area of knowledge is not very deep or serious Apparently Jim used the term in reference to Firebird users. Firebird developers certainly have deep knowledge of technology, but perhaps too deep. From my perspective, the entire subject of protecting source code in procedures is completely irrelevant. Our Oracle DBA throws a fit every time I suggest that some method run in the database as a stored procedure. The database is not designed for that!, he screams. He is a database purist. His focus is optimizing the delivery of relational data. To him, having the database engine wasting cycles running code that belongs in the application is criminal. He feels almost as strongly about using alphanumeric primary keys. The current revolution in web application development is moving logic out of the database and out of the presentation layer and into services. It can be summed up as: javascript calling services. I no longer write applications that do not use some form of ORM. The last time I tried to find a JPA solution that worked with Firebird I was disappointed. Firebird needs to catch up. Preserve whatever functionality exists now in FB3 for the benefit of current users and move on. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
OK, my spelling has never been that goode. But how about session specific field encryption? Carlos? On Sunday, August 31, 2014, Tom Coleman tcole...@autowares.com wrote: On Aug 31, 2014, at 9:39 AM, James Starkey wrote: This calls into question whether Firebird exists to serve the interests of its users or just for the amusement of certain dilantants. Jim's often prescient comments sent me to the dictionary to look this one up. Per Webster: dil·et·tante *noun* \ˈdi-lə-ˌtänt, -ˌtant; ˌdi-lə-ˈ\ : a person whose interest in an art or in an area of knowledge is not very deep or serious Apparently Jim used the term in reference to Firebird users. Firebird developers certainly have deep knowledge of technology, but perhaps too deep. From my perspective, the entire subject of protecting source code in procedures is completely irrelevant. Our Oracle DBA throws a fit every time I suggest that some method run in the database as a stored procedure. The database is not designed for that!, he screams. He is a database purist. His focus is optimizing the delivery of relational data. To him, having the database engine wasting cycles running code that belongs in the application is criminal. He feels almost as strongly about using alphanumeric primary keys. The current revolution in web application development is moving logic out of the database and out of the presentation layer and into services. It can be summed up as: javascript calling services. I no longer write applications that do not use some form of ORM https://en.wikipedia.org/wiki/Object-relational_mapping. The last time I tried to find a JPA https://en.wikipedia.org/wiki/Java_Persistence_API solution that worked with Firebird I was disappointed. Firebird needs to catch up. Preserve whatever functionality exists now in FB3 for the benefit of current users and move on. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
28.08.2014 22:30, Carlos H. Cantu wrote: 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. A lot of mad users who is unable to hide their sources vs a lot of mad users who got exception or unexpected NULL result from old applications (including isql) trying to read the sources. Who win? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 08/29/14 12:16, Dimitry Sibiryakov wrote: 28.08.2014 22:30, Carlos H. Cantu wrote: 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. A lot of mad users who is unable to hide their sources vs a lot of mad users who got exception or unexpected NULL result from old applications (including isql) trying to read the sources. Who win? I'm afraid you did not understand what Carlos suggests - he only wants to be able to set source field to null like it was possible since fb1 times (sooner of all in interbase too). Certainly that's not a method of protecting, but I see no ways how can it cause unexpected NULL result in old app-s - such technique is in use for a long time. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
29.08.2014 10:47, Alex Peshkoff wrote: I'm afraid you did not understand what Carlos suggests - he only wants to be able to set source field to null like it was possible since fb1 times (sooner of all in interbase too). Certainly that's not a method of protecting, but I see no ways how can it cause unexpected NULL result in old app-s - such technique is in use for a long time. You are right. But does it really worth returning of writable system tables or a different solution exists?.. Encrypting of sources won't work. Returning of NULL/exception to anybody except owner/admins won't work. The only way I see - to implement ALTER PROCEDURE ERASE SOURCES or something like that. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 08/29/14 12:58, Dimitry Sibiryakov wrote: 29.08.2014 10:47, Alex Peshkoff wrote: I'm afraid you did not understand what Carlos suggests - he only wants to be able to set source field to null like it was possible since fb1 times (sooner of all in interbase too). Certainly that's not a method of protecting, but I see no ways how can it cause unexpected NULL result in old app-s - such technique is in use for a long time. You are right. But does it really worth returning of writable system tables or a different solution exists?.. Encrypting of sources won't work. Why? If decrypt key is present only at developer's server - it's not bad solution. Returning of NULL/exception to anybody except owner/admins won't work. Definitely. The only way I see - to implement ALTER PROCEDURE ERASE SOURCES or something like that. This will work. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Fri, 29 Aug 2014 13:19:02 +0400, Alex Peshkoff peshk...@mail.ru wrote: On 08/29/14 12:58, Dimitry Sibiryakov wrote: 29.08.2014 10:47, Alex Peshkoff wrote: I'm afraid you did not understand what Carlos suggests - he only wants to be able to set source field to null like it was possible since fb1 times (sooner of all in interbase too). Certainly that's not a method of protecting, but I see no ways how can it cause unexpected NULL result in old app-s - such technique is in use for a long time. You are right. But does it really worth returning of writable system tables or a different solution exists?.. Encrypting of sources won't work. Why? If decrypt key is present only at developer's server - it's not bad solution. Returning of NULL/exception to anybody except owner/admins won't work. Definitely. The only way I see - to implement ALTER PROCEDURE ERASE SOURCES or something like that. This will work. That sounds like an idea. An alternative would be to allow this when creating or altering the procedure, eg something like CREATE PROCEDURE myprocedure(...) RETURNS ... WITH (SUPPRESS_SOURCE) AS ... -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
29.08.2014 11:19, Alex Peshkoff wrote: different solution exists?.. Encrypting of sources won't work. Why? If decrypt key is present only at developer's server - it's not bad solution. Too complicated, IMHO. The only way I see - to implement ALTER PROCEDURE ERASE SOURCES or something like that. This will work. Only if you are going to keep using BLR forever. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 08/29/14 13:49, Mark Rotteveel wrote: On Fri, 29 Aug 2014 13:19:02 +0400, Alex Peshkoff peshk...@mail.ru wrote: On 08/29/14 12:58, Dimitry Sibiryakov wrote: 29.08.2014 10:47, Alex Peshkoff wrote: I'm afraid you did not understand what Carlos suggests - he only wants to be able to set source field to null like it was possible since fb1 times (sooner of all in interbase too). Certainly that's not a method of protecting, but I see no ways how can it cause unexpected NULL result in old app-s - such technique is in use for a long time. You are right. But does it really worth returning of writable system tables or a different solution exists?.. Encrypting of sources won't work. Why? If decrypt key is present only at developer's server - it's not bad solution. Returning of NULL/exception to anybody except owner/admins won't work. Definitely. The only way I see - to implement ALTER PROCEDURE ERASE SOURCES or something like that. This will work. That sounds like an idea. An alternative would be to allow this when creating or altering the procedure, eg something like CREATE PROCEDURE myprocedure(...) RETURNS ... WITH (SUPPRESS_SOURCE) AS ... Like Dimitriy correctly noticed - this will cause great problems when the moment will come to stop using BLR. And what should we do with such statement at that time? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
MR Personally I don't see the point. I also wonder how many people actually MR use this loophole; you say a lot. In my vocabulary that means more than MR two; or in other words: it is not a solid basis for a decision. I would say thousands of installations, at last in Brazil. MR Your source code is already protected by intellectual property laws. You are kidding, right? Do you really think people that wants to stole your code are worried with copyright laws? MR And although not trivial, deriving the code (or at least an MR equivalent) from the blr is possible; meaning that nulling the MR source code is just a stop gap. As I said in my original email. MR That said, if we want to 'fix' this, there are better solutions (although MR still a stop gap). For example SQL Server has: [...] Looks interesting. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 08/29/14 13:51, Dimitry Sibiryakov wrote: 29.08.2014 11:19, Alex Peshkoff wrote: different solution exists?.. Encrypting of sources won't work. Why? If decrypt key is present only at developer's server - it's not bad solution. Too complicated, IMHO. BTW - when dropping BLR this will not work too. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Fri, 29 Aug 2014 07:11:38 -0300, Carlos H. Cantu lis...@warmboot.com.br wrote: MR Personally I don't see the point. I also wonder how many people actually MR use this loophole; you say a lot. In my vocabulary that means more than MR two; or in other words: it is not a solid basis for a decision. I would say thousands of installations, at last in Brazil. MR Your source code is already protected by intellectual property laws. You are kidding, right? Do you really think people that wants to stole your code are worried with copyright laws? No I don't, but the protection offered by deleting the source is equivalently weak, and actually makes it harder to prove theft (as the reverse engineered source is not identical). 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Fri, 29 Aug 2014 14:12:12 +0400, Alex Peshkoff peshk...@mail.ru wrote: That sounds like an idea. An alternative would be to allow this when creating or altering the procedure, eg something like CREATE PROCEDURE myprocedure(...) RETURNS ... WITH (SUPPRESS_SOURCE) AS ... Like Dimitriy correctly noticed - this will cause great problems when the moment will come to stop using BLR. And what should we do with such statement at that time? What does that mean? On the fly/on demand compilation from source, or using a different byte code representation than blr? If the first then you still have my initial WITH (ENCRYPTION) proposal as an alternative, and remember you already have a problem anyway with people who currently delete the source. However, my primary opinion is that these are all stopgap measures that don't offer any real protection; so why go through the trouble of offering it in any official way. 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On Fri, 29 Aug 2014 14:53:14 +0400, Alex Peshkoff peshk...@mail.ru wrote: On 08/29/14 14:43, Mark Rotteveel wrote: What does that mean? On the fly/on demand compilation from source, or using a different byte code representation than blr? Compilation from source directly into executable by engine form. If the first then you still have my initial WITH (ENCRYPTION) proposal as an alternative Afraid that in open source world this hardly works - if engine is able to decrypt source for compilation it's too easy to add printf-s where needed and open DB with such engine. That not only applies to open source though. It is probably also the reason why the SQL server documentation I linked to earlier says the source is obfuscated, and that people with sufficient rights still have access, and that you can get the unobfuscated version using a debugger; it is a stopgap (or deterrent), not a real solution. 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
As already Robert said: FB 3 provides UDRs. If someone want to hide sources - use them. AP Certainly it's the good solution. Afaics, UDR is new feature, and add extra complexity compared to creating and maintaining procedures/triggers direct in the database (thing that most people are more than used to do). []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
29.08.2014 13:12, Carlos H. Cantu wrote: Afaics, UDR is new feature, and add extra complexity compared to creating and maintaining procedures/triggers direct in the database Is it too high price for protecting your copyrights?.. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
29.08.2014 13:57, Carlos H. Cantu wrote: The matter is that most companies who uses FB in Brazil are really small. Some one them has only one developer. Changing to UDR may require big changes in the way those companies updates and maintain their softwares (this means cost). How much money they will loose if someone see the sources of their source procedures? -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
29.08.2014 14:47, Carlos H. Cantu wrote: You can ask them:) Actually, they have to ask themselves if the sources are precious enough to waste time for their protection. AFAIK, database itself is usually pointless without application that works with it. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
On 29 August 2014 08:53, Dimitry Sibiryakov s...@ibphoenix.com wrote:
Actually, they have to ask themselves if the sources are precious
enough to waste time
for their protection. AFAIK, database itself is usually pointless without
application that
works with it.
Not always true.
I have databases that contain no data - they are just a series of views,
triggers and procedures designed to provide access to a different database.
Such 'Surfacing' databases are used for ODBC/JDBC/OLAP clients who need
to see tables/columns in their own language while allowing the use of
modern data cube analysis tools.
Such a database is designed for general access from any client.
Some developers who do not have mandated language laws, design their
database for access by such third party tools.
This issue could be solved by extending the GRANT/REVOKE DDL syntax such as
adding a VISIBLE [AS NULL] option to the privileges list - ie if you
revoke visible from a column, it is as if that column does not exist. If
you revoke visible with the as null option, the column exists for you, but,
returns a null as a result.
GRANT
{*privileges* ON *object* | *role*}
TO *grantees*
[WITH {GRANT|ADMIN} OPTION]
[{GRANTED BY | AS} [USER] *grantor*]
privilege_list = SELECT
| DELETE
| INSERT
| UPDATE
| VISIBLE[AS NULL]
--
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
As an extrapolation of my last post,
The idea of extending the grant revoke syntax vs allowing for removing the
code from the system tables assumes a few things.
1.) It assumes enhanced user authorization options and control
2.) It makes the assumption that since blr can be reversed and encrypted
source could be decrypted with sufficient work, it is pointless to add a
feature that is by-passable.
3.) It opens up features not currently available - such as implementing
user defined, hidden system columns within their own tables to track things
that should never be seen by the end user.
The idea of giving developers the ability to hide part of their design, is
a good feature. It actually can make it easier for end users who do not
need to see all the underlying mechanics that makes their systems run.
Database authentication and encryption, both on disk or over the wire is
another can of worms that should be implemented separately from the need to
obfuscate a developers source code.
As far as I understand it, both enhanced authentication mechanisms and
encryption mechanisms are being worked on already, leaving a simple
extension to the security layer in regards to the VISIBLE option as an
appropriate manner of dealing with the problem without breaking any
existing applications.
best regards
Dalton
On 29 August 2014 09:51, Dalton Calford dalton.calf...@gmail.com wrote:
On 29 August 2014 08:53, Dimitry Sibiryakov s...@ibphoenix.com wrote:
Actually, they have to ask themselves if the sources are precious
enough to waste time
for their protection. AFAIK, database itself is usually pointless
without application that
works with it.
Not always true.
I have databases that contain no data - they are just a series of views,
triggers and procedures designed to provide access to a different database.
Such 'Surfacing' databases are used for ODBC/JDBC/OLAP clients who need
to see tables/columns in their own language while allowing the use of
modern data cube analysis tools.
Such a database is designed for general access from any client.
Some developers who do not have mandated language laws, design their
database for access by such third party tools.
This issue could be solved by extending the GRANT/REVOKE DDL syntax such
as adding a VISIBLE [AS NULL] option to the privileges list - ie if you
revoke visible from a column, it is as if that column does not exist. If
you revoke visible with the as null option, the column exists for you, but,
returns a null as a result.
GRANT
{*privileges* ON *object* | *role*}
TO *grantees*
[WITH {GRANT|ADMIN} OPTION]
[{GRANTED BY | AS} [USER] *grantor*]
privilege_list = SELECT
| DELETE
| INSERT
| UPDATE
| VISIBLE[AS NULL]
--
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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Anyone who's followed the support list for a decade or so knows that developers frequently ask how they can protect the source of their procedures. And, likewise, that the answer is that the esssence of the procedure is the BLR and must be readable to be used, so the best option is to mask the problem by setting the source to NULL. Beyond that, Carlos Cantu has unusual insight in that he offers a wealth of support and information for Firebird developers in Brazil, one of the countries that uses Firebird the most. Nothing in Firebird uses the content of RDB$SOURCE fields except the code in ISQL that extracts schemas. Setting the source to null is not secure, but it is a technique that has been used widely for the whole history of Firebird. It's similar to the Java class obfuscators in that reverse compiling BLR isn't impossible, but it deters the lazy. That said, blocking user writes to the system tables is a good thing. Writeable system tables were a cute idea in the early eighties, using the database methods to run the database. In the wider world (and the world is much wider now) writeable system tables are a disaster waiting to happen. However, there's a cost to change, even change for the better. When possible, change should techniques that preserve current capabilities. How hard would it be to add clauses [WITH [OUT] SOURCE] to CREATE and ALTER statements plus [DROP SOURCE] to the ALTER statements? (Including, of course, RECREATE and all it's varients). If that would hold up V3, then promise it for 3.01 and let developers who worry about theft wait one release. Changing Firebird to a direct SQL engine won't be materially affected. As Mark Rotteveel noted, complex system objects are likely to have two representations - SQL source and partially compiled - for efficiency and to allow developers to hide their work. Cheers, Ann Don't get me started on encrypting the system tables, or I'll trot out the old politically incorrect story. -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
Carlos H. Cantu 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. Just an observation about the nature of this stuff, rather than an argument against your suggestion ... Once this becomes an officially sanctioned way to protect your code, it seems likely that recovery tools would follow. We may go from a system of protection that was never good, but only used by those that were willing to go to the extra bother (and presumably take the extra care), to a system that might be used with less care and understanding and so create a demand better recovery tools. Up to now, the system seems not to have inspired anyone to write a good recovery tool - or not that I've noticed, but then I've never looked beyond the basic BLR viewer that has been in IBObjects for years. An official language feature may well change that. And having, officially, given users a way to shoot themselves in the foot, what do we say to someone that wants to add an option to gfix to recover the lost source code? (After all, ISQL has a metadata extract feature, what was the point of that if we expected users to always have copies of the source they used to create the database? ;-) -- Geoff Worboys Telesis Computing Pty Ltd -- 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
Re: [Firebird-devel] Hiding source code of procedures and triggers will not work in FB 3
2014-08-29 17:51 GMT+04:00 Dalton Calford dalton.calf...@gmail.com: This issue could be solved by extending the GRANT/REVOKE DDL syntax such as adding a VISIBLE [AS NULL] option to the privileges list - ie if you revoke visible from a column, it is as if that column does not exist. If you revoke visible with the as null option, the column exists for you, but, returns a null as a result. IMO it's completely enough to have any granted permission to make a column visible for user. A column is invisible if there is no any granted permission. I cannot imagine a situation when you have SELECT for column but do not have VISIBLE. Regarding PROCEDURES it could be the same. SOURCE could be visible only for users who have ALTER PROCEDURE permission. Now DDL permissions are supported, you know. But it still does not solve a problem of protection SOURCE code of a procedure. I tend to an idea of either encryption of SOURCE field by developer's key or do not store SOURCE code at all depending on special option of CREATE or ALTER procedure. -- Roman Simakov -- 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
