March 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1164084] New: Sendmail upstream security bug report
by bugzilla_noreply＠novell.com 05 Apr '23

05 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1164084 Bug ID: 1164084 Summary: Sendmail upstream security bug report Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: All OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- - Add upstream patch 8.15.2.mci.p0 * If sendmail tried to reuse an SMTP session which had already been closed by the server, then the connection cache could have invalid information about the session. One possible consequence was that STARTTLS was not used even if offered. -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 1209517] New: [Build 20230317] openQA test fails in reboot_plasma5
by bugzilla_noreply＠suse.com 05 Apr '23

05 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209517 Bug ID: 1209517 Summary: [Build 20230317] openQA test fails in reboot_plasma5 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 URL: https://openqa.opensuse.org/tests/3183060/modules/rebo ot_plasma5/steps/55 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: fvogt(a)suse.com Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-NET-aarch64-zdup-Leap-15.3-kde@aarch64 fails in [reboot_plasma5](https://openqa.opensuse.org/tests/3183060/modules/reboot_pl… This problem appears ONLY on KDE upgrade scenarios from Leap 15.3. Update from previous Tumbleweed snapshot is fine, as well as upgrade from Leap 15.2. ## Test suite description ## Reproducible Fails since (at least) Build [20230317](https://openqa.opensuse.org/tests/3181474) ## Expected result Last good: [20230315](https://openqa.opensuse.org/tests/3179278) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1206952] New: lxd fail with new btrfs
by bugzilla_noreply＠suse.com 05 Apr '23

05 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206952 Bug ID: 1206952 Summary: lxd fail with new btrfs Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: werwolf131313(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- > lxc launch images:opensuse/15.4 test > Creating test > Error: Failed instance creation: Failed creating instance from image: Failed to run: btrfs qgroup create 0/4135 /var/lib/lxd/storage-pools/lxd-pool/images/9fac0fafb956a6ef1dee274f6694e22de1c94b20cade2f6c2a848b3a163945a3: exit status 1 (ERROR: unable to create quota group: File exists) fixed here: https://github.com/lxc/lxd/issues/11210 a rebuild of the package with this patch is required. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1206346] New: go1.20 release tracking
by bugzilla_noreply＠suse.com 05 Apr '23

05 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206346 Bug ID: 1206346 Summary: go1.20 release tracking Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: jkowalczyk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- go1.20 (expected February 2023) is a major release of Go. Minor releases of go1.20.x will be provided through February 2024. This issue tracks go1.20.x releases packaged and submitted initially to openSUSE:Factory and can be referenced in submissions to additional repositories. Go Release Cycle https://github.com/golang/go/wiki/Go-Release-Cycle Go Release history https://golang.org/doc/devel/release.html -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1189960] New: cleanup: remove or document patches.suse/btrfs-8447-serialize-subvolume-mounts-with-potentially-mi.patch
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1189960 Bug ID: 1189960 Summary: cleanup: remove or document patches.suse/btrfs-8447-serialize-subvolume-mounts-wit h-potentially-mi.patch Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: dsterba(a)suse.com Reporter: jeffm(a)suse.com QA Contact: jeffm(a)suse.com Blocks: 1189946 Found By: --- Blocker: --- This is an automated report to queue a potentially obsolete patch for removal. The patch patches.suse/btrfs-8447-serialize-subvolume-mounts-with-potentially-mi.patch will be removed from the master branch in 30 days if the assignee does not remove it before then. Alternatively, the assignee may update the patch tags and this report to indicate what efforts are being made to land the patch in the upstream kernel or to justify why it should require ongoing maintenance effort. Thank you for your cooperation. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1187511] New: Mint Y GTK Theme Uses Green for All Variants
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1187511 Bug ID: 1187511 Summary: Mint Y GTK Theme Uses Green for All Variants Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: CheeseEBoi(a)mailo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When using the Mint Y GTK Theme from the repositories, all color variants of the theme use green for the highlights aside from the window controls. Both light and dark versions have this problem but the window decoration theme does not. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1209741] New: pam session keyring creating during KDE GUI login not available to cifscreds
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209741 Bug ID: 1209741 Summary: pam session keyring creating during KDE GUI login not available to cifscreds Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: jmscdba(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- *** Background Info Please note that although I am reporting this bug against TW 20230324 the bug actually started occurring with builds created roughly 6 to 9 months ago. I did not submit earlier because I was having trouble with how to best document the situation to allow you to easily replicate the bug. After reading the Linux-PAM System Administrators Guide, I come up with the following steps to document the bug. I went with most recent TW build in a VM to replicate the problem so that you could easily do the same in your debugging, however, the problem occurs on all of my TW installs on other machines which have been zypper dup'd for years. There are NO changes to the newly installed system and it is using the default configuration for everything. *** Short description of the problem Based on my test case research it appears that one of the following is the source of the problem: 1) Either pam_keyinit.so is not creating the session keyring during login or it is somehow created but does not end up attached correctly to the user's GUI login session. 2) cifscreds is not reading/finding the session keyring *** Research and Steps to Recreate the problem Perform new TW build 20230324 installation As mentioned above this replicates on my other TW machines which have been update for years but I used this as a base so that all of the default configuration is in place. After installation is completed the rest of the steps are performed using my joe user logged into KDE and from a konsole prompt. keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 cifscreds add -u joe fileserver Warning: you have no persistent session keyring. cifscreds keys will not persist after this process exits. See pam_keyinit(8). Since cifscreds says there is no persistent keyring the credentials do not exist after cifscrds terminates as shown by the following: keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 Based on those results it "appears" that either cifscreds is not finding the session keyring and therefore that is the problem OR pam_keyinit.so is somehow not creating a new session keyring ( but it seems to be creating it based on the above ) or it is creating in a way that is not seen by the cifscreds program. Since cifsceds is unable to add the user credentials to the session keyring and have them persist this means that the user cannot access CIFS shares which have been mounted with the multiuser mount option. In testing further I tried the following: Show starting point keyrings again keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 Create a new session keyring using: keyctl session Joined session keyring: 446515518 Show keyring state after creating new one keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 446515518 --alswrv 1000 1000 keyring: _ses Attempt to add credentials to newly created keyring cifscreds add -u joe fileserver No warning is displayed and credentials are added to the newly created session keyring keyctl show @s Keyring 446515518 --alswrv 1000 1000 keyring: _ses 480791877 ----sw-v 1000 1000 \_ logon: cifs:a:192.168.1.1 User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Note that I did not include the mount steps ( done as root ) because they are not part of the problem, as the real issue is with the session keyring not being available when cifscreds is run. My initial thought that something was wrong with cifscreds, however, the following test seems to confirm that the actual problem is with the PAM configuration and how pam_keyinit.so is creating the session keyring when logging into the KDE GUI. To perform this test to demonstrate that: Reboot the machine to start clean Instead of logging into KDE GUI press Ctrl+Alt+F1 to get a console. login keyctl show @u Keyring 766463839 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 576175083 --alswrv 1000 1000 keyring: _ses 766463839 --alswrv 1000 65534 \_ keyring: _uid.1000 cifscreds add -u joe fileserver No warning is displayed and credentials are successfully added keyctl show @u Keyring 766463839 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 576175083 --alswrv 1000 1000 keyring: _ses 766463839 --alswrv 1000 65534 \_ keyring: _uid.1000 673617333 ----sw-v 1000 1000 \_ logon: cifs:a:192.168.1.1 User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Since the session keying and cifscreds work correctly from the tty console but do NOT when you log into the KDE GUI and do the exact same thing it would appear that something is wrong with how pam_keyinit is creating the session keyring and it being available in when logging into the GUI. I have tried varies other tests to see if I could "fix" the default pam config to resolve the issue which did not work. As I final test I tried the following: NOTE: I understand that we should NOT modify the /etc/pam.d/common-*-pc files and I only did this as a test to see if it resolved the issue and recognize that the real fix is/may be something totally different. Modify /etc/pam.d/common-session-pc to add the following to the end session optional pam_keyinit.so revoke force reboot login to KDE gui cifscreds add -u joe fileserver No warning is displayed and credentials are successfully added User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Other research grep -ir 'pam_keyinit.so' /etc/pam.d/* /usr/lib//pam.d/* Shows that it is included in MANY pam config files man pam_keyinit.so says The pam_keyinit PAM module ensures that the invoking process has a session keyring other than the user default session keyring. In order to allow other PAM modules to attach tokens to the keyring, this module provides both an auth (limited to pam_setcred(3) and a session component. The session keyring is created in the module called. Moreover this module should be included as early as possible in a PAM configuration. man cifscreds NOTES say The cifscreds utility requires a kernel built with support for the login key type. That key type was added in v3.3 in mainline Linux kernels. Since cifscreds adds keys to the session keyring, it is highly recommended that one use pam_keyinit to ensure that a session keyring is established at login time. *** Conclusion It appears that the session keyring is being creating improperly during GUI login such that cifscreds cannot use it, possibly it is not attached to the correct process ? This item on kernel org is from 2012 !!! https://patchwork.kernel.org/project/cifs-client/patch/1342704916-2224-1-gi… Seems to describe the problem I am seeing and also demonstrated how the issue does not exist at the tty console ( Ctrl+Alt+F1 ) but did when done from the GUI ( xfec4 in that case ) they have the same issue I am reporting. In one of the comments where somebody tested on a fairly stock Fedora 17 they said An excellent question. I see the same behavior on a fairly stock Fedora 17 host too. I can only assume that the actual desktop session is ending up with a different keyring session than gdm had. It sure seems like that old issue is exactly what I am seeing here since the Ctrl+Alt+F1 console does not have the issue and the GUI login does. The bottom line is that something is wrong with the default pam config for pam_keyinit.so when you log into the KDE GUI such that the session keyring is not seen/available to cifscreds and adding to common-session-pc works around the issue for now but may not be the best solution or could have other security issues. I suspect that the real solution is to make sure that KDE GUI login has the session keyring created in the same way and attached to the same process as the Ctrl+Alt+F1 login. I am happy to perform any other tests or gather other information just provide the steps for whatever other information you need. Hopefully this very detailed bug report provides you with most of the legwork completed to debug and now we only need the fix created. -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1198621] New: systemd-boot: mach bunt
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1198621 Bug ID: 1198621 Summary: systemd-boot: mach bunt Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: snwint(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1198583 Found By: --- Blocker: --- If we go for systemd-boot we need it to look nice. How about gfxboot for it? :-) -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1146936] New: nmcli-examples: add examples of bonding + vlan + bridge
by bugzilla_noreply＠novell.com 04 Apr '23

04 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1146936 Bug ID: 1146936 Summary: nmcli-examples: add examples of bonding + vlan + bridge Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: william.brown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Configuring a bond + vlan + bridge is not completely straightforward or clear with nmcli. An example should be added such as: nmcli conn add type bond con-name bond0 ifname bond0 mode 802.3ad ipv4.method disabled ipv6.method ignore nmcli connection add type ethernet con-name bond0-eth1 ifname eth1 master bond0 slave-type bond nmcli connection add type ethernet con-name bond0-eth2 ifname eth2 master bond0 slave-type bond nmcli connection add type bridge con-name net_18 ifname net_18 ipv4.method disabled ipv6.method ignore nmcli connection add type vlan con-name bond0.18 ifname bond0.18 dev bond0 id 18 master net_18 slave-type bridge This is suitable for libvirt/vms to use the bridges. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1176818] New: Wrong public keys in openSUSE-build-key for verifying container image signatures
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1176818 Bug ID: 1176818 Summary: Wrong public keys in openSUSE-build-key for verifying container image signatures Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: meissner(a)suse.com Reporter: rhafer(a)suse.com QA Contact: qa-bugs(a)suse.de CC: sgrunert(a)suse.com Found By: --- Blocker: --- The openSUSE-build-keys package contains /usr/lib/rpm/gnupg/keys/opensuse-container-key.asc and /usr/lib/rpm/gnupg/keys/suse-container-key.asc which symlink to the "openSUSE Project Signing Key <opensuse(a)opensuse.org>" and "SuSE Package Signing Key <build(a)suse.de>" but apparently the images we provide on registry.opensuse.org are signed by some other key. When enabling signature verification for "registry.opensuse.org" using the key "/usr/lib/rpm/gnupg/keys/opensuse-container-key.asc" all images fail to verify because the images are signed with a different key. Looking into the signatures, which are fetched from "https://registry.opensuse.org/sigstore/" it seem the images are signed by a key with the ID "D754694F9AB48CE9". The key in /usr/lib/rpm/gnupg/keys/opensuse-container-key.asc however AFAICS is: "B88B2FD43DBDC284". So something is wrong here. -- You are receiving this mail because: You are on the CC list for the bug.

1 4