February 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