F28 System Wide Change: Kerberos in Python modernization
by Jan Kurik
= System Wide Change: Kerberos in Python modernization =
https://fedoraproject.org/wiki/Changes/kerberos-in-python-modernization
Change owner(s):
* Robbie Harwood <rharwood at fp dot o>
Replace usage of python-krbV and pykerberos with python-gssapi in all
Fedora packages to enable their removal from Fedora. rharwood will
author all necessary code changes; no new code from maintainers is
required.
== Detailed Description ==
Replace older, clunkier, less user-friendly python interfaces to
Kerberos with python-gssapi. python-gssapi uses the GSSAPI interface,
which is widely standardized, implemented by both MIT and Heimdal
Kerberos, and much more user-friendly.
As part of this effort, python-requests-gssapi will be introduced to
fedora to enable transition off of python-requests-kerberos (which
requires pykerberos). Its package review (completed as of 2018-01-03)
was rhbz#1527682
Please note that I will be providing all patches necessary to all
affected components; no work is expected from other maintainers, other
than normal review and backport handling.
== Scope ==
* Proposal owners:
rharwood (responsible for providing patches and new package)
* Other developers:
maintainers of affected packages are expected to perform code review
* Release engineering:
#7219: https://pagure.io/releng/issue/7219
* List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 3 months
F28 Self Contained Change: Thunderbolt Enablement
by Jan Kurik
= Proposed Self Contained Change: Thunderbolt Enablement =
https://fedoraproject.org/wiki/Changes/ThunderboltEnablement
Change owner(s):
* Christian Kellner <ckellner AT redhat DOT com>
Support Thunderbolt 3 peripherals in a secure way hardware out of the box.
== Detailed Description ==
Thunderbolt™ is the brand name of a hardware interface developed by
Intel® that allows the connection of external peripherals to a
computer.
Devices connected via Thunderbolt can be DMA masters and thus read
system memory without interference of the operating system (or even
the CPU). Version 3 of the interface provides 4 different security
levels, in order to mitigate the aforementioned security risk that
connected devices pose to the system. The security level is set by the
system firmware.
The four security levels are:
* none: Security disabled, all devices will fully functional on connect.
* dponly: Only pass the display-port stream through to the connected device.
* user: Connected devices need to be manually authorized by the user.
* secure: As 'user', but also challenge the device with a secret key
to verify its identity.
The Linux kernel, starting with version 4.13, provides an interface
via sysfs that enables userspace query the security level, the status
of connected devices and, most importantly, to authorize devices, if
the security level demands it.
The active security level can normally be selected prior boot via a
BIOS option, but it is interesting to note that in the future the none
option is likely to go away. This of course means connected
thunderbolt devices wont work at all unless they are authorized by the
user from with the running operating system.
The solution to automatically enable thunderbolt 3 devices to work
with Fedora without compromising the security of the computer consists
of two user space compoments: a system daemon (boltd) and a component
in GNOME shell. For new devices the shell will automatically enroll (=
authorize and store in the database) new devices via the daemon if
(and only if) the current user is a system administrator and the
session is unlocked. On subsequent connections of the same device the
daemon will then automatically authorize the device.
== Scope ==
* Proposal owners:
Stablize bolt and integrate the current GNOME Shell extension
proof-of-concept into GNOME Shell upstream.
* Other developers:
Nothing
* Release engineering:
#7238: https://pagure.io/releng/issue/7238
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 3 months
Schedule for Friday's FESCo Meeting (2018-01-05)
by Jared K. Smith
(Sorry for the short notice -- I forgot that I was running the meeting this
week.)
Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting onirc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2018-01-05 16:00 UTC'
Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda
= Followups =
#topic #1799 The ProvenPackager rubric needs more formality
.fesco 1799https://pagure.io/fesco/issue/1799
= New business =
#topic #1800 Election Planning discussion
.fesco 1800https://pagure.io/fesco/issue/1800
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found
athttps://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue athttps://pagure.io/fesco,
e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
6 years, 3 months
F28 Self Contained Change: Glibc collation update and sync with cldr
by Jan Kurik
= Proposed Self Contained Change: Glibc collation update and sync with cldr =
https://fedoraproject.org/wiki/Changes/Glibc_collation_update_and_sync_wi...
Change owner(s):
* Mike Fabian <mfabian AT redhat DOT com>
Update collation data in glibc to an ISO file from 2015 (in sync with
Unicode 8.0.0) and sync collation rules of the locales with CLDR.
== Detailed Description ==
The collation data in glibc is extremely out of date, most locales
base their collation rules on an iso14651_t1_common file which has not
been updated for probably more than 15 years. Therefore, all
characters added in later Unicode versions are missing and not sorted
at all which causes bugs like [[1]]. This change is about updating
that iso146541_t1_common file to the latest available version from ISO
which is from 2015 and up-to-date with Unicode 8.0.0. Because
additions and changes in the syntax of the new iso146541_t1_common
file, updating that file requires changing the collation rules of
almost all locales. Because all these collation rules have to be
touched anyway, this is a good opportunity to fix bugs in the
collation ruies and sync them with the collation rules in CLDR.
== Scope ==
* Proposal owners:
Work with upstream, file bugs and provide patches where required.
* Other developers:
This change will impact glibc and everything which sorts strings using
the collation functions from glibc. Other Developers do not need to
make any changes from their end, but they need to watch how their
application behaves with improved localedata. We need proper testing
to see that it does not break any application.
* Release engineering:
#7234: https://pagure.io/releng/issue/7234
List of deliverables:
N/A (not a System Wide Change)
Policies and guidelines:
No, this change does not require any updates to Policies or packaging
guideline updates.
Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 3 months
linux-firmware, microcode_ctl, libvirt, qemu updates?
by Chuck Anderson
Red Hat has released linux-firmware, microcode_ctl, libvirt, and qemu
updates in addition to the kernel updates to mitigate against Meltdown
and Spectre. Is anyone working on those updates for Fedora? Is there
anything I can do to help with those?
6 years, 3 months
Self Introduction: Kevin Howell
by Kevin Howell
Hi folks,
I'm a Red Hat employee since 2014 and have been a long-time user of Fedora.
On the job I work on mostly subscription-manager (
https://github.com/candlepin/subscription-manager ) and also candlepin (
https://github.com/candlepin/candlepin ). I dabble in various other tiny
side-projects (feel free to see https://github.com/kahowell if curious),
and have contributed a few PRs to a few other open source projects.
I'm hoping to get started in packaging for Fedora, especially for packaging
subscription-manager and related packages, and I also aspire to package
other projects (outside of my day job) at some point.
I'm looking for sponsorship into the packager group for this purpose.
Lately, I've been doing most of the release work for subscription-manager
(and packaging for RHEL).
I go by khowell at Red Hat and Fedora; I'm kahowell on GitHub and FreeNode.
Also, Happy 2018!
Warm regards,
Kevin Howell
6 years, 3 months
F28 System Wide Change: Strong crypto settings
by Jan Kurik
= System Wide Change: Strong crypto settings =
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
Change owner(s):
* Nikos Mavrogiannopoulos <nmav AT redhat DOT com>
This change is about updating the current system-wide crypto policy to
disable legacy and unused cryptographic protocols.
== Detailed Description ==
Fedora includes several cryptographic components who's security
doesn't remain constant over time. Algorithms such as (cryptographic)
hashing and encryption typically have a lifetime after which they are
considered either too risky to use or plain insecure. That would mean
we need to phase out such algorithms from the default settings, or
completely disable if they could cause irreparable issue.
While in the past we did not disable algorithms in a consistent way
(different applications utilized different policies), today we have a
system-wide policy followed by a large part of Fedora components. That
allows us to move consistently and deprecate algorithms system-wide.
For rationale see RFC 7457 for a more complete list of attacks taking
advantage of legacy crypto algorithms.
The propose changes for default policy are:
* Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols
and move the TLS 1.x, x<=1 to legacy level.
* Require finite field parameters (RSA, Diffie-Hellman) of 2048 and
more in the default settings
That is a policy of:
LEGACY
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: SHA-1 hash or better (not RIPEMD)
Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES)
key exchange: ECDHE, RSA, DHE
DH params size: >=1024
RSA params size: >=1024
TLS protocols: TLS >= 1.0
DEFAULT
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: with SHA-1 hash or better
Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20,
including aes-cbc)
key exchange: ECDHE, RSA, DHE
DH params size: >= 2048
RSA params size: >= 2048
TLS protocols: TLS >= 1.2
FUTURE
MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 384 bits (including bernstein curves)
Signature algorithms: SHA-384 hash or better
Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
key exchange: ECDHE, DHE
DH params size: >= 3072
RSA params size: >= 3072
TLS protocols: TLS >= 1.2
== Scope ==
* Proposal owners:
The policies include in crypto-policies package need to be updated.
* Other developers:
* Crypto policies are updated to the settings above
* OpenSSL is updated to allow setting policies for TLS versions
* Release engineering:
#7235: https://pagure.io/releng/issue/7235
* List of deliverables:
* Crypto policies are updated to the settings above
* OpenSSL, NSS, GnuTLS and all applications covered under the Fedora
Crypto Policies follow the new crypto settings.
* Policies and guidelines:
No changes to packaging or other guidelines is needed.
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 3 months
FYI Fwd: Status of the second bootstrap of Fedora/RISC-V
by Richard W.M. Jones
----- Forwarded message from "Richard W.M. Jones" <rjones(a)redhat.com> -----
Date: Thu, 4 Jan 2018 11:29:51 +0000
From: "Richard W.M. Jones" <rjones(a)redhat.com>
To: sw-dev(a)groups.riscv.org
Subject: [sw-dev] Status of the second bootstrap of Fedora/RISC-V
I've almost reached the end of the allotted time available for
bootstrapping Fedora/RISC-V for a second time, so this is a status
report describing what I found and how far I got.
Background
----------
Fedora is a binary Linux distribution. I first bootstrapped Fedora on
RISC-V at the end of 2016 (the "first bootstrap").
https://fedoraproject.org/wiki/Architectures/RISC-V
To do a Linux distro sanely we need full ABI guarantees at least
between userspace and the kernel, so that involves mainly glibc and
the kernel, and at that time the ABI was changing which meant we would
need to go through the very costly process of re-bootstrapping
everything multiple times. So after porting a large percentage (I
think about 1/3rd) of all Fedora packages to the (then-) old glibc, I
stopped work on it for about a year.
glibc is supposed to go upstream in a few months from now, and that
will guarantee a stable ABI between userspace and the kernel, allowing
us to sanely build a Linux distro. I therefore put aside some time
now to practice bootstrapping Fedora again (the "second bootstrap").
When glibc finally goes upstream we will need to do the third and
final bootstrap, and from that point on older Fedora/RISC-V releases
will be used to build each new Fedora release.
Bootstrapping stages
--------------------
[These are historically named and based on the stages we used for
aarch64.]
stages 1 & 2: QEMU and cross-compiler are built from riscv-qemu and
riscv-tools.
https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce...
https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce...
stage 3: We build a minimal Fedora/x86_64 chroot and remove all x86_64
ELF binaries and libraries. Using the hosted cross-compiler we build
RISC-V binaries and libraries and to replace the x86 ones. We then
build a disk image from the chroot (it has many other hacky aspects to
it) and boot it under qemu.
https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce...
The stage 3 disk image is just enough to run ‘rpmbuild’ and ‘gcc’ and
a small handful of other tools, which is just enough to build RPMs.
https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce...
stage 4: Using only RPMs generated from stage 3 we build a pristine
disk image. This disk image contains only files controlled by RPMs
[actually there are two additional files needed: /init and a poweroff
binary, both eventually will be replaced by systemd].
https://github.com/rwmjones/fedora-riscv-bootstrap/blob/1858bd496378ddcce...
Using the stage 4 disk image we then build the rest of the Fedora
packages. This requires some manual intervention, usually to break
circular chains of dependencies of which there are many. There is
also an autobuilder which can build packages from Fedora
alphabetically or by shadowing the Fedora Koji build system.
The autobuilder will need rewriting at some point since it can be made
much more efficient now that we have working networking.
Status of the second bootstrap
------------------------------
I spent about 10 working days on this, and got a large part of the way
through stage 3. You can see the status and download built packages
here: https://github.com/rwmjones/fedora-riscv-bootstrap
There is also a stage3 disk image here: http://oirase.annexia.org/riscv/
The eagle-eyed will notice that I'm still building some Fedora 24/25
packages (latest is Fedora 27). This is because those packages
contain all the fixes from the first time around so it's convenient to
use them for the moment. Even with these packages it should be
sufficient to build Fedora 27 in stage 4 (particularly as packages get
replaced with the new versions as we go along).
Unfortunately I did not yet get a working stage 4 disk image. A glibc
RPM is required for stage 4 since almost all packages depend on it,
but the glibc build is hanging at some point for unclear reasons.
Debugging anything inside the stage 3 QEMU instance is a recipe for
pain and also debugging tools don't work inside stage 3.
QEMU user networking (with virtio-net virtual device) worked fine for
me, but I wasn't able to compile enough dependencies to get dhcp to
work.
Problems
--------
There is definitely a problem with GCC miscompiling with -O2 (which
can be worked around using -O0). It affected at least 4 packages, but
I was not able to produce any sort of minimal test case or common
cause. The issue is being tracked in:
https://github.com/riscv/riscv-gcc/issues/100
There is some bug in the kernel which causes it to hit a BUG_ON in
fs/buffer.c. Latest status is:
https://groups.google.com/a/groups.riscv.org/d/msg/sw-dev/v05FjcGC1EI/atX...
Poweroff does not work, however I was able to work around it:
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/8ps3Vtd...
The following bug affects iputils. I didn't try the upstream fix yet:
https://github.com/riscv/riscv-binutils-gdb/issues/108
A notable problem was building python2 which has multiple build issues
(although python3 was fine). Luckily Fedora has greatly reduced its
dependence on python2 and no important system packages should depend
on it in F27. In fact for the third bootstrap I may not even bother
with python2.
I wasn't able to get SMP to work, but unless mttcg also works SMP
wouldn't be helpful anyway.
Future
------
As discussed in the first section, my plan now is to wait until the
glibc changes are accepted upstream and released (hopefully in glibc
2.27). At that point I will go for the third and final bootstrap.
Rich.
----- End forwarded message -----
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
6 years, 3 months