January 2019 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 319035] Make YaST (incl. modules available in GNOME Software
by fate_noreply＠suse.de 22 Dec '19

22 Dec '19

Feature added by: Dominique Leuenberger (dimstar) Feature #319035, revision 1 Title: Make YaST (incl. modules available in GNOME Software openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: GNOME Software is an other way of handling installations. Instead of being package centric, it is application centric. An application is being represented by means of an appdata.xml file in it's setup (installed to /usr/share/appdata), then a metadata parser extracts this info and produces 'AppStream' metadata (to be consumed by software centers) In order to make extensions/plugins to applications discoverable, a package can add a metainfo.xml file to the same location and have itself listed as an extension/addon to the application. For YaST, this results in: - an appdata.xml file being provided together with YaST.desktop (done) - For all yast modules to install a metainfo.xml file, describin their extensive nature to yast. -- openSUSE Feature: https://features.opensuse.org/319035

1 4

[New: openFATE 324909] speed up staging setup and rebuild
by fate_noreply＠suse.de 15 Aug '19

15 Aug '19

Feature added by: Ludwig Nussel (lnussel) Feature #324909, revision 1 Title: speed up staging setup and rebuild Buildservice: New Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Staging projects have to rebuild quite often which takes a lot of time and resources. Maybe OBS could speed that up by taking some shortcuts. Some ideas by an unqualified external: * using ccache to speed up rebuilds without source changes. Could be implemented by project or project group for example. * have some cloning feature that also copies binaries and does not lead to immediate rebuild. That would allow to setup a new staging or rebase one in no time by cloing all packages including their binaries from rings. -- openSUSE Feature: https://features.opensuse.org/324909

1 5

[New: openFATE 318458] Reading user process memory
by fate_noreply＠suse.de 26 Apr '19

26 Apr '19

Feature added by: Sławomir Lach (Lachu) Feature #318458, revision 1 Title: Reading user process memory Requested by: Sławomir Lach (lachu) Partner organization: openSUSE.org Description: Reading user's process memory or writting to it is very bad think. Malware can stole passwords or change settings of application. I have two idea about solving this issue: 1. Dissallow to debug(reading/writting memory) process placed in /bin, /sbin, /usr/bin, /usr/sbin 2. Dissallow to debug(reading/writting memory) process of file not belonging to user, who execute file. -- openSUSE Feature: https://features.opensuse.org/318458

1 1

[New: openFATE 323500] Kernel: Add support for new AppArmor rule types
by fate_noreply＠suse.de 20 Mar '19

20 Mar '19

Feature added by: Christian Boltz (cboltz) Feature #323500, revision 1 Title: Kernel: Add support for new AppArmor rule types openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu.com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. -- openSUSE Feature: https://features.opensuse.org/323500

1 23

[New: openFATE 323318] OBS WEBUI: User role selector on task list
by fate_noreply＠suse.de 21 Feb '19

21 Feb '19

Feature added by: Adrian Schröter (adrianSuSE) Feature #323318, revision 1 Title: OBS WEBUI: User role selector on task list Buildservice: New Milestone: 2.9 Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Requested by: Ruediger Oertel (oertel) Partner organization: openSUSE.org Description: OBS Webui shall support filtering open tasks for a user by his workflow role there. The role is defined via a group for now. Details for planing can be found in this trello card: https://trello.com/c/H0fZCfFi/319-allow-filtering-of-requests-reviews-and-b… This request is just for tracking and connecting involved people. -- openSUSE Feature: https://features.opensuse.org/323318

1 3

[New: openFATE 320873] Remove copy_to_system from control.xml and AutoYaST
by fate_noreply＠suse.de 20 Feb '19

20 Feb '19

Feature added by: Ancor Gonzalez Sosa (ancorgs) Feature #320873, revision 1 Title: Remove copy_to_system from control.xml and AutoYaST openSUSE Distribution: New Priority Requester: Desirable Requested by: Ancor Gonzalez Sosa (ancorgs) Partner organization: openSUSE.org Description: In 2006 an generic mechanism to (silently) copy files from an existing filesystem to the system being installed was introduced in YaST as part of the implementation of two different features (fate#120103 and fate#300421). Any information to the user about the files being copied was intentionally left out (see comments in #300421). In 2008 the list of files was moved to control.xml and the AutoYaST profile (fate#305019). But the documentation and schema for the AutoYaST profile were never updated to reflect the change. We have received several bug reports and Fate entries about it since then, from incomplete lists of files (bug#956515, bug#956976) to non-intuitive or incomplete behavior (fate#319624, bug#956976) and everything in between. Starting with yast2-installation 3.1.187 and yast2-users 3.1.49, the original features do not longer need to use "copy_to_system" and the corresponding section is now empty in the control files of both SLE and openSUSE. I would like to completely drop the "copy_to_system" feature since it's obscure (everything happen behind user's back), problematic (quite some bug reports), not necessary (not longer needed by the originating features) and poorly documented (not even in the AutoYaST schema). -- openSUSE Feature: https://features.opensuse.org/320873

1 12

[New: openFATE 310701] package byobu in an opensuse repository
by fate_noreply＠suse.de 28 Jan '19

28 Jan '19

Feature added by: Divan Santana (divansantana7) Feature #310701, revision 1 Title: package byobu in an opensuse repository openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Divan Santana (divansantana7) Description: Would be great if anyone using opensuse could zypper in byobu . Unfortunately it's not in any opensuse repo despite it being a great tool for administrating linux servers. I'm quite surprised this isn't already available for opensuse. Would be a nice addition for 11.4 -- openSUSE Feature: https://features.opensuse.org/310701

1 7

[New: openFATE 324570] make GDM blackground image configurable
by fate_noreply＠suse.de 18 Jan '19

18 Jan '19

Feature added by: Ludwig Nussel (lnussel) Feature #324570, revision 1 Title: make GDM blackground image configurable Requested by: Ludwig Nussel (lnussel) Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: GDM only has very limited theming posibilites. To change the actual wallpaper one has to modify a binary file a rather nasty and not upgradable way: https://wiki.archlinux.org/index.php/GDM#Log-in_screen_background_image Please implement some more convenient way to allow custom deployments to override the wallpaper in GDM. -- openSUSE Feature: https://features.opensuse.org/324570

1 20

[New: openFATE 322073] yast should not override ip_forward setting
by fate_noreply＠suse.de 16 Jan '19

16 Jan '19

Feature added by: Bernhard Wiedemann (bmwiedemann) Feature #322073, revision 1 Title: yast should not override ip_forward setting openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Bernhard Wiedemann (bmwiedemann) Partner organization: openSUSE.org Description: someone thought, this bugfix qualifies as feature: http://bugzilla.suse.com/show_bug.cgi?id=1010036 Test Case: echo net.ipv4.ip_forward = 1 > /etc/sysctl.d/50-ip-forward.conf sysctl --system 2>/dev/null |grep "ip_forward = " net.ipv4.ip_forward = 1 Use Case: as a system administrator I want to override ip_forward setting in an easily scripted manner by writing my preferred values to /etc/sysctl.d/50-ip-forward.conf Business case (Partner benefit): openSUSE.org: manual configuration is deprecated and yast overriding admin's settings should be a thing of the past. -- openSUSE Feature: https://features.opensuse.org/322073

1 3

[openFATE 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 14 Jan '19

14 Jan '19

Feature changed by: Karl Cheng (qantas94heavy) Feature #305147, revision 16 Title: Wizard mode for Network Card configuration (in YaST) openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-08-11 15:36:00 reject reason: A desktop applet is the better solution, see Ludwig's proposal. Priority Requester: Neutral - openSUSE-11.4: Unconfirmed + openSUSE-11.4: Rejected by Karl Cheng (qantas94heavy) + reject reason: A desktop applet is the better solution, see Ludwig's + proposal. Priority Requester: Desirable Requested by: Michal Zugec (mzugec) Product Manager: Federico Lucifredi (flucifredi) Project Manager: Christoph Thiel (cthiel1) Technical Contact: Security Team (secteam) Partner organization: openSUSE.org Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) sounds reasonable. But how many multihomed systems do we find where the user "does not know" ? Besides, the security team's policy seems to be "lock everything, ask questions later", so I am not sure they are willing to mollify the firewall rules (for instance, open up Avahi by default, or other default daemons) on a "local" interface. Asking Marcus for insight. I am not sure on this one. #2: T. J. Brumfield (enderandrew) (2009-06-13 02:33:51) I'd contend that openSUSE and SLES/SLED should be treated differently here. With SLES/SLED, I'd err more on the side of caution and security, where as with openSUSE, I'd err more on the side of making the system user friendly. #3: Marcus Meissner (msmeissn) (2009-07-16 14:35:43) What we have investigated, or better Ludwig has investigated, is a Desktop Applet that can switch Firewall zones. See http://lizards.opensuse.org/2009/07/10/1453/ (Since most user machines these days are laptops, who vary between zones.) Perhaps this is more what is wanted? #4: Andreas Jaeger (a_jaeger) (2009-08-11 15:35:28) (reply to #3) I agree, let's push the applet instead. -- openSUSE Feature: https://features.opensuse.org/305147

1 0