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
