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
