Remove securesystemslib.settings #219
Labels
legacy
Issues related to legacy interfaces (obsolete with #731)
Comments
|
Makes sense to me. Thanks for suggesting this! |
This was referenced Feb 4, 2021
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 9, 2023
Prior to this commit, settings.SUBPROCESS_TIMEOUT=3 (seconds) was used as default and also to configure timeouts for any subprocess spawned via the securesystemslib process interface, including running the gpg command to sign, export keys and check version. The small timeout regularly lead to test failures on slow test runners. Furthermore, configuring the timeout via global is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). This patch defines a custom constant, to be used only for gpg subprocesses and increases its value to 10 seconds. To override this default, an optional timeout argument will be added to relevant gpg interfaces in a subsequent commit. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 9, 2023
Prior to this change, configuring timeouts for gpg required patching the default-specifying global. This is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). To allow overriding default timeout in an intuitive way, this commit adds optional arguments to the relevant gpg interface functions. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 9, 2023
Prior to this commit, settings.SUBPROCESS_TIMEOUT=3 (seconds) was used as default and also to configure timeouts for any subprocess spawned via the securesystemslib process interface, including running the gpg command to sign, export keys and check version. The small timeout regularly lead to test failures on slow test runners. Furthermore, configuring the timeout via global is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). This patch defines a custom constant, to be used only for gpg subprocesses and increases its value to 10 seconds. To override this default, an optional timeout argument will be added to relevant gpg interfaces in a subsequent commit. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 9, 2023
Prior to this change, configuring timeouts for gpg required patching the default-specifying global. This is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). To allow overriding default timeout in an intuitive way, this commit adds optional arguments to the relevant gpg interface functions. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 10, 2023
Prior to this commit, settings.SUBPROCESS_TIMEOUT=3 (seconds) was used as default and also to configure timeouts for any subprocess spawned via the securesystemslib process interface, including running the gpg command to sign, export keys and check version. The small timeout regularly lead to test failures on slow test runners. Furthermore, configuring the timeout via global is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). This patch defines a custom constant, to be used only for gpg subprocesses and increases its value to 10 seconds. To override this default, an optional timeout argument will be added to relevant gpg interfaces in a subsequent commit. Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Feb 10, 2023
Prior to this change, configuring timeouts for gpg required patching the default-specifying global. This is bad practice and error-prone (see secure-systems-lab#219, secure-systems-lab#345). To allow overriding default timeout in an intuitive way, this commit adds optional arguments to the relevant gpg interface functions. Signed-off-by: Lukas Puehringer <[email protected]>
3 tasks
lukpueh
added
legacy
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Apr 10, 2024
With the removal of legacy key modules, settings is no longer used or needed. fixes secure-systems-lab#219 Signed-off-by: Lukas Puehringer <[email protected]>
lukpueh
added a commit
to lukpueh/securesystemslib
that referenced
this issue
Apr 12, 2024
With the removal of legacy key modules, settings is no longer used or needed. fixes secure-systems-lab#219 Signed-off-by: Lukas Puehringer <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
NOTE: this is a meta-bug/milestone.
Description of issue or feature request:
The settings module is a legacy of securesystemslib originating as part of the tuf reference implementation and results in awkward cohesion between securesystemslib and its users.
The settings module is a prime example of this, there are places in securesystemslib where modifying the behaviour of a function requires changing values in
securesystemslib.settings, which is non-intuitive. Particularly as many of the settings are only documented as comments in that file.This meta-bug tracks the goal/milestone of removing
securesystemslib.settingsand should be linked to smaller, more tractable and more specific issues.Current behavior:
Users have to modify securesystemslib internal settings, rather than being able to pass all required information as arguments to library functions.
Expected behavior:
Users are not required to modify internal library settings and can pass all required configuration values as arguments to the functions they are using.
The text was updated successfully, but these errors were encountered: