January 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1160547] New: VUL-1: CVE-2020-6624: jhead: heap-based buffer over-read in process_DQT in jpgqguess.c
by bugzilla_noreply＠novell.com 25 Jul '22

25 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1160547 Bug ID: 1160547 Summary: VUL-1: CVE-2020-6624: jhead: heap-based buffer over-read in process_DQT in jpgqguess.c Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://smash.suse.de/issue/250646/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: sbrabec(a)suse.com Reporter: atoptsoglou(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2020-6624 jhead through 3.04 has a heap-based buffer over-read in process_DQT in jpgqguess.c. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-6624 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6624 https://bugs.launchpad.net/ubuntu/+source/jhead/+bug/1858744 -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1160544] New: VUL-1: CVE-2020-6625: jhead: heap-based buffer over-read in Get32s when called from ProcessGpsInfo in gpsinfo.c
by bugzilla_noreply＠novell.com 25 Jul '22

25 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1160544 Bug ID: 1160544 Summary: VUL-1: CVE-2020-6625: jhead: heap-based buffer over-read in Get32s when called from ProcessGpsInfo in gpsinfo.c Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other URL: https://smash.suse.de/issue/250647/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: sbrabec(a)suse.com Reporter: atoptsoglou(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2020-6625 jhead through 3.04 has a heap-based buffer over-read in Get32s when called from ProcessGpsInfo in gpsinfo.c. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-6625 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6625 https://bugs.launchpad.net/ubuntu/+source/jhead/+bug/1858746 -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1159688] New: mirrors not carrying latest release for tumbleweed (factory)
by bugzilla_noreply＠novell.com 22 Jul '22

22 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1159688 Bug ID: 1159688 Summary: mirrors not carrying latest release for tumbleweed (factory) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Factory Status: NEW Severity: Critical Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Astara(a)tlinx.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I downloaded repomd.xml from download.opensuse.org/tumbleweed/repo/non-oss/repodata/repomd.xml. That directory had files for Dec 16th. When I tried to open one of the file in that directory ( http://download.opensuse.org/tumbleweed/repo/non-oss/repodata/a424c3aaba9f6… ) I was taken to mirrors.edge.kernel.org. Unfortunately, the latest files in that directory were from the 14th (today is the 20th). The above file wasn't in the outdated mirror. This prevents download of current releases. Perhaps before blindly sending us off to some mirror site, a database should be checked to see what mirrors have which versions and not send us to a site that doesn't have the files for the version that repomd references. This really resolves to 'zero' confidence in the mirror system and low confidence in being able to download a coherent version of the distribution. -- You are receiving this mail because: You are on the CC list for the bug.

2 11

[Bug 1116431] New: systemd tmpfiles does not clean-up sddm-auth files
by bugzilla_noreply＠novell.com 20 Jul '22

20 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1116431 Bug ID: 1116431 Summary: systemd tmpfiles does not clean-up sddm-auth files Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: 64bit OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin(a)winter-rosenheim.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Over time, the /tmp directory contains a growing number of sddm-auth files. The systemd tmpfile services makes no attempt to clean them up. I would suggest to add a rule to /etc/tmpfiles.d to remove these files. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1084717] New: The Leap 15.0 installation procedure creates a 500 MB EFI partition
by bugzilla_noreply＠novell.com 19 Jul '22

19 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1084717 Bug ID: 1084717 Summary: The Leap 15.0 installation procedure creates a 500 MB EFI partition Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: bugrprt21882(a)online.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Executing a default "fresh" Leap 15.0 installation (Build 153) results in a 500 MB EFI partition being created. Attempting to change the EFI partition size to something less than 256 MB results in an error message indicating that, "the partition size is much too small" being raised. -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1129549] New: YaST Control Center - Multilingual issue
by bugzilla_noreply＠novell.com 19 Jul '22

19 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1129549 Bug ID: 1129549 Summary: YaST Control Center - Multilingual issue Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: bugrprt21882(a)online.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- System Language and System Locale: de_DE.UTF-8 User "root" Locale: de_DE.UTF-8 Regardless of whether the Qt graphical user interface or the ncurses text-mode user interface, the following module names and, where noted, also the associated comment, are English: * "Software-Repositories" - comment also in English. * "Create New Directory Server" - comment also in English. * "Create New Kerberos Server" - comment also in English. * "User Logon Management" - comment also in English. The following German language module names have English comments: * "Datum und Zeit". * "Netzwerkeinstellungen". * "Benutzer und Gruppenverwaltung". -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1151703] New: python3-yamllint is missing requirement on python3-setuptools
by bugzilla_noreply＠novell.com 18 Jul '22

