On 18/11/15 12:38, Dimitry Sibiryakov wrote:
>> Should there be a way to reset UUID for existing database?
>> >
>> > Backup-restore.
>> > Not really handy, I'd say.
>Whatever users use the ID for, it should identify the database as long as
> it exists.
> May be gfix may be ta
18.11.2015 22:32, Dmitry Yemanov wrote:
>> >as long as UUID and Crypt Database ID are understood to be separate values
> Here I completely agree.
Ok, I, actually, don't care which one my plugin will get. All I need is
something for
key holder to make decision which key it must return. Includi
18.11.2015 23:20, Leyne, Sean wrote:
>
> as long as UUID and Crypt Database ID are understood to be separate values
Here I completely agree.
Dmitry
--
Firebird-Devel mailing list, web interface at
https://lists.sourc
Dmitry,
> > Consider: I want to restore a copy of my production database to my testing
> system and have the same UUID as Live because I have defined a number of
> config/operational values based on the UUID.
>
> Consider: I have a replication set up with replica B linked to source database
> A v
Bieniaszewski
-Oryginalna wiadomość-
From: Dmitry Yemanov
Sent: Wednesday, November 18, 2015 8:14 PM
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] Database UUID
18.11.2015 21:17, Leyne, Sean wrote:
>
> Consider: I want to restore a copy of my prod
18.11.2015 21:17, Leyne, Sean wrote:
>
> Consider: I want to restore a copy of my production database to my testing
> system and have the same UUID as Live because I have defined a number of
> config/operational values based on the UUID.
Consider: I have a replication set up with replica B linke
18.11.2015 19:36, Alex Peshkoff wrote:
> But Iagree, from all other aspects placing databases ID in RDB$Database
> table is better.
MON$DATABASE if you wish.
> For example it's stored encrypted.
What's the point?
--
WBR, SD.
---
On 11/18/2015 09:11 PM, Leyne, Sean wrote:
>>> How should it be retrieved by the client?
>> No way. If someone ask for it, new item can be added to
>> isc_get_database_info().
> Should be added as virtual column of RDB$Database table
I suppose Dmitry wanted to use uuid (except other) as an I
> >> Should nbackup preserve or reset it?
> >
> > Preserve because technically it is the same database.
>
> Here we disagree. It becomes a different database after fixup/restore, even
> being a page-level copy of the original one.
While I see your point about the database being different, fr
> > How should it be retrieved by the client?
>
>No way. If someone ask for it, new item can be added to
> isc_get_database_info().
Should be added as virtual column of RDB$Database table
> > When/how should it be created for already existing ODS12 databases?
>
>At restore.
Agree
>
18.11.2015 14:21, Alex Peshkoff wrote:
> If you do not want to use it in your plugin you are free to ignore it.
> For other plugins it's OK to load the key at once if it's name is stored
> in database in order to avoid callback to client in some funny place
> like AST.
Say, we have in firebird.
On 11/18/2015 04:10 PM, Dimitry Sibiryakov wrote:
> 18.11.2015 14:05, Alex Peshkoff wrote:
>>> Leave it to crypto-plugin. Key holder has a way to receive the
>>> information from it if
needed.
>> No, I will not. Holder may need this info before crypto-plugin started.
> Why? At
18.11.2015 14:05, Alex Peshkoff wrote:
>> Leave it to crypto-plugin. Key holder has a way to receive the
>> information from it if
>> >needed.
>> >
> No, I will not. Holder may need this info before crypto-plugin started.
Why? At this point a key holder doesn't even know if a key will be
On 11/18/2015 03:52 PM, Dimitry Sibiryakov wrote:
> 18.11.2015 13:45, Alex Peshkoff wrote:
>>> Engine then must store it at header page. When attachment to the encrypted
>>> db is
established engine extract key name and pass it to the crypto-plugin (or
key holder ?)
>> May be better bot
On 11/18/2015 03:44 PM, Dimitry Sibiryakov wrote:
> 18.11.2015 13:36, Vlad Khorsun wrote:
>> Key name could be generated by crypto-plugin (or key holder ?) when
>> database is about to be
>> encrypted. Engine then must store it at header page. When attachment to the
>> encrypted db is
>> est
18.11.2015 13:45, Alex Peshkoff wrote:
>> Engine then must store it at header page. When attachment to the encrypted
>> db is
>> >established engine extract key name and pass it to the crypto-plugin (or
>> >key holder ?)
> May be better both?
Leave it to crypto-plugin. Key holder has a way to
On 11/18/2015 03:36 PM, Vlad Khorsun wrote:
> 18.11.2015 14:04, Dimitry Sibiryakov wrote:
>> 18.11.2015 13:00, Vlad Khorsun wrote:
>>> As you really need way to identify encryption key (not a database
>>> itself) i
>>> suggest you to ask for key name (key ID) stored at header page. And it
>
18.11.2015 13:36, Vlad Khorsun wrote:
> Key name could be generated by crypto-plugin (or key holder ?) when
> database is about to be
> encrypted. Engine then must store it at header page. When attachment to the
> encrypted db is
> established engine extract key name and pass it to the crypto
18.11.2015 13:17, Dmitry Yemanov wrote:
> 18.11.2015 14:45, Dimitry Sibiryakov wrote:
>>> >> How should it be retrieved by the client?
>> >
>> > No way.
> Why do we need something that nobody can use?
To use it at server side.
At least the ID should be in gstat output. This way a user
On 11/18/2015 03:04 PM, Dimitry Sibiryakov wrote:
> 18.11.2015 13:00, Vlad Khorsun wrote:
>> As you really need way to identify encryption key (not a database
>> itself) i
>> suggest you to ask for key name (key ID) stored at header page. And it
>> already
>> was discussed recently.
> Th
18.11.2015 14:04, Dimitry Sibiryakov wrote:
> 18.11.2015 13:00, Vlad Khorsun wrote:
>> As you really need way to identify encryption key (not a database
>> itself) i
>> suggest you to ask for key name (key ID) stored at header page. And it
>> already
>> was discussed recently.
>
> This s
18.11.2015 14:45, Dimitry Sibiryakov wrote:
>> How should it be retrieved by the client?
>
> No way.
Why do we need something that nobody can use?
>> Should nbackup preserve or reset it?
>
> Preserve because technically it is the same database.
Here we disagree. It becomes a different
18.11.2015 13:00, Vlad Khorsun wrote:
> As you really need way to identify encryption key (not a database itself)
> i
> suggest you to ask for key name (key ID) stored at header page. And it already
> was discussed recently.
This solution has one problem: where this key ID must come from?
18.11.2015 13:45, Dimitry Sibiryakov wrote:
> 18.11.2015 12:38, Dmitry Yemanov wrote:
...
>> When/how should it be created for already existing ODS12
>> databases?
>
> At restore. May be - on "alter database encrypt".
As you really need way to identify encryption key (not a database itsel
18.11.2015 12:38, Dmitry Yemanov wrote:
> How should it be retrieved by the client?
No way. If someone ask for it, new item can be added to
isc_get_database_info().
> When/how should it be created for already existing ODS12
> databases?
At restore. May be - on "alter database encrypt".
18.11.2015 14:24, Dimitry Sibiryakov wrote:
>> What do you mean by "now"? v3 RC2?
>
> Tomorrow. ;) Yes, in v3 RC2.
Adding it is one part of the deal. How should it be retrieved by the
client? When/how should it be created for already existing ODS12
databases? What if application relies on it bu
18.11.2015 12:15, Dmitry Yemanov wrote:
> What do you mean by "now"? v3 RC2?
Tomorrow. ;) Yes, in v3 RC2.
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/
18.11.2015 13:59, Dimitry Sibiryakov wrote:
>
> Do I understand right that clumplets in header page are not a part of ODS, so
> subj can
> be added to them even now?
What do you mean by "now"? v3 RC2?
Dmitry
--
Firebi
Hello, All.
Do I understand right that clumplets in header page are not a part of ODS,
so subj can
be added to them even now?
--
WBR, SD.
--
Firebird-Devel mailing list, web interface at
https://lists.source
29 matches
Mail list logo
