Look into makefile :)
17.11.2015 18:51, Dimitry Sibiryakov пишет:
> Hello, Adriano.
>
> Subj. "Invalid command line parameters" on run is not much helpful.
>
--
Firebird-Devel mailing list, web interface at
Hello, Adriano.
Subj. "Invalid command line parameters" on run is not much helpful.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
> > Why should the **connection** provide the key?
>
>Because looking for a key is not a work for a lock.
>And keeping the key under a door mat is also generally a bad idea.
Perhaps you are referring to a different "connection" than I am.
Could you/someone please confirm the sequence
Hello, All.
A typical piece of code:
> // do not assign cryptPlugin directly before key init complete
> IDbCryptPlugin* p = cryptControl.plugin();
> keyHolderPlugins.init(p);
> cryptPlugin = p;
> cryptPlugin->addRef();
>Theoretical question: must every connection provide a valid key, or first
> connection unlock the database for everyone?
Why should the **connection** provide the key?
The engine should be able to find/validate the key on its own, when the
database file is _opened_. This would mean that
17.11.2015 18:11, Dimitry Sibiryakov пишет:
> Hello, All.
>
> A typical piece of code:
>
>> // do not assign cryptPlugin directly before key init complete
>> IDbCryptPlugin* p = cryptControl.plugin();
>> keyHolderPlugins.init(p);
>>
17.11.2015 16:26, alex wrote:
> This depends upon crypt key holder plugin.
Right. But to make it possible, Firebird code must provide an opportunity.
In terms of
code the question is "should be setKey() called only after plugin's load or for
every new
attachment no matter if the plugin was
17.11.2015 17:47, Dimitry Sibiryakov пишет:
> Hello, All.
>
> Theoretical question: must every connection provide a valid key, or first
> connection
> unlock the database for everyone?
>
можно сделать и так и сяк - определяется holder-ом
(я сегодня почти не на раюоте завтра постараюсь
17.11.2015 16:18, Leyne, Sean wrote:
> Why should the **connection** provide the key?
Because looking for a key is not a work for a lock.
And keeping the key under a door mat is also generally a bad idea.
--
WBR, SD.
Hello, All.
Theoretical question: must every connection provide a valid key, or first
connection
unlock the database for everyone?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
On 17/11/2015 14:48, Dimitry Sibiryakov wrote:
> 17.11.2015 17:40, Leyne, Sean wrote:
>> For me, the sequence of operations for accessing a database would be:
>>
>> - Client initiates connection to remote server, requesting access to
>> database XYZ.fdb (there is nothing new in the connection
> - Client application set callback for providing a key
I don't understand why client needs to know anything about whether database is
encrypted or not.
Certainly, MS SQL server doesn't require clients to know such details...
Sean
17.11.2015 18:01, Leyne, Sean wrote:
>> - Client application set callback for providing a key
> I don't understand why client needs to know anything about whether database
> is encrypted or not.
This step depends on implementation of KeyHolder plugin and may be not
required.
--
WBR, SD.
17.11.2015 17:40, Leyne, Sean wrote:
> For me, the sequence of operations for accessing a database would be:
>
> - Client initiates connection to remote server, requesting access to database
> XYZ.fdb (there is nothing new in the connection string other than what is
> available now)
> - engine
Hello!
Tuesday, November 17, 2015, 6:26:04 PM, you wrote:
>> The engine should be able to find/validate the key on its own, when the
>> database file is _opened_.
a> This depends upon crypt key holder plugin. Even in SS it may be written
a> in a way forcing each connection to provide valid
Arno, can you please verify now?
It should still reset the array, but much less than before.
Adriano
On 16/11/2015 07:11, Arno Brinkman wrote:
> Hi All,
>
> I noticed some big differences in performance between FB3 and FB2.5,
> so with help form Vlad i got debug builds to do some profiling.
> 17.11.2015 18:01, Leyne, Sean wrote:
> >> - Client application set callback for providing a key
> > I don't understand why client needs to know anything about whether
> database is encrypted or not.
>
>This step depends on implementation of KeyHolder plugin and may be not
> required.
17.11.2015 23:48, Leyne, Sean wrote:
>
> Again, I feel that they issue of client/server connection encryption and
> database encryption are being co-mingled.
>
> Database encryption is about the engine's ability to access/work with a
> database, there should be absolutely no client dependency.
Regression - composite index order cause not using referencing index
Key: CORE-5020
URL: http://tracker.firebirdsql.org/browse/CORE-5020
Project: Firebird Core
Issue Type:
19 matches
Mail list logo
