January 2023 - openSUSE Packaging - openSUSE Mailing Lists

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

Memory problems at build time
by Eric Schirra 25 Jan '23

25 Jan '23

Hello all, I have now noticed with a wide variety of packages that they build in OBS itself, but not locally using osc. It comes then memory error. e.g.: RangeError: WebAssembly.Instance(): Out of memory: wasm memory As said on the OBS server online the packages are built. But not locally. Does anyone know this? Do others have this problem? Is there a solution? What do I have to do then? I would be very grateful for any help. Regards Eric

6 10

spec sources with spaces in filename (rpm 4.18)
by Manfred Schwarb 25 Jan '23

25 Jan '23

Hi, In a package, I have a source file with spaces in it: Source: Mobile Atlas Creator %{version}.zip ... %prep %setup -q -c -n mobac This used to work fine, and resulted in: [ 76s] + cd /home/abuild/rpmbuild/BUILD [ 76s] + rm -rf mobac [ 76s] + /usr/bin/mkdir -p mobac [ 76s] + cd mobac [ 76s] + /usr/bin/unzip -qq '/home/abuild/rpmbuild/SOURCES/Mobile Atlas Creator 2.3.0.zip' [ 77s] + STATUS=0 But since rpm 4.18, a new tool rpmuncompress is used. This now gives: [ 38s] + cd /home/abuild/rpmbuild/BUILD [ 38s] + rm -rf mobac [ 38s] + /usr/bin/mkdir -p mobac [ 38s] + cd mobac [ 38s] + /usr/lib/rpm/rpmuncompress -x /home/abuild/rpmbuild/SOURCES/Mobile Atlas Creator 2.3.0.zip [ 38s] error: File /home/abuild/rpmbuild/SOURCES/Mobile: No such file or directory [ 38s] error: Bad exit status from /var/tmp/rpm-tmp.SgyFCX (%prep) Is this just a plain bug in rpm? Is there some recommended way to deal with spaces in filenames? TIA for advice, Manfred

3 4

Where to discuss questions related to the SUSE Packagehub aka openSUSE:Backports?
by Johannes Kastl 12 Jan '23

12 Jan '23

Hi all, what is the right way or place to discuss things like missing or outdated packages in the SUSE Packagehub aka openSUSE:Backports? The wiki packages do not contain anything (or I missed it). There is only a single mail address on packagehub.suse.com which did not reply yet. I was hoping for a mailinglist, but failed to find one? E.g., I noticed some packages are missing for SP4 that were available in SP3. Or should these things be discussed here on opensuse-packaging? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

2 3

Deprecating the %usrmerged macro
by Ludwig Nussel 09 Jan '23

09 Jan '23

Hi! When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version. So I propose to remove use of the %usrmerged macro in spec files. Of course spec files could manually set it based on %suse_version if that's convenient. Spec files just shouldn't rely on an externally set %usrmerged anymore. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)

6 8