-
Notifications
You must be signed in to change notification settings - Fork 22
DBC Feeder uses TLS for connection to kuksa.val Server by default #133
Comments
The default configuration is False: https://github.com/eclipse/kuksa.val.feeders/blob/3a72e0b7230927205507e5fd96c5162cc26af56a/dbc2val/config/dbc_feeder.ini#L33 |
Not if I provide my own config file that doesn't contain the tls option, or am I mistaken? |
Ah that may be true, not sure without checking code. @erikbosch might know the answer immediately. He should be back really soon. I agree, with the original issue: It should of course be consistent between code and docs |
Let me check this for you ;-) |
In my opinion it is good that "the default is TLS unless you set it to false in config or cmd line", wile the default configfile could still be "false", as realistically that is what most people will use. It should just be reflected in the docs. |
Fair enough, then I guess we should change https://github.com/eclipse/kuksa.val.feeders/blob/3a72e0b7230927205507e5fd96c5162cc26af56a/dbc2val/dbcfeederlib/databrokerclientwrapper.py#L49 |
I have taken another look at the supported command line switches and their defaults. For example, it seems to be impossible to disable usage of TLS on the command line, neither by means of a command line switch nor by means of an environment variable. Is that intended and follows a particular pattern (which I am not able to see) or is this simply a case of not implemented yet? |
We have an issue at eclipse/kuksa.val#589 on the fact that we are not that consistent in config options and the fact that we maybe should not support all config settings as command line arguments. There has also now and then been concerns that we should not change existing (default) behavior as that may cause regressions for downstream projects, I guess that is one of the reasons why broker and server had different default behavior. I will look more in detail and create a PR to better align behavior when time permits |
We have migrated CAN Provider (dbcfeeder) to a new repo. Long term my intention is to close all dbc/can-related issues in this repository. If we see the issue as still interesting or relevant we could create a new issue in the new repo, possibly referencing the old issue in the repository. Suggested way forward:
|
The README of the dbc2val feeder suggests that the feeder will not use TLS for connecting to kuksa.val Server/Databroker.
However, ServerClientWrapper actually seems to default to using TLS.
We should either adapt the documentation or the implementation accordingly.
The text was updated successfully, but these errors were encountered: