Hi again,
One other thought I forgot to include...
On Tue, 2021-02-02 at 23:28 +0900, Tristan Van Berkom wrote:
> Hi Sander,
>
> Replies inline.
>
[...]
> * I am reading between the lines that there is an idea that
> the entire "push" configuration option is redundant, as one
> could infer this by the presence of certain credentials.
>
> It was my original naive understanding that we could get away
> with renaming the confusingly named `server-cert`, `client-cert`
> and `client-key` configurations with `pull-cert` and `push-cert`
> and `push-key`, alleviating some cognitive effort for the user.
>
> However I was mistaken about the relation here, and I don't think
> that we can infer the ability or decision to push based on what
> credentials have been provided.
>
> Instead, the "server-cert" is only needed when encrypted traffic
> is only required on the client receiving end, and the client
> cert/key are additionally required when bidirectional TLS is
> required.
>
> I think it is better to consider this requirement as an attribute
> of the client server relationship, and the implementation of the
> service, rather than to assume that two way encryption will never
> be required for activities which the client deems to be "pulling"
> or "fetching".
>
> Even though the implementations we are currently working with
> happen to require all three credentials only for push operations,
> this does not mean it will always be so, for every service
> implementation (at least, not as far as I understand).
As I am not a big fan of the "push" boolean switch either, I was also
thinking this might be more appropriate as an enumeration.
Instead of "push" being either true/false, we could have an "action"
attribute with three values: "push" / "pull" / "both".
I did not do this in the branch as of yet, but what it would provide in
addition to the current API is the ability to define push remotes where
you only want to push but want to make sure you never try to pull from
those.
However, I haven't come up with a sensible reason for a user to desire
this option, which is why I didn't change this part.
Cheers,
-Tristan
