There is no technical requirement to store sources for triggers and
procedures. It is done, presumably, for the convenience of application
developers. Some application developers, of which Carlos is just one, have
demonstrated that storing the sources is sometimes extremely inconvenient,
even detrimental to applications developers.
If Firebird is going to survive, let alone prosper, it can't make a
practice of slapping its highest profile users in the face. It is both
rude and counter-productive.
The capability that Carlos has requested has been there from the beginning
and has only recently been removed, which flies in the face of reasonable
software development. This calls into question whether Firebird exists to
serve the interests of its users or just for the amusement of certain
dilantants.
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.
On Sunday, August 31, 2014, Carlos H. Cantu <lis...@warmboot.com.br> 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.
>
> []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
>
--
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