18 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1151703 Bug ID: 1151703 Summary: python3-yamllint is missing requirement on python3-setuptools Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: jayvdb(a)gmail.com Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Observation yamllint tries to read out information during runtime using "pkg_resources" which is supplied by setuptools, if installed, but the package does not pull in this dependency. ## Steps to reproduce ``` $ docker run --rm -it registry.opensuse.org/opensuse/tumbleweed 5da80e2533ad:/ # zypper -n in python3-yamllint && yamllint Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata ............................................[done] Building repository 'openSUSE-Tumbleweed-Non-Oss' cache .................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata ................................................[done] Building repository 'openSUSE-Tumbleweed-Oss' cache .....................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Update' metadata .............................................[done] Building repository 'openSUSE-Tumbleweed-Update' cache ..................................................[done] Loading repository data... Reading installed packages... Resolving package dependencies... The following 9 NEW packages are going to be installed: libexpat1 libpython3_7m1_0 libuuid1 libyaml-0-2 python-rpm-macros python3-PyYAML python3-base python3-pathspec python3-yamllint 9 new packages to install. Overall download size: 8.9 MiB. Already cached: 0 B. After the operation, additional 34.5 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package libexpat1-2.2.7-1.2.x86_64 (1/9), 87.7 KiB (206.3 KiB unpacked) Retrieving: libexpat1-2.2.7-1.2.x86_64.rpm ..............................................................[done] Retrieving package libpython3_7m1_0-3.7.3-1.3.x86_64 (2/9), 1.1 MiB ( 3.2 MiB unpacked) Retrieving: libpython3_7m1_0-3.7.3-1.3.x86_64.rpm .......................................................[done] Retrieving package libuuid1-2.34-2.1.x86_64 (3/9), 50.3 KiB ( 30.1 KiB unpacked) Retrieving: libuuid1-2.34-2.1.x86_64.rpm ................................................................[done] Retrieving package libyaml-0-2-0.2.2-2.1.x86_64 (4/9), 53.9 KiB (126.3 KiB unpacked) Retrieving: libyaml-0-2-0.2.2-2.1.x86_64.rpm ............................................................[done] Retrieving package python-rpm-macros-20190610.2ee3233-1.2.noarch (5/9), 25.8 KiB ( 47.0 KiB unpacked) Retrieving: python-rpm-macros-20190610.2ee3233-1.2.noarch.rpm ...........................................[done] Retrieving package python3-base-3.7.3-1.3.x86_64 (6/9), 7.2 MiB ( 29.7 MiB unpacked) Retrieving: python3-base-3.7.3-1.3.x86_64.rpm ...............................................[done (4.5 MiB/s)] Retrieving package python3-pathspec-0.5.9-1.4.noarch (7/9), 47.0 KiB (188.0 KiB unpacked) Retrieving: python3-pathspec-0.5.9-1.4.noarch.rpm .......................................................[done] Retrieving package python3-PyYAML-5.1.2-1.1.x86_64 (8/9), 189.8 KiB (739.6 KiB unpacked) Retrieving: python3-PyYAML-5.1.2-1.1.x86_64.rpm .........................................................[done] Retrieving package python3-yamllint-1.17.0-1.1.noarch (9/9), 71.9 KiB (294.0 KiB unpacked) Retrieving: python3-yamllint-1.17.0-1.1.noarch.rpm ......................................................[done] Checking for file conflicts: ............................................................................[done] (1/9) Installing: libexpat1-2.2.7-1.2.x86_64 ............................................................[done] (2/9) Installing: libpython3_7m1_0-3.7.3-1.3.x86_64 .....................................................[done] (3/9) Installing: libuuid1-2.34-2.1.x86_64 ..............................................................[done] (4/9) Installing: libyaml-0-2-0.2.2-2.1.x86_64 ..........................................................[done] (5/9) Installing: python-rpm-macros-20190610.2ee3233-1.2.noarch .........................................[done] (6/9) Installing: python3-base-3.7.3-1.3.x86_64 .........................................................[done] (7/9) Installing: python3-pathspec-0.5.9-1.4.noarch .....................................................[done] (8/9) Installing: python3-PyYAML-5.1.2-1.1.x86_64 .......................................................[done] (9/9) Installing: python3-yamllint-1.17.0-1.1.noarch ....................................................[done] Traceback (most recent call last): File "/usr/bin/yamllint", line 6, in <module> from pkg_resources import load_entry_point ModuleNotFoundError: No module named 'pkg_resources' ``` ``` -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1041090] New: trackerbug: packages do not build reproducibly from unsorted input
by bugzilla_noreply＠novell.com 18 Jul '22

18 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1041090 Bug ID: 1041090 Summary: trackerbug: packages do not build reproducibly from unsorted input Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- See also https://reproducible-builds.org/docs/stable-inputs/ When linking .o files in random filesystem order the linker will vary the ordering of functions and apply varying optimizations resulting in binaries that differ on every build and thus trigger rebuilds of depending packages and are published to mirrors and users when actually nothing really changed. -- You are receiving this mail because: You are on the CC list for the bug.

2 15

[Bug 1160091] New: Boinc Manager fails to auto-connect to localhost on application start
by bugzilla_noreply＠novell.com 15 Jul '22

15 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1160091 Bug ID: 1160091 Summary: Boinc Manager fails to auto-connect to localhost on application start Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: marix(a)marix.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When starting up the Boinc Manager application (boinc-manager) it fails to utilise the credentials in gui_rpc_auth.cfg to automatically connect to the Boinc client running on localhost. Weirdly, the automatic connection to localhost does work if the Boinc Manager is started automatically by KDEs session restore. This works even when the client was not connected to localhost when the previous KDE session was ended. Using boinccmd on the command line also works flawlessly. My initial assumption was that this was somehow related to the desktop file of the Boinc manager. However, explicitly launching boinc-manager from the command line and thus bystepping the desktop file shows the same issue. The behaviour I'd expect would be for the client to behave identical when being launched via the application launcher and via KDE's session restore mechanism, ideally auto-connecting successfully in both cases. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1123721] New: suse-module-tools must not depend on mkintird / dracut
by bugzilla_noreply＠novell.com 14 Jul '22

14 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1123721 Bug ID: 1123721 Summary: suse-module-tools must not depend on mkintird / dracut Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Discussion on https://build.opensuse.org/request/show/657402 and via email. Email from Dominique Leuenberger, 2019-01-24 ------------- Some more thinking and tinkering around the problems with suse-module- tools - and your https://github.com/openSUSE/rpm-config-SUSE/pull/6 Adding a runtime dependency from suse-module-tools to dracut is a bad thing (with the current setup), as you already know: * coreutils buildrequires suse-module-tools in order to get the initrd macros in place. * coreutils is part of the distro bootstrap cycle (which is already large/too large). Adding dracut (plus dependency chain) into this cycle will make it close to impossible to bootstrap any new distro, namely SLE16 This shall not mean that dracut as a dependency on suse-module-tools is wrong per se, and as you did in the last weeks, we should try to find a solution for this issue, and I think the started path is not the worst: * we remove the macro to rebuild the initrd from suse-module-tools, and move that to a common place (rpm-config-SUSE comes to mind, it already contains commonly used macros) * With this, coreutils could completely give up on the dependency on suse-module-tools, which means s-module-tools could be downgraded from a ring0 to a ring1 package. The macro is already smart enough to skipt over the execution of /usr/lib/module-init-tools/regenerate-initrd- posttrans if it does not exist * An additional problem will show up though: dracut requires suse- module-tools, and suse-module-tools will require dracut. To break that cycle in OBS you will have to add a "#!BuildIgnore: suse-module-tools" to suse-module-tools.spec. This way forward would solve the technical difficulties we have around building a self-contained distro, without making it harder on the distro maintainers AND will allow us to add a dependency to s-m-t that is being interpreted by OBS (or we could even add a fileprovides then - once coreutils no longer cares for it) If any mail recipient has a valid reason AGAINST this plan, please speak up - but please also offer alternative solutions. Otherwise, let's get things moving. There are still two ring0 packages that will need touching (rpm-config-SUSE and coreutils) - and ring0 packages are 'tough' as they put a high load onto the distro build, meaning stagins willing to take them are scarse. ------------- https://github.com/openSUSE/rpm-config-SUSE/pull/6 has been accepted for rpm-config-SUSE. The initrd-related macros have _not_ been removed from suse-module-tools yet (15.0.20). The dependency on mkinitrd has been replaced by a weak "recommends". -- You are receiving this mail because: You are on the CC list for the bug.

2 20