[//]: # (werk v2)
# Preserve search term after deletion of topics, bookmarks or custom sidebar elements
key | value
---------- | ---
date | 2024-06-11T09:15:57+00:00
version | 2.3.0p8
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
Recently, deleting topics, bookmarks or custom sidebar elements under "Customize" led to a page reload that ignored a given inpage search ("Find on this page ...").
This is fixed to preserving the search term after deletion.
Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Don't show automation secret in the audit log (addresses CVE-2024-28830)
key | value
---------- | ---
date | 2024-06-19T12:10:00+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 2
compatible | no
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/audit_log_backup". If anything goes wrong
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually by running
```
sed -i 's/Value of "automation_secret" changed from "[^"]*" to "[^"]*".\\n//g' ~/var/check_mk/wato/log/wato_audit*
sed -i 's/Attribute "automation_secret" with value "[^"]*" added.\\n//g' ~/var/check_mk/wato/log/wato_audit*
```
If the update works as expected, you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Mitigations*:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE
`CVE-2024-28830`.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Don't show automation secret in the audit log (addresses CVE-2024-28830)
key | value
---------- | ---
date | 2024-06-19T12:10:00+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 2
compatible | no
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/audit_log_backup". If anything goes wrong
during the update, you have to copy the files back to ~var/check_mk/wato/log
- and remove the automation secrets manually. If the update works as expected,
- you can remove the backup files.
+ and remove the automation secrets manually by running
+
+ ```
+ sed -i 's/Value of "automation_secret" changed from "[^"]*" to "[^"]*".\\n//g' ~/var/check_mk/wato/log/wato_audit*
+ sed -i 's/Attribute "automation_secret" with value "[^"]*" added.\\n//g' ~/var/check_mk/wato/log/wato_audit*
+ ```
+
+ If the update works as expected, you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Mitigations*:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE
`CVE-2024-28830`.
[//]: # (werk v2)
# More helpful error handling for broken plugins
key | value
---------- | ---
date | 2024-06-22T20:52:10+00:00
version | 2.3.0p8
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This only affects developers of plugins.
In case of a broken import in a plugin the resulting `ImportError` has been swallowed, making debugging very hard.
Now the error is reported on the console (to std error), and raised in debug mode (as is the case for any other exception).
[//]: # (werk v2)
# Don't crash on broken plugins unless in debug mode
key | value
---------- | ---
date | 2024-06-23T22:27:30+00:00
version | 2.3.0p8
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This is a regression in Checkmk 2.3 that only affects plugin developers.
Individual broken plugins could make the whole plugin loading crash.
Now the error is only reported, and the plugin is skipped.
For the debugging purposes, the crashing can be triggered using the `--debug` flag.
[//]: # (werk v2)
# Preserve search term after deletion of topics, bookmarks or custom sidebar elements
key | value
---------- | ---
date | 2024-06-11T09:15:57+00:00
version | 2.4.0b1
class | fix
edition | cre
component | multisite
level | 1
compatible | yes
Recently, deleting topics, bookmarks or custom sidebar elements under "Customize" led to a page reload that ignored a given inpage search ("Find on this page ...").
This is fixed to preserving the search term after deletion.
[//]: # (werk v2)
# Don't crash on broken plugins unless in debug mode
key | value
---------- | ---
date | 2024-06-23T22:27:30+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This is a regression in Checkmk 2.3 that only affects plugin developers.
Individual broken plugins could make the whole plugin loading crash.
Now the error is only reported, and the plugin is skipped.
For the debugging purposes, the crashing can be triggered using the `--debug` flag.
[//]: # (werk v2)
# More helpful error handling for broken plugins
key | value
---------- | ---
date | 2024-06-22T20:52:10+00:00
version | 2.4.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This only affects developers of plugins.
In case of a broken import in a plugin the resulting `ImportError` has been swallowed, making debugging very hard.
Now the error is reported on the console (to std error), and raised in debug mode (as is the case for any other exception).
Werk 17070 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Agent controller on Linux: More informative error message in case of file reading errors in import mode
Class: fix
Compatible: compat
Component: checks
Date: 1718987988
Edition: cre
Level: 1
Version: 2.1.0p45
On Linux systems, the agent controller always runs as the cmk-agent user, independently of the user
starting the controller. Hence, in import mode, the input file must readable by the cmk-agent user.
Otherwise, the import will fail. As of this werk, the controller displays a more informative error
message in this case, hinting at the point that the input file must be readable by cmk-agent.
------------------------------------<diff>-------------------------------------------
- Title: Agent controller on Linux: More informative error message in case of file reading erros in import mode
+ Title: Agent controller on Linux: More informative error message in case of file reading errors in import mode
? +
Class: fix
Compatible: compat
Component: checks
Date: 1718987988
Edition: cre
Level: 1
Version: 2.1.0p45
On Linux systems, the agent controller always runs as the cmk-agent user, independently of the user
starting the controller. Hence, in import mode, the input file must readable by the cmk-agent user.
Otherwise, the import will fail. As of this werk, the controller displays a more informative error
message in this case, hinting at the point that the input file must be readable by cmk-agent.