Subject | Re: [Firebird-Architect] RC4 |
---|---|
Author | Geoff Worboys |
Post date | 2010-11-14T23:44:48Z |
Hi Jim,
A few last comments and then I'll leave you alone.
Jim Starkey wrote:
that others prove to have better reading comprehension skills.
Suggesting a preference to use well studied security protocols
and solutions is a far cry suggesting Firebird, or it's users,
don't address the problem.
the case of Firebird, it is not possible to externalise the
key distribution problem. At the very least the idea opened
earlier by Dmitry and Roman seemed to offer one solution but
it seems unlikely to be the only one.
supported protocols on the existing port or you can choose to
have two separate ports, one for secured connections and one
for unsecured.
Since you admit that addressing the problem requires changes to
the client and server and protocol, I fail to see why such
changes could not include the move to an external protocol ...
in fact it seems an ideal time to make the change, so that
Firebird is not locked into a single solution.
If you embed some custom security protocol inside Firebird you
haven't actually solved all that much - once it's broken you
have to turn around and do it again (and face all the same
issues you face now). Make the changes externalise the problem
and you enable Firebird (or it's users) to move between
protocols as needed or appropriate.
--
Geoff Worboys
Telesis Computing
A few last comments and then I'll leave you alone.
Jim Starkey wrote:
> [...] There are two approaches to these problems. The mostI do object to you putting words in my mouth, I can only hope
> most discussed is to ignore them -- let somebody else worry
> about. Geoff and others have worked long and hard find
> reasons that Firebird shouldn't or can't address the
> problems. That's bunk. The other approach is to fix it.
that others prove to have better reading comprehension skills.
Suggesting a preference to use well studied security protocols
and solutions is a far cry suggesting Firebird, or it's users,
don't address the problem.
> Fixing Firebird security isn't as simple as supportingAnd this just astounds me. Perhaps you could explain why, in
> encryption plugins because plugins can't address the key
> distribution problem. [...]
the case of Firebird, it is not possible to externalise the
key distribution problem. At the very least the idea opened
earlier by Dmitry and Roman seemed to offer one solution but
it seems unlikely to be the only one.
> Addressing the problem requires changes to the client, theI fail to see a big problem. You can choose to switch between
> protocol, and the server. Complicating the solution is the
> honorable tradition of allowing older clients to communicate
> with newer servers and vice versa.
supported protocols on the existing port or you can choose to
have two separate ports, one for secured connections and one
for unsecured.
Since you admit that addressing the problem requires changes to
the client and server and protocol, I fail to see why such
changes could not include the move to an external protocol ...
in fact it seems an ideal time to make the change, so that
Firebird is not locked into a single solution.
If you embed some custom security protocol inside Firebird you
haven't actually solved all that much - once it's broken you
have to turn around and do it again (and face all the same
issues you face now). Make the changes externalise the problem
and you enable Firebird (or it's users) to move between
protocols as needed or appropriate.
--
Geoff Worboys
Telesis Computing