July 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[Bug 1171174] security enhancement: no setuid
by bugzilla_noreply＠suse.com 22 Jul '22

22 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1171174 https://bugzilla.suse.com/show_bug.cgi?id=1171174#c2 Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |georg.pfuetzenreuter(a)suse.c | |om --- Comment #2 from Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> --- Hi! According to your comment the default permission set on SLE Micro should be "paranoid". Indeed, the `config.sh` script in https://build.opensuse.org/package/view_file/SUSE:SLE-15-SP4:Update:Product… "attempts" to change the security setting with a reference to this bug but due to not specifying the "-i" flag in the `sed` line the change is merely printed and never actually written to the file: ``` # fix security level (boo#1171174) sed -e '/^PERMISSION_SECURITY=s/easy/paranoid/' /etc/sysconfig/security chkstat --set --system ``` This can be confirmed in `/etc/sysconfig/security` on a fresh copy of the SLE Micro .raw image: ``` PERMISSION_SECURITY="easy local" ``` Is this expected? Maybe I am missing something! :-) Best, Georg -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1201400] New: Unable to add a flatpak gnome repo due TLS error
by bugzilla_noreply＠suse.com 15 Jul '22

15 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201400 Bug ID: 1201400 Summary: Unable to add a flatpak gnome repo due TLS error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: michal.vyskocil(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0 Build Identifier: I've installed a fresh MicroOS Destkop 20220710, but I am unable finish the first installation or to add any flatpak repo. Reproducible: Always Steps to Reproduce: 1.flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo 2. or run mod-firstboot, but this does not provide any reasonable error Actual Results: F: Opening system flatpak installation at path /var/lib/flatpak F: Loading https://flathub.org/repo/flathub.flatpakrepo using libsoup error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate Expected Results: Repository being added. I found out that after a fresh installation neither flatpak neither curl have been working due the TLS certificates. I called sudo update-ca-certificates which fixed the curl part, but not the flatpak. I did a restart, but was the same. As this prevents me to install any application, I consider this as a major problem. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1186158] [SELinux] blocking podman socket access to /var/run/podman/podman.sock
by bugzilla_noreply＠suse.com 12 Jul '22

12 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SElinux is blocking podman |[SELinux] blocking podman |socket access to |socket access to |/var/run/podman/podman.sock |/var/run/podman/podman.sock -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 12 Jul '22

12 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c15 --- Comment #15 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Richard Brown from comment #14) > (In reply to Ludwig Nussel from comment #13) > > (In reply to Alois Wohlschlager from comment #12) > > > [...] Some concrete examples > > > TW/MicroOS experience: > > > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > > > MicroOS today. The system works without a boot splash, but it looks nicer > > > with one. > > > > Plymouth needs to be made a requirement for graphical desktops > > unfortunately. If someone desperately doesn't want it installed, the pattern > > dragging plymouth in would have to be uninstalled. > > It's also worth considering on most systems plymouth starts slower than > GDM/SDDM, so the only real-world effect of installing plymouth is often the > addition of a flicker between grub and the login prompt, a flicker which is > noticibly absent on MicroOS. > > Personally I'd rather have no flicker rather than an ugly flicker that > doesn't have time for the human brain to register the fact there could have > been an image there. Absolutely. The point is that if the OS needs plymouth because we fail to make it boot fast and need to paper over the ugly messages then plymouth must be required. Or we fix the broken boot time and render plymouth obsolete. Then it doesn't need to be listed at all. IOW if plymouth is "recommended" there's something worth fixing. > > > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > > > Requires today. A desktop system can work without printing if so desired, > > > but a significant part of the userbase appreciates their printer working. > > > > That should neither be required nor recommended. If one plugs a USB printer, > > hardware supplements are supposed to pull in required packages. I wouldn't > > be surprised if that's broken (again) on openSUSE though. Also any > > assumptions about whether or not users with local printers constitute a > > significant part of the user base are based on pure guessing related to > > personal bias :-) > > It is a clear design requirement of the MicroOS Desktop that it must be " > small, but not at the expense of functionality. Printing, Gaming, Media > Production and much more should all work." > > And such things should work "out of the box" Again I agree. That cannot mean installing cups with all drivers and ppds for all printers ever manufactured on this planet by default though. Think out of the box to find a proper solution :-) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c14 --- Comment #14 from Richard Brown <rbrown(a)suse.com> --- (In reply to Ludwig Nussel from comment #13) > (In reply to Alois Wohlschlager from comment #12) > > [...] Some concrete examples > > TW/MicroOS experience: > > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > > MicroOS today. The system works without a boot splash, but it looks nicer > > with one. > > Plymouth needs to be made a requirement for graphical desktops > unfortunately. If someone desperately doesn't want it installed, the pattern > dragging plymouth in would have to be uninstalled. It's also worth considering on most systems plymouth starts slower than GDM/SDDM, so the only real-world effect of installing plymouth is often the addition of a flicker between grub and the login prompt, a flicker which is noticibly absent on MicroOS. Personally I'd rather have no flicker rather than an ugly flicker that doesn't have time for the human brain to register the fact there could have been an image there. > > > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > > Requires today. A desktop system can work without printing if so desired, > > but a significant part of the userbase appreciates their printer working. > > That should neither be required nor recommended. If one plugs a USB printer, > hardware supplements are supposed to pull in required packages. I wouldn't > be surprised if that's broken (again) on openSUSE though. Also any > assumptions about whether or not users with local printers constitute a > significant part of the user base are based on pure guessing related to > personal bias :-) It is a clear design requirement of the MicroOS Desktop that it must be " small, but not at the expense of functionality. Printing, Gaming, Media Production and much more should all work." And such things should work "out of the box" https://en.opensuse.org/Portal:MicroOS/Desktop Therefore your 'concrete example' here is invalid and antithetical to the goals of the MicroOS Desktop Project -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c13 --- Comment #13 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Alois Wohlschlager from comment #12) > Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. That's the theory. In practice we ended up with a mess and without soft locks. Now those recommends are just a pita, haunting you if you don't also lock packages :-) They might be ok actually for something like, say FreeCAD, ie some extra app that you will for sure install manually and interactively. So the UI can show you specifically for that app what it recommends. For the thousands of OS components the recommends just lead to not seeing the forest for all the trees though. We'd be better off trying harder to avoid them. > [...] Some concrete examples > TW/MicroOS experience: > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > MicroOS today. The system works without a boot splash, but it looks nicer > with one. Plymouth needs to be made a requirement for graphical desktops unfortunately. If someone desperately doesn't want it installed, the pattern dragging plymouth in would have to be uninstalled. > (Same with the language magic this issue is about, but I don't > understand how it works exactly. The locale is some kind of virtual provides of the system and packages containing localization files supplement that. Hardware supplements work in a similar way. > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > Requires today. A desktop system can work without printing if so desired, > but a significant part of the userbase appreciates their printer working. That should neither be required nor recommended. If one plugs a USB printer, hardware supplements are supposed to pull in required packages. I wouldn't be surprised if that's broken (again) on openSUSE though. Also any assumptions about whether or not users with local printers constitute a significant part of the user base are based on pure guessing related to personal bias :-) > As a concrete example again, the x11 -> x11_enhanced -> web_browser > Recommends chain does make sense on traditional systems. On MicroOS not so > much, since you just install the browser using Flatpak. Also in that case the recommends should be removed IMO. Default applications can be pulled in by a specific pattern that is added explicitly by YaST when selecting a desktop via role. No need to express this via dependencies. But then maybe we should also stop treating the traditional desktop install as the Linux desktop demo show we have currently. We can do it like in MicroOS. Basic desktop only, ie fast install. Then have eg opensuse-welcome suggest a bunch of common apps with a nice UI on first boot. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c12 --- Comment #12 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- (In reply to Ludwig Nussel from comment #11) > If you have such a list already, a first approach could also be to try to > simply file sr's to eliminate those recommends. That's what I did in the > past with some packages and generally didn't get much pushback. Mind trying? > :-) I don't really have a list handy, but I definitely can (and in fact planned to) try to create such a list (part of that will involve tracking down the SELinux -> Jupyter madness, which will most likely result in a SR). However, just eliminating these recommends unconditionally won't work, see below why. I will answer your other two points in the opposite order that you have mentioned them, since I think this is more logical. > I'd prefer to get rid of recommends. As OS vendor we > have to decide whether a package is needed or not. A stricter definition of > what is a mandatory part of the OS really helps in other areas too (eg > transactional-update status). That decision was already made, and such a definition already exists: it's called Requires. We already have that situation in today's MicroOS. Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. Some concrete examples TW/MicroOS experience: * enhanced_base -> plymouth: This is a Recommends, so it's not installed on MicroOS today. The system works without a boot splash, but it looks nicer with one. (Same with the language magic this issue is about, but I don't understand how it works exactly. Emoji fonts and color management are also in this category.) * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a Requires today. A desktop system can work without printing if so desired, but a significant part of the userbase appreciates their printer working. With Recommends, everyone can have a good experience, while users can choose to slim their systems down further. In a world without Recommends, this option doesn't exist any more: in order not to bloat everyone's system, many "nice to have" things have to be left out, leading to degraded experience after installation (of course you can install these things after the fact, but that's not user-friendly at all). > Yes that is likely possible via boolean dependencies. I wonder whether it's > really needed though. As a concrete example again, the x11 -> x11_enhanced -> web_browser Recommends chain does make sense on traditional systems. On MicroOS not so much, since you just install the browser using Flatpak. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c11 --- Comment #11 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Alois Wohlschlager from comment #7) > What about enabling recommends, but shipping targeted locks to prevent > installation of the worst offenders by default? That's what I currently do > on my MicroOS system, since no-recommends is too barebones, and with my > approach I get the bloat down quite a bit If you have such a list already, a first approach could also be to try to simply file sr's to eliminate those recommends. That's what I did in the past with some packages and generally didn't get much pushback. Mind trying? :-) (In reply to Alois Wohlschlager from comment #10) > (In reply to Richard Brown from comment #8) > > > > Locks are a terrible cludge that just result in broken systems > > Ok, understood that this is not a generally applicable solution. > > > I'm all for installing all language patterns all the time, I'm not for > > installing GB and GB of random junk alongside them > > Well, but recommends are not supposed to be "random junk" anyway, but rather > "generally useful, but not strictly required". Where they do pull in random > junk, I see basically three categories: > 1a. Things that are generally useful on traditional systems, but not on > MicroOS (e.g. pulling in YaST or Firefox from various desktop patterns). > Does zypp have a way to express something like "Recommends: (MicroOS or > yast2)"? If so, these could be used for a fix. Yes that is likely possible via boolean dependencies. I wonder whether it's really needed though. I'd prefer to get rid of recommends. As OS vendor we have to decide whether a package is needed or not. A stricter definition of what is a mandatory part of the OS really helps in other areas too (eg transactional-update status). > 1b. Compatibility-related, but rarely useful things, I mainly think of the > kernel's "Recommends: kernel-firmware" here. This could be fixed the same > way as 1a. > 2. Things which are arguably plain bugs, such as pulling in Jupyter from > some SELinux-related packages. These should be fixed anyway. +1 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188939] SELinux prevents podman from being run as a systemd service and from being updated
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1188939 https://bugzilla.suse.com/show_bug.cgi?id=1188939#c2 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NORESPONSE --- Comment #2 from Johannes Segitz <jsegitz(a)suse.com> --- Please reopen if you can still reproduce this -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 09 Jul '22

09 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c10 --- Comment #10 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- (In reply to Richard Brown from comment #8) > > Locks are a terrible cludge that just result in broken systems Ok, understood that this is not a generally applicable solution. > I'm all for installing all language patterns all the time, I'm not for > installing GB and GB of random junk alongside them Well, but recommends are not supposed to be "random junk" anyway, but rather "generally useful, but not strictly required". Where they do pull in random junk, I see basically three categories: 1a. Things that are generally useful on traditional systems, but not on MicroOS (e.g. pulling in YaST or Firefox from various desktop patterns). Does zypp have a way to express something like "Recommends: (MicroOS or yast2)"? If so, these could be used for a fix. 1b. Compatibility-related, but rarely useful things, I mainly think of the kernel's "Recommends: kernel-firmware" here. This could be fixed the same way as 1a. 2. Things which are arguably plain bugs, such as pulling in Jupyter from some SELinux-related packages. These should be fixed anyway. > We should have this fixed in the install media somewhen soon..then we just > need to find a solution for pre-built images also I see two problems with this approach: * It's not just about language packs, some other things like boot splash, emoji fonts, color management, and hardware support are also at least nice to have, but currently not installed on MicroOS. Duplicating the work already done is brittle, and probably more work than fixing the few suboptimal recommends. * If some user, for some reason, wants a special-purpose, ultra-minimal system without language packs or the like, they cannot just uninstall the recommended package any more, because it's now required from somewhere. -- You are receiving this mail because: You are the assignee for the bug.

1 0