F20 System Wide Change: Enable kdump on secureboot machines
by Jaroslav Reznik
= 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.
10 years, 9 months
F20 Self Contained Change: KDE Plasma Workspaces 4.11
by Jaroslav Reznik
= 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)
10 years, 9 months
Planned Outage: koji storage move - 2013-07-18 21:00 UTC
by Kevin Fenzi
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.
10 years, 9 months
F20 Self Contained Change: SDDM as the default KDE DM
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: Shared Certificate Tools
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: Hadoop
by Jaroslav Reznik
= 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)
10 years, 9 months
F20 Self Contained Change: Application Installer
by Jaroslav Reznik
= 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
10 years, 9 months
F20 System Wide Change: ARM as primary Architecture
by Jaroslav Reznik
= 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
10 years, 9 months
F20 Self Contained Change: GLIBC 2.18
by Jaroslav Reznik
= 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.
10 years, 9 months