April 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1042287] New: [Build 20170601] openQA test fails in enlightenment_first_start
by bugzilla_noreply＠novell.com 25 Feb '22

25 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1042287 Bug ID: 1042287 Summary: [Build 20170601] openQA test fails in enlightenment_first_start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: http://openqa.opensuse.org/tests/413072/modules/enligh tenment_first_start/steps/12 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The description text is missing. ## Observation openQA test in scenario opensuse-Tumbleweed-NET-x86_64-otherDE_enlightenment@64bit fails in [enlightenment_first_start](http://openqa.opensuse.org/tests/413072/modules/… ## Reproducible Fails since (at least) Build [20170601](http://openqa.opensuse.org/tests/412884) ## Expected result Last good: [20170529](http://openqa.opensuse.org/tests/411282) (or more recent) ## Further details Always latest result in this scenario: [latest](http://openqa.opensuse.org/tests/latest?machine=64bit&flavor=NET&te… -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1122683] New: osc: deprecate insecure APIs
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1122683 Bug ID: 1122683 Summary: osc: deprecate insecure APIs Classification: Internal Novell Products Product: openSUSE Build Service Version: master Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: osc Assignee: adrian(a)suse.com Reporter: malte.kraus(a)suse.com QA Contact: adrian(a)suse.com Found By: --- Blocker: --- >From bnc#1119444: > > The OSC client has some vulnerable code in it, that it doesn't use itself but provides as a library to plugins. In one case there's even a comment explicitly marking this as insecure, but are not removed due to compatibility concerns. If not breaking backwards compatibility under any circumstances is that important, I recommend adding deprecation warnings (https://docs.python.org/2.6/library/warnings.html#temporarily-suppressing-w…) to move plugins over to secure APIs. > > Can you create a dedicated request for this? Specifically, the 'unpack_srcrpm' function has such a warning as a comment. Also, 'Ar.saveTo', 'CpioRead.copyin' can be made to store files in arbitrary locations if the archive they parsed contain a filename starting with a "/". -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1170396] New: basis_devel complains about missing gettext-tools
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1170396 Bug ID: 1170396 Summary: basis_devel complains about missing gettext-tools Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: simonf.lees(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The C++ pattern doesnt, reported on IRC -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1158470] New: synergy: Mouse pointer can't be moved back to server after switching to neighbor
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1158470 Bug ID: 1158470 Summary: synergy: Mouse pointer can't be moved back to server after switching to neighbor Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X11 Applications 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: --- I'm observing erratic behavior of synergy in my setup under Leap. TL;DR: It's fixed by upgrading to synergy-1.9.1-lp151.61.3 from X11:Utilities. Setup: server "artemis", left: > eDP-1 connected primary 1368x768+0+1152 (normal left inverted right x axis y axis) 294mm x 165mm > DP-1-1 connected 1200x1920+1368+0 left (normal left inverted right x axis y axis) 518mm x 324mm This is the laptop screen plus one monitor in "portrait" orientation. client "apollon", right: > DP1-1 connected primary 1080x1920+1200+0 left (normal left inverted right x axis y axis) 530mm x 300mm > eDP1 connected 1368x768+2280+1016 (normal left inverted right x axis y axis) 310mm x 170mm Another vertical monitor plus the screen of the 2nd laptop. >From left to right, I have "artemis" laptop screen, portrait monitor of "artemis", portrait monitor of "apollon", "apollon" laptop screen. The links section in synergy.conf looks like this: > section: links > artemis: > right = apollon > down = zeus > apollon: > left = artemis > down = zeus > zeus: > up = artemis > left = artemis > right = apollon > end (computer "zeus" is switched off). Now I start synergys on artemis, synergyc is running on apollon. I slowly move the pointer on artemis from left to right until it reaches the right edge of the portrait monitor. I'd expect the cursor to move on "apollon" now, but this does not happen. It vanishes on "artemis", but it's not visible on "apollon". When I move the mouse back left, still nothing happens. I can't get the mouse pointer to move back to "artemis" screen. I have to ssh to artemis and kill synergys to get a working mouse pointer back. Here's what happens in the synergys debug log when moving the mouse from left to right: > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2563,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2565,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2566,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 2567,1158 at this point the right screen border of "artemis" is reached, now we start generating events for "apollon": > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:18] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:18] DEBUG2: move on apollon to 84,1158 > [2019-12-04T22:54:18] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1369,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1369,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: onMouseMoveSecondary +85,+0 > [2019-12-04T22:54:19] DEBUG2: move on apollon to 169,1158 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1368,960 > [2019-12-04T22:54:19] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:19] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:19] DEBUG2: move on apollon to 253,1158 "onMouseMoveSecondary" gets basically the same relative step over and over again, causing the pointer to move monotonically to the right (I made but minimal movements with the mouse at this point), until... > [2019-12-04T22:54:22] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:22] DEBUG2: move on apollon to 3622,1155 > [2019-12-04T22:54:22] DEBUG2: warped to 1284,960 > [2019-12-04T22:54:22] DEBUG2: event: MotionNotify 1284,960 > [2019-12-04T22:54:22] DEBUG2: onMouseMoveSecondary +84,+0 > [2019-12-04T22:54:22] DEBUG2: find neighbor on right of "apollon" > [2019-12-04T22:54:22] DEBUG2: no neighbor on right of "apollon" > [2019-12-04T22:54:22] DEBUG1: try to leave "apollon" on right > [2019-12-04T22:54:22] DEBUG1: no neighbor right > [2019-12-04T22:54:22] DEBUG2: clamp to right of "apollon" Here, the *right* edge of apollon's monitor is reached although I sure as hell didn't move the mouse there. Comparing the same log for synergy 1.9.1: > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2549,1705 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2564,1691 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 2567,1683 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 844,1440 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 689,1531 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 705,1518 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 725,1505 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 746,1492 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 775,1479 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 807,1461 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 844,1440 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +160,-96 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 160,1587 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -155,+91 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 5,1678 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -5,+5 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 0,1683 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +21,-18 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 21,1665 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary -21,+18 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 0,1683 > [2019-12-04T23:07:51] DEBUG2: event: MotionNotify 684,1536 > [2019-12-04T23:07:51] DEBUG2: onMouseMoveSecondary +41,-31 > [2019-12-04T23:07:51] DEBUG2: move on apollon to 41,1652 Here it seems that right after entering "apollon"'s screen, a number of MotionNotify events is discarded, and later on, onMouseMoveSecondary() calls seem to "correct" previous movements. For the user, this feels correct. Also, the mouse pointer is well visible in on "apollon", moves as expeted, and can be moved back to the "artemis" screen just fine. I've been trying to figure out which commits changed this behavior between v1.8.8-stable and v1.9.1-stable, but nothing caught my eye. The 1.9.1 version has already been submitted and accepted to Leap 15.2. I'd like to suggest to submit it to 15.1, too. -- You are receiving this mail because: You are on the CC list for the bug.

2 16

[Bug 1122778] New: x11 pattern recommends YaST and x11_opt
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.suse.com/show_bug.cgi?id=1122778 Bug ID: 1122778 Summary: x11 pattern recommends YaST and x11_opt Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Patterns Assignee: dimstar(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: simonf.lees(a)suse.com Found By: --- Blocker: --- When installing with recommends enabled, these patterns are always pulled in with x11 (unless locks are used): * x11_opt * x11_opt -> enhanced_base * x11_opt -> enhanced_base -> apparmor * x11_opt -> enhanced_base -> enhanced_base_opt * x11_opt -> enhanced_base -> sw_management * x11_opt -> enhanced_base -> yast2_basis * x11_opt -> fonts * x11_opt -> fonts -> fonts_opt ... and over Supplements which also pulls in other patterns. That makes it highly impractical to have a user-friendly option to not install "everything and the kitchen sink" without either locking the pattern metapackages (which nobody knows about and they really shouldn't need to) or disabling recommends (which breaks stuff severely). This needs to be fixed by either removing quite a few of those cross-pattern recommends or changing the way patterns are managed in yast (deselection adds a lock). -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1087824] New: Installer picks obsolete mirror
by bugzilla_noreply＠novell.com 24 Feb '22

24 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1087824 Bug ID: 1087824 Summary: Installer picks obsolete mirror Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i686 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jdelvare(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- I am trying to install Tumbleweed/i586 from France. download.opensuse.org redirects me to mirrors.standaloneinstaller.com which is out of date: Index of /opensuse-stable/tumbleweed/repo/oss/boot/i386 Name Last modified Size ---------------------------------------------------------------------- Parent Directory cracklib-dict-full.rpm 2017-05-27 18:14 3.1M yast2-trans-de.rpm 2017-10-12 01:59 643K yast2-trans-en_US.rpm 2017-10-12 01:59 95K This results in an error message: Digest verification failed. Checking for the list of openSUSE mirror sites (https://mirrors.opensuse.org/list/tumbleweed.html) this mirror is not listed as hosting any Tumbleweed contents. According to the list, the only mirror in France for Tumbleweed is fr2.rpmfind.net. If I manually select this mirror at the beginning of the installation, the error does not happen. download.opensuse.org should only redirect Tumbleweed users to mirrors with up-to-date Tumbleweed contents. -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1073845] New: python-attrs andpython-pluggy form a build cycle together
by bugzilla_noreply＠novell.com 18 Feb '22

18 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1073845 Bug ID: 1073845 Summary: python-attrs andpython-pluggy form a build cycle together Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The two packages python-attrs and python-pluggy cause trouble for bootstrapping a distro, since they depend on each other to build -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1156745] New: [Build 20191112] openQA test fails in libreoffice_recent_documents; keyboard shortcuts can't open some menu in gtk3 under wayland
by bugzilla_noreply＠novell.com 17 Feb '22

17 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1156745 Bug ID: 1156745 Summary: [Build 20191112] openQA test fails in libreoffice_recent_documents; keyboard shortcuts can't open some menu in gtk3 under wayland Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1083961/modules/libr eoffice_recent_documents/steps/14 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: zcjia(a)suse.com QA Contact: qa-bugs(a)suse.de CC: alynx.zhou(a)suse.com, grace.wang(a)suse.com, yfjiang(a)suse.com Found By: --- Blocker: --- ## Observation In this test, openQA tries to send_key "alt-f" to open the "Files" menu, if you do this manually, you will find that the menu opens for a short period of time and then closes itself. This bug happens if the menu's first item is a submenu (In this case, the first item of 'Files' is submenu 'New'.), this bug only happens for gtk3 application under wayland. This bug does not happen on Leap 15.1, which has gtk 3.22.30 (TW has 3.24.12). openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-desktopapps-documentation@64bit fails in [libreoffice_recent_documents](https://openqa.opensuse.org/tests/1083961/mod… ## Test suite description Maintainer Yaun Ren ## Reproducible Fails since (at least) Build [20191107](https://openqa.opensuse.org/tests/1079854) ## Expected result Last good: [20191106](https://openqa.opensuse.org/tests/1079673) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1036979] New: python2-qt4 posttrans fails
by bugzilla_noreply＠novell.com 17 Feb '22

17 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1036979 Bug ID: 1036979 Summary: python2-qt4 posttrans fails Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Output of python2-qt4-4.12-3.1.x86_64.rpm %posttrans script: /var/adm/update-scripts/posttransLsYXyp/python2-qt4-4.12-3.1.x86_64.rpmpbKPGQ: line 6: syntax error: unexpected end of file Warning: python2-qt4-4.12-3.1.x86_64.rpm %posttrans script failed (returned 2) -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1017682] New: VUL-0: CVE-2016-10091: UnRTF: stack-based buffer overflows in cmd_* functions
by bugzilla_noreply＠novell.com 17 Feb '22

17 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1017682 Bug ID: 1017682 Summary: VUL-0: CVE-2016-10091: UnRTF: stack-based buffer overflows in cmd_* functions Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE3 Assignee: anixx(a)opensuse.org Reporter: mikhail.kasimov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Ref: http://seclists.org/oss-sec/2016/q4/786 =============================================== Hi As reported by "Skylake" in the Debian bugtracker[1], UnRTF is prone to stack-based buffer overflows in various cmd_* functions. I've found a Stack-based buffer overflow in unrtf 0.21.9, which affects three functions including: cmd_expand, cmd_emboss and cmd_engrave. # convert.c static int cmd_expand (Word *w, int align, char has_param, int param) { char str[10]; if (has_param) { sprintf(str, "%d", param/4); // Overflow, 9-digit negative value triggers the bug if (!param) attr_pop(ATTR_EXPAND); else attr_push(ATTR_EXPAND, str); } return FALSE; } Apparently writing a negative integer to the buffer can trigger the overflow (Minus sign needs an extra byte). * How to trigger the bug * $ echo "\expnd-400000000" > poc $ unrtf poc A preliminary patch can be found in the Debian bugtracker, but it is not yet finalized. Could you assign (a?) CVE as needed? Does one CVE suffice here, since same class of issue in various cmd_* functions from one reporter? Whilest, at least in Debian, unrtf is compiled with FORTIFY_SOURCE=2 and the buffer overflows are detected, at least if any exposed application uses unrtf to process untrusted input, this might lead to a denial-of-service. [1] https://bugs.debian.org/849705 Regards, Salvatore =============================================== https://software.opensuse.org/package/unrtf TW: KDE:KDE3: 0.21.5 42.2: KDE:Extra: 0.21.5 and KDE:KDE3: 0.21.8 42.1: KDE:Extra: 0.21.5 and KDE:KDE3: 0.21.8 13.2: KDE:Extra: 0.21.5 and KDE:KDE3: 0.21.8 -- You are receiving this mail because: You are on the CC list for the bug.

2 3