February 2023 - openSUSE Packaging - openSUSE Mailing Lists

Announce: Conditional Build Dependencies per Project
by Thorsten Kukuk 25 Mar '23

25 Mar '23

Hi, Our base packages include support for all sorts of features, making our base OS very large due to dependencies. While this is not a problem for e.g. openSUSE Tumbleweed, where the extra packages do not really matter in the overall size, it is a big problem when building a small single-purpose OS where you want something really small without any unnecessary packages. Like ALP. The "useless" packages create yet another problem: Libraries are installed for features that are not supported or do not work. E.g. AppArmor and SELinux are exclusive, so why should e.g. ALP ship AppArmor that can't work and isn't supported, but creates a high maintenance overhead on all sides without any benefit? We use already %bcond in our spec files set in the project config for various reasons, one is to bootstrap the distro. Another reason is, that it looks like as some maintainers build already smaller versions of some packages for their need in their projects. To avoid that e.g. ALP is shipped with AppArmor and SELinux, while only SELinux will be used, we decided to "formalize" and document this: https://en.opensuse.org/openSUSE:Package_Conditional_Build_Dependencies 85% of the keywords are already used today in projects. What does this mean for you? 1. if somebody added this %bcond to your packages, please accept them and forward them to Factory. 2. if you are working on a package and have dependencies mentioned in the list, please consider to make your package configurable in this regard. 3. If we create bug reports for ALP since you are a maintainer of a core package which has dependencies we don't want to see, please work on them with a higher priority. 4. Yes, it is known that you cannot build every package without this dependencies. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

9 15

inexplicable TW Mesa packaging
by Felix Miata 11 Feb '23

11 Feb '23

# grep onlyR /etc/zypp/zypp.conf solver.onlyRequires = true # rpm -e libdrm_radeon1 libvdpau_radeonsi xf86-video-ati libvdpau_r600 error: Failed dependencies: libdrm_radeon.so.1()(64bit) is needed by (installed) Mesa-libva-22.3.2-336.1.x86_64 libdrm_radeon.so.1()(64bit) is needed by (installed) Mesa-dri-22.3.2-336.1.x86_64 libdrm_radeon.so.1()(64bit) is needed by (installed) Mesa-gallium-22.3.2-336.1.x86_64 libdrm_radeon.so.1()(64bit) is needed by (installed) Mesa-dri-nouveau-22.3.2-336.1.x86_64 # Why does Mesa in an NVidia-only GPU installation require AMDGPU/Radeon-only packages? Is this artificial requirement also true with upstream Mesa? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

2 1

Restoring/updating duo_unix (2FA)
by Daugherity, Andrew W 09 Feb '23

09 Feb '23

There used to be a duo_unix [1] package in the security repo, but it was a bit out of date. I branched it and updated it to (what was) current in my home repo [2], but unfortunately the original package was deleted before I could submit my updates. Does this mean I’ll have to create a new package from scratch and then submit that to the security repo? I’ve tried to use 'osc copypac' but it just creates a new dangling link, or completely fails if I use -e. An outstanding issue that I meant to ask this list before submitting is that Duo changed their build to statically link libduo; quoth their changelog (v1.9.20): - Link libduo statically to address issues with the ldconfig cache and incompatibilities between versions My understanding is that this should not be an issue on openSUSE, since RPM scripts will run ldconfig as needed after installation/upgrade. (And indeed, duo_unix.spec has '%post -n %{libname} -p /sbin/ldconfig’ and likewise for %postun.) I guess they have their reasons and would not want a patch reverting that, but I should create a local patch to link libduo dynamically to comply with the SUSE packaging policies, right? There are also some rpmlint warnings but I think these only apply if submitting to factory and not for the OBS security repo, right? (Although having the security team review it and getting Duo included might be good things…) ==== - pam_duo.x86_64: W: suse-pam-unauthorized-module pam_duo.so - duo_unix.x86_64: E: permissions-unauthorized-file (Badness: 100) /etc/permissions.d/duo_unix - That file has a commented-out line for applying 4755 (setuid) to login_duo, which is normally not used on Linux (pam_duo is used instead) - duo_unix.x86_64: W: missing-call-to-setgroups-before-setuid /usr/sbin/login_duo This executable is calling setuid and setgid without setgroups or initgroups. There is a high probability this means it didn't relinquish all groups, and this would be a potential security issue to be fixed. Seek POS36-C on the web for details about the problem. ==== I think the last one is a false positive since it doesn’t want to change supplementary groups (not to mention root doesn’t generally have any) and does call setgid() before setuid() [3]. But is there any reason to put pam_duo in a separate package, as whoever previously maintained this in OBS did? Duo’s repositories for e.g. Red Hat or Ubuntu just have a single duo_unix package. Obviously a separate -devel package and libduo3 make sense, but I’m not finding anything requiring this for PAM modules. Thanks, Andrew Daugherity | Systems Administrator II Technology Services – Research Technologies Texas A&M University College Station, TX 77843-1112 [1] https://github.com/duosecurity/duo_unix [2] https://build.opensuse.org/package/show/home:adaugherity:branches:security/… [3] https://github.com/duosecurity/duo_unix/blob/6c1abc27390cc4461757cf494e1cb1…

2 2