Dmitry Yemanov wrote:

>
> 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.
>

OK for server side.

>
>>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.

That's are serious issues. What about the compromise? We let user
specify trusted authentication flag in DPB, and if it is present -
ignore environment, exactly like we do when there are explicit login /
password in DPB.

>>>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.
>

OK.

>>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.
>

This is what I see in vulcan sources:

/* Protocol 11 adds the new Firebird account management functions,
fb_update_account_info
* and fb_authenticate_user
*/

#define PROTOCOL_VERSION11 11

And no protection at all!

Right now I suppose to:
1. Switch to PROTOCOL_VERSION11.
2. Add isc_wish_list() implementation for op_update_account_info and
op_authenticate_user.
3. Move op_authenticate_user opcode to match vulcan's rules.
4. Add 'trusted' switch to isql and qli.
5. And I ask Jim to add minimal op_trusted_auth to vulcan.

And we should discuss protocol version protection in separate thread.