- openSUSE Bugs

[Bug 1228075] Networkmanager: configure Hybrid bridge port and indefinite waiting connecting because slave interfaces are not coming up
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1228075 https://bugzilla.suse.com/show_bug.cgi?id=1228075#c4 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |UPSTREAM Status|NEW |RESOLVED CC| |fvogt(a)suse.com Flags|needinfo?(chcao(a)suse.com) | --- Comment #4 from Fabian Vogt <fvogt(a)suse.com> --- Can you please file this upstream at bugs.kde.org? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190766] python-rich backports requirement
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1190766 https://bugzilla.suse.com/show_bug.cgi?id=1190766#c7 Hui-Zhi Zhao <hui.zhi.zhao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(hui.zhi.zhao@suse | |.com) | --- Comment #7 from Hui-Zhi Zhao <hui.zhi.zhao(a)suse.com> --- I am sorry for the late reply! Thank you, it meets my requirement. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1230643] [SELinux] semodule removal issues
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230643 https://bugzilla.suse.com/show_bug.cgi?id=1230643#c8 --- Comment #8 from Cathy Hu <cathy.hu(a)suse.com> --- (ftr, its just to confirm/not confirm my suspicion about the issue, it will probably not fix it longterm) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190766] python-rich backports requirement
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1190766 https://bugzilla.suse.com/show_bug.cgi?id=1190766#c6 --- Comment #6 from Nathan Cutler <ncutler(a)suse.com> --- In SLE-15-SP6 we have python311-CommonMark version 0.9.1 which should meet the requirement as long as python-rich is changed to build for Python 3.11, and it looks like that has already happened at: https://build.opensuse.org/package/show/devel:languages:python/python-rich And I see that python311-rich is already available in SLE-15-SP6 and SLE-15-SP7 via the Python3 module, so this no longer has anything to do with Backports anymore. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1230643] [SELinux] semodule removal issues
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230643 Cathy Hu <cathy.hu(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(anton.smorodskyi@ | |suse.com) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1230643] [SELinux] semodule removal issues
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230643 https://bugzilla.suse.com/show_bug.cgi?id=1230643#c7 --- Comment #7 from Cathy Hu <cathy.hu(a)suse.com> --- hmm i had a bit of time to look into this again, sorry for the delay is /var/lib/selinux/targeted/active/modules/100/ajaxterm/ existing but empty? if so, could you try to delete the folder and check if it fixes your problem? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234565] New: VUL-0: CVE-2024-45337: git-bug: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234565 Bug ID: 1234565 Summary: VUL-0: CVE-2024-45337: git-bug: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: mcepl(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1232951] New: VUL-0: CVE-2024-51744: traefik: github.com/golang-jwt/jwt/v4: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1232951 Bug ID: 1232951 Summary: VUL-0: CVE-2024-51744: traefik: github.com/golang-jwt/jwt/v4: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/426863/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-51744:3.1:(AV:N/AC:H/PR:N/UI:R/ S:U/C:L/I:N/A:N) Severity: Normal Priority: P5 - None Component: Security Assignee: alexandre.vicenzi(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1232936 Target Milestone: --- Found By: --- Blocker: --- golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-51744 https://www.cve.org/CVERecord?id=CVE-2024-51744 https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d19706… https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r https://bugzilla.redhat.com/show_bug.cgi?id=2323735 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1232964] New: VUL-0: CVE-2024-51744: rclone: github.com/golang-jwt/jwt/v4: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1232964 Bug ID: 1232964 Summary: VUL-0: CVE-2024-51744: rclone: github.com/golang-jwt/jwt/v4: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/426863/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-51744:3.1:(AV:N/AC:H/PR:N/UI:R/ S:U/C:L/I:N/A:N) Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1232936 Target Milestone: --- Found By: --- Blocker: --- golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-51744 https://www.cve.org/CVERecord?id=CVE-2024-51744 https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d19706… https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r https://bugzilla.redhat.com/show_bug.cgi?id=2323735 -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1234629] New: sendmail: embeds uname -r
by bugzilla_noreply＠suse.com 17 Dec '24

17 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234629 Bug ID: 1234629 Summary: sendmail: embeds uname -r Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: werner(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1101107 Target Milestone: --- Found By: Development Blocker: --- While working on reproducible builds for openSUSE, I found that our sendmail debuginfo package embeds the build machine's kernel version. With my reproducibleopensuse tools, I do debuginfo=--debuginfo vmtype=--vm-type=podman rbk Here is a helpful part of the diff: filterdiff strings R*/usr/lib/debug/.dwz/sendmail-8.18.1-1.1.x86_64 --- strings RPMS.1/usr/lib/debug/.dwz/sendmail-8.18.1-1.1.x86_64 +++ strings RPMS.2/usr/lib/debug/.dwz/sendmail-8.18.1-1.1.x86_64 @@ -316,16 +316,16 @@ /usr/include/bits/types ../../include/libsmdb ../../include/sm -/usr/src/debug/sendmail-8.18.1/obj.Linux.6.11.8-1-default.x86_64/libsm +/usr/src/debug/sendmail-8.18.1/obj.Linux.6.6.63-1-longterm.x86_64/libsm -- You are receiving this mail because: You are on the CC list for the bug.

1 4