03.04.2012 11:55, Alex Peshkoff wrote:
> To work with encrypted database file we need a tool to encrypt database.
> I see 3 possible solutions for it. In all 3 cases some plugin dependent
> parameter may be passed to plugin. In all cases one may use decrypt
> instead encrypt to make
>
> 1. ALTER DATABASE ENCRYPT WITH<PLUGIN_NAME> { ('PARAMETER') }
> This SQL implementation has one main advantage - it looks (I think) very
> native for SQL server.
This gets my primary vote.
> 2. gfix -encrypt<plugin> {-cryptpar<parameter>} database
> gfix passes plugin name and parameter in DPB, the rest of activity are
> like in database validation. This implementation looks like most simple
> to implement.
No DPB hackery, please. GFIX could finally start doing something itself.
For example, run ALTER DATABASE ENCRYPT asynchronously and show the
progress (if requested) via querying the last encrypted pageno from the
header. But anyway, this should be the secondary option, SQL is expected
to be a primary tool for this task.
> 3. Use of special utility: fbdbcrypt -encrypt<plugin> {-cryptpar
> <parameter>} {-verbose} local-database
> Certainly, appropriate support in services will be present.
> This method looks ugly at first, but it has one great advantage -
> ability to have switch 'verbose' and let user watch progress with
> database encryption.
Also possible as a secondary option, let's just decide what's better -
keep polluting GFIX with new features or create new command-line tools
for the every new feature (or a set of features).
Dmitry
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
