Hi, This all makes sense to me. Once the migration is done again, I'll file an issue for RE Scenario 2, such that we don't forget :-).
Cheers, Sander On Wed, Feb 3, 2021 at 7:50 AM Tristan Van Berkom < [email protected]> wrote: > 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 > > >
