devel-announce July 2013

devel-announce@lists.fedoraproject.org

6 participants
56 discussions

F20 System Wide Change: Enable kdump on secureboot machines
by Jaroslav Reznik 11 Jul '13

11 Jul '13

= Proposed System Wide Change: Enable kdump on secureboot machines = https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot Change owner(s): Vivek Goyal <vgoyal(a)redhat.com> Currently kexec/kdump is disabled on machines with secureboot enabled. This feature aims to enable kexec/kdump on such machines. == Detailed description == /sbin/kexec prepares a binary blob, called purgatory. This code runs at priviliged level between kernel transition. With secureboot enabled, no unsigned code should run at privilige level 0, hence kexec/kdump is currently disabled if secureboot is enabled. One proposed way to solve the problem is that sign /sbin/kexec utility. And upon successful signature verification, allow it to load kernel, initramfs, and binary blob. /sbin/kexec will verify signatures of kernel being loaded before it asks running kernel to load it. There are quite a few pieces to the puzzle. I am listing the some of the things which need to be done. === Build and ship ima-evm-utils package === /sbin/kexec will be signed by evmctl. This utility will put an xattr security.ima on /sbin/kexec file and kernel will leverage IMA infrastructure in kernel to verify signature of /sbin/kexec upon execution. * There is a bz open 807476 for inclusion of this package since long time. Not sure what it is stuck on though. * There are some patches which are not upstream yet (like lock down executable in memory) which we need to carry in this patckage till patches get upstream. === Changes to kexec-tools === Build /sbin/kexec statically. There is no infrastructure to sign and verify signature of shared libraries. Even if we can sign and verify shared libraries, currently kernel allows writing to shared libraries while these are mapped. So one can overwrite the library after signature verification. So build /sbin/kexec statically. kexec does not use nss related code, so there should not be any issues w.r.t glibc calling into other shared libraries. * Generate detached /sbin/kexec signautre at build time and install these signature on target in seucurity.ima xattr when kexec-tools is installed. * Modify kexec-tools so that it can call keyctl() and verify signature of a new kernel being loaded. === Kernel Changes === Kernel needs to carry additional patches to do verify elf binary signature. * There are patches to extend keyctl() so that user space can use it to verify signature of a user buffer (vmlinuz in this case). * These patches are not upstream, so these need to be carried in fedora till patches get upstream. * Kernel need to be signed using evmctl and detached signature need to be generated. These signatures need to be installed on vmlinuz upon kernel rpm installation in security.ima xattr. === Signing Key Management === Yet to be figured out. There are couple of ideas on table. * Embed few keys in kernel and one of these keys will be used to sign /sbin/kexec. In case of a key is revoked, use a new key from set of embedded keys. * Ship a PE/COFF wrapped key in kexec-tools package. This PE/COFF binary should be signed by appropriate authority so it can be loaded in system keyring. == Scope == Proposal owners: * Provide patches for kernel package. * Provide patches for kexec-tools package. * Provide patches for ima-evm-utils package. * ima-evm-utils package will be new. It is not clear who will maintain that package. Other developers: * Signing Process, Signing key management, Signing key loading on target after boot and Signature installation on target are unknown areas right now. It is not very clear how these things will be done. Once details have been figured out, it might require work from other developers. Not sure though at this point of time. * Can't think any other major work required by other developers yet. We will have to figure out how signing will take place and how signatures will be installed on target system. And depending on how we do it, it might require some work from other developers. Like making use of rpm hooks to install signature etc. Given the fact that we are signing only one file /sbin/kexec, we might get away doing changes in kexec-tools spec file. Release engineering: * We need to sort out how signing will take place. I will require release- engineering help on this. * For issues related to key management I will need help of security/release engineering. Policies and guidelines: * I think to begin with we might not have to update any packaging guidelines for this. Anything magic w.r.t signing can probably be limited to kexec-tools spec file.

1 0

F20 Self Contained Change: KDE Plasma Workspaces 4.11
by Jaroslav Reznik 11 Jul '13

11 Jul '13

= Proposed Self Contained Change: KDE Plasma Workspaces 4.11 = https://fedoraproject.org/wiki/Changes/KDE411 Change owner(s): Rex Dieter <rdieter(a)fedoraproject.org> and KDE SIG Rebase to version 4.11 of: the KDE Plasma Workspaces including the Plasma Desktop and Netbook workspaces, the KDE Applications and the KDE Platform. == Detailed description == New features overview: KDE Plasma Workspaces, KDE Applications and KDE Platform 4.11 Faster Nepomuk indexing KScreen integration in Kwin Qt Quick in Plasma Workspaces More porting to QML Kontact improvements WebP image format plugin Ogg Opus audio support in Juk Metalink/HTTP Support in Kget UI Refactoring in KWallet Given how the KDE Plasma Workspaces 4.11 and Fedora 20 schedules align, there should be plenty of buffer time between the KDE Plasma Workspaces 4.11 and Fedora 20 releases. We are already working on importing and polishing beta version of KDE. == Scope == Proposal owners: Requires rebasing to the latest upstream version and preparing distribution specific patches. All new required packages are already included in distribution. But as upstream changed release schema and now provides split tarballs for some previously monolithic modules, we are going to follow this decision in Fedora too as we want to stick as close as possible to upstream. This involves changes in packaging, new reviews and small overload for packaging system. Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

Planned Outage: koji storage move - 2013-07-18 21:00 UTC
by Kevin Fenzi 10 Jul '13

10 Jul '13

Planned Outage: koji storage move - 2013-07-18 21:00 UTC There will be an outage starting at 2013-07-18 21:00 UTC, which will last approximately 24 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2013-07-18 21:00 UTC' Reason for outage: We are moving our koji package storage from one backend device to another, which requires a final rsync of a lot of data. During this outage, koji will not be available to build or download packages from, and the 2013-07-19 rawhide compose will not occur. pkgs.fedoraproject.org will be available and you can commit changes, but no builds will be possible. Updates pushes will not happen in this window either. Additionally, we will be tweaking our koji database during this window to improve it's performance. Affected Services: Buildsystem - http://koji.fedoraproject.org/ Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ GIT / Source Control - pkgs.fedoraproject.org DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/3882 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

F20 Self Contained Change: SDDM as the default KDE DM
by Jaroslav Reznik 10 Jul '13

10 Jul '13

= Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza <mbriza(a)redhat.com> and KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. == Detailed description == As described in many articles and discussions, KDM is nearing its end of life and it's time we decided upon the successor. I'm proposing to switch to SDDM, which is a new project that suits our needs perfectly despite its immaturity: As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer. SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable against Qt4, supports QtQuick theming and its upstream is quite active. Compared to the current DM, KDM, it currently lacks a few features (such as XDMCP) but adds some other ones (QtQuick themes) or is currently adding them (Keyboard layout switching in the greeter). == Scope == Proposal owners: * Create sddm and sddm-kcm packages. * Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM * (eventually) exclude KDM from the kde-workspace package Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

F20 Self Contained Change: Shared Certificate Tools
by Jaroslav Reznik 10 Jul '13

10 Jul '13

= Proposed Self Contained Change: Shared Certificate Tools = https://fedoraproject.org/wiki/Changes/SharedCertificateTools Change owner(s): Stef Walter <stefw(a)redhat.com> Fedora now has infrastructure for sharing system trusted certificates between the various crypto libraries. Tools are being worked on for adding/removing these shared trusted certificates, as well as blacklisted certificates. This is being worked on upstream in the p11-kit project. This change integrates that upstream work into Fedora. == Detailed description == A tool will be added to the p11-kit-trust package which can be used to perform the following actions: * Add a trust anchor * Disable a trust anchor * Remove an added trust anchor * Blacklist a certificate or key * Remove an blacklisted certificate or key Because not all crypto implementations read their trusted information directly from the dynamic database, the tool will take care of extracting things as appropriate after making a change. This will enable administrators to run a single command to add an anchor (and perform other tasks). == Scope == p11-kit has had work done to have the trust module store changes. The initial tool has been written upstream. Remainder of the tool needs completion. The ca-certificates package will need some minor tweaks to make sure the new tools integrate correctly with it. Although this feature can potentially affect a large number of packages, the implementation is well bounded. It is limited to a p11-kit (with one or two lines changed in ca-certificates). Proposal owners: stefw, see above Other developers: kaie (for ca-certificates) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

F20 Self Contained Change: Hadoop
by Jaroslav Reznik 10 Jul '13

10 Jul '13

= Proposed Self Contained Change: Hadoop = https://fedoraproject.org/wiki/Changes/Hadoop Change owner(s): Matthew Farrellee <matt(a)fedoraproject.org> Provide native Apache Hadoop packages. == Detailed description == Apache Hadoop is a widely used, increasingly complete big data platform, with a strong open source community and growing ecosystem. The goal is to package and integrate the core of the Hadoop ecosystem for Fedora, allowing for immediate use and creating a base for the rest of the ecosystem. == Scope == Proposal owners: * Note: target is Apache Hadoop 2.0.5-alpha * Package all dependencies needed for Apache Hadoop 2.x * Package the Apache Hadoop 2.x software Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change)

1 0

F20 Self Contained Change: Application Installer
by Jaroslav Reznik 10 Jul '13

10 Jul '13

= Proposed Self Contained Change: Application Installer = https://fedoraproject.org/wiki/Changes/AppInstaller Change owner(s): Richard Hughes <rhughes(a)redhat.com>, together with the desktop team We will replace the existing gnome-packagekit frontends (gpk-update-viewer and gpk-application) by a new application. == Detailed description == The current PackageKit frontends are focused on (surprise!) packages. The new tool, tentatively named gnome-software, is designed from the beginning for installing applications. It will present applications with information that is relevant to users (screenshots, reviews, descriptions, ratings,...) instead of information that is relevant for packagers (dependencies, package size, file lists,...). It will be possible to search and browse for available applications. gnome-software will also be used to present information about available and installed updates. Notifications about available updates will launch gnome- software if the user chooses to see details. gnome-software will be fully integrated with 'offline updates' - if an update includes system packages, it will be done as an offline update, regardless whether it gets initiated from the gnome-shell menu, a notification, or the gnome-software UI. To improve some problematic aspects of the updates user experience (long waits, locks), we will use the new hawkey backend for PackageKit. == Scope == Proposal owners: * Implement minimal required functionality for application installation in gnome-software * Implement minimal required functionality for updates in gnome-software * Replace gpkg-update-viewer * Package gnome-software * Include a hawkey backend in PackageKit and use it Other developers: * Use gnome-software instead of gpk-update-viewer when dealing with updates in gnome-settings-daemon, gnome-shell and gnome-control-center Release engineering: * Make metadata available for packaged applications in Fedora (screenshots, icons, ratings,...). Not all of this needs to be in place for F20 Policies and guidelines: * No immediate changes needed; longer-term, we probably want to make changes to way applications are distributed and installed * The update experience will also benefit from proposed changes to batch updates

1 0

F20 System Wide Change: ARM as primary Architecture
by Jaroslav Reznik 09 Jul '13

09 Jul '13

= Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary Change owner(s): Dennis Gilmore <dennis(a)ausil.us>, Peter Robinson <pbrobinson(a)gmail.com> Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). == Detailed description == The Changing IT landscape has started to focus on greener technologies as well as cheaper mass produced devices that allow for fully functional cheap devices for lower socio-economic areas and other markets like education and "makers". ARM SoCs have traditionally been the domain of embedded and mobile applications but are now finding their way into more traditional computing devices like desktop, notebook and server markets. Fedora ARM currently works on many different devices with wider support coming with each new mainline kernel release. For this change we will enable armv7hl builds on primary koji, and compose arm trees as with the other primary architectures. Fedora has in the Phoenix data centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will remain allocated to the arm secondary architecture koji instance for building updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of life the ARMv5 softfp nodes will able to be be reallocated to other tasks. Infrastructure has expressed an interest in testing and experimenting with some of its workloads on ARM, some are allocated to QA and some for releng. There is currently 24 nodes configured in primary koji ready to go as builders, there is the capacity to add up to 24 more when ARM becomes primary if desired. The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance- creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created. == Scope == Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64. Requisite build hardware already exists in phx2 and is configured to work with mainline koji. Proposal owners: change the arches in koji, import the matching ARMv7 rawhide builds into koji. Update Release Engineering scripts to automatically build armhfp trees along with i686 and x86_64. Other developers: submit builds as normal, in the event of unexpected build failures liaise with the ARM Team to help debug and fix issues. Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are part of the team of people proposing the Change. Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji

1 0

F20 Self Contained Change: GLIBC 2.18
by Jaroslav Reznik 08 Jul '13

08 Jul '13

= Proposed Self Contained Change: GLIBC 2.18 = https://fedoraproject.org/wiki/Changes/GLIBC218 Change owner(s): Carlos O'Donell <carlos(a)redhat.com> Switch GLIBC in Fedora 20 to GLIBC version 2.18. == Detailed description == GLIBC 2.18 will be released at the end of July 2013; we have started closely tracking the GLIBC 2.18 development code in Fedora Rawhide and are addressing any issues as they arise. There should be little difference from the users perspective between GLIBC 2.17 used in F19 and GLIBC 2.18 used in F20. == Scope == Proposal owners: Update glibc to 2.18 from tested upstream release. Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) The library is backwards compatible with the version of glibc that was shipped in Fedora 19. All packages do not need to be rebuilt.

1 0

F20 Self Contained Change: Ryu Network Operating System
by Jaroslav Reznik 08 Jul '13

08 Jul '13

= Proposed Self Contained Change: Ryu Network Operating System = https://fedoraproject.org/wiki/Changes/Ryu Change owner(s): yamahata <yamahata at private email ne jp> Ryu Network Operating System [1] This change was originally proposed for Fedora 19 but postponed to Fedora 20 https://fedoraproject.org/wiki/Features/Ryu == Detailed description == Ryu is an Operating System for Software Defined Networking. Ryu aims to provide a logically centralized control and well defined API that make it easy for operators to create new network management and control applications. Currently, Ryu manages network devices by using OpenFlow. You can say that Ryu is an OpenFlow Controller. For Software Defined Networking or OpenFlow, please refer to Open Networking Foundation [2] == Scope == Proposal owners: * Ryu development: DONE ** vlan support: 100% DONE ** Ryu plugin support for Openstack Networking (Neutron, formaly Quantum): keeping update for its development * packaging: ** rpm package: available at [3] ** rpm package review [4] Work In Progress ** make sure that it works with dependent Fedora package. Especially OpenStack and Open vSwitch Other developers: N/A Release engineering: N/A Policies and guidelines: N/A [1] http://osrg.github.com/ryu/ [2] https://www.opennetworking.org/ [3] http://sourceforge.net/projects/ryu/files/Packages/Fedora/ [4] https://bugzilla.redhat.com/show_bug.cgi?id=909674

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2013