Subject | Re: [Firebird-Architect] Re: database encryption |
---|---|
Author | Dmitry Yemanov |
Post date | 2010-11-08T18:35:37Z |
Roman,
encryption thing though. Personally, I see it as a future Firebird
architecture targeted to even tighter integration. The engine exposes
the hooks that the host process (Firebird server or user application)
implements for the core operation set (mostly access to different
resources). My first thoughts were about configuration (the engine
should never read the .conf files, it should be provided with the
ready-to-use configuration instead) and logging (the engine should not
write anything into firebird.log itself).
The next thought was about the storage (PIO etc), but here I see some
problems. For example, the engine behavior much depends on various I/O
options like buffered/unbuffered, persistent/temporary, filesystem/raw,
etc. Sometimes it's already hard to guess whether some OS supports them
in the required way and it gets even more complicated in the case of the
pluggable storage. So it seems we'll need some extra features, i.e.
request the storage about its supported capabilities and adjust the way
the engine works based on that. Surely possible, just somewhat beyond
the current PIO interface.
Dmitry
> I was thinking rather in the direction of statically linking FirebirdI had this kind of thinking as well, separately from the whole
> database engine (not server) in something bigger, and that bigger
> provides its own means for remote protocol (if any), encrypted storage,
> key management, tampering detection, etc.
>
> So, basically, instead of concentrating on a dynamically loadable
> encryption provider, we (project) concentrate on making FB embeddable
> for those that need it - i.e. clean separation of the remote code
> (already done), all PIO stuff (partly done, temp files), gbak and
> nbackup, etc.
>
> I see Firebird server as a default implementation of the remote protocol
> and PIO code that embeds Firebird engine and is accompanied by all the
> drivers, tools, etc. People that need more, should be able to
> concentrate on the parts where they are strong and do not dig deep into
> FB internals, and vice versa. We might provide something simple to
> address the mass market, but that is a side effect.
encryption thing though. Personally, I see it as a future Firebird
architecture targeted to even tighter integration. The engine exposes
the hooks that the host process (Firebird server or user application)
implements for the core operation set (mostly access to different
resources). My first thoughts were about configuration (the engine
should never read the .conf files, it should be provided with the
ready-to-use configuration instead) and logging (the engine should not
write anything into firebird.log itself).
The next thought was about the storage (PIO etc), but here I see some
problems. For example, the engine behavior much depends on various I/O
options like buffered/unbuffered, persistent/temporary, filesystem/raw,
etc. Sometimes it's already hard to guess whether some OS supports them
in the required way and it gets even more complicated in the case of the
pluggable storage. So it seems we'll need some extra features, i.e.
request the storage about its supported capabilities and adjust the way
the engine works based on that. Surely possible, just somewhat beyond
the current PIO interface.
Dmitry