-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS argument handling (renaming and clean-up) #584
Comments
Looks good reasonable from my side, I am just not sure whether we should also have an explicit --insecure on client side. |
Aligning implementation in kuksa-client with proposal in eclipse#584. May affect applications using kuksa-client
Aligning implementation in kuksa-client with proposal in eclipse#584. May affect applications using kuksa-client. Also removes support for client certificates as mutual authentication is not supported by Databroker
Aligning implementation in kuksa-client with proposal in eclipse#584. May affect applications using kuksa-client. Also removes support for client certificates as mutual authentication is not supported by Databroker
Note, a similar discussion is needed for authorization. Today (in Databroker) you opt-in to authorization by
|
This topic was discussed at a Community call. Participants seemed to agree that it is OK that default configuration isn't usable, that you either must specify tokens/cert or explicitly request an insecure solution. I suggest that this can be implemented after v0.4.0. so that existing integrations can use v0.4.0 rather than latest if they want the "old" behavior. |
This is a proposal on how KUKSA.val applications/libraries in the long run shall handle TLS. The background is that names as of today are a bit inconsistent. I would like us to discuss if we want to do any changes in this areas to make names more aligned
Server/Databroker
--insecure
or similar must be addedClients
Proposed names
no-tls
tls-cert
tls-private-key
tls-ca-cert
tls-server-name
The kuksa-client library supports client certificates, at least partially, but not described in user facing documentation!
Proposed Changes
The text was updated successfully, but these errors were encountered: