"Alex Peshkov" <pes@...> wrote:

>
> All cases you have described are something not very real.

I always have the ISC envvars defined for debugging purposes. With your
approach, I cannot use trusted authentication until I drop them, but this
will require me to specify login data explicitly in order to run e.g. v1.5
gbak. Please also consider coexisting of multiple client installs with one
of them requiring the ISC envvars.

> But getting serious - what to do, if all of
> ISC_USER/ISC_PASSWORD/isc_dpb_trusted_auth are present in DPB?

Raise an error.

> Next, it will require modification of all and any client program to be
> able to use trusted connections.

This is an important issue. But this reminds me the old situation with
INSERT RETURNING - we wrongly describe it as isc_info_stmt_exec_procedure to
please existing drivers. Personally, I consider this a wrong approach. We
should avoid making bad design decisions just to support new features
automagically in every existing software. But I see that many of you
disagree on this point.

Why do I consider this solution bad? Because I have no reliable way
(independent of the external world) to ask for the trusted authentication.
Lack of isc_user_name/isc_password in DPB does not guarantee it, as the
client library will make the decision itself, based on the found ISC
envvars. Should I test for them myself? I think I shouldn't be required to.

>> AFAIU, any new packet type should mean a protocol version bump.
>
> Certainly in the general case. And when we will implement full schema
> with plugins - this is required step. But in the short run it's pretty
> possible to live without it.

A protocol version explicitly means packet types/formats it can understand.
Everything else is generally not reliable.

> Yes, it's possible to add it manually. But it's not enough to make
> server start negotiation. You must send actual data in DPB, because
> before sending op_trusted_auth packet server validates them. And any
> wrong bit (in a chain of about 100 bytes) makes negotiation impossible.

You rely on the fact that if I'm able to send isc_dpb_trusted_auth with a
valid authentication data, then I should understand op_trusted_auth packets.
But this is a violation of the architecture (c) Jim. DPB data should have no
dependencies on the remote protocol and vice versa.

> But if you've learned to do all this - will you still use old fbclient?

It should be my choice :-) The code must be protected from illegal usage.

> And even if you have done all this - client
> should fail with protocol error and disconnect port. Nothing criminal.

A much better would be a clear error message during op_connect.

> And if we want to have real protection in protocol - what about
> Interbase and borland? The may add new kinds of packets too.

They will never do it in protocol version 10.

> We have
> good protection in ODS, but protocol seems to be unprotected. Correct me
> if I'm wrong.

We must implement the appropriate protection (similar to the ODS one) as
soon as we offer protocol version 11.


Dmitry