== Summary ==
This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
== Owner ==
* Name: Nikos Mavrogiannopoulos
== Detailed Description ==
This change will enable the TLS 1.3 protocol (draft28) on the gnutls
library. TLS 1.3 is the latest version of the TLS protocol which
addresses few shortcomings of the previous versions. The protocol has
already been approved by IETF and is on its final publication stage,
with only minor editorial changes expected. The change for gnutls
depending is transparent to existing applications.
More information for applications using gnutls:
== Benefit to Fedora ==
* This brings the latest TLS protocol support to applications
depending on gnutls, when crypto policies are updated for TLS1.3.
== Scope ==
* Proposal owners:
* Other developers: N/A (not a System Wide Change)
== Upgrade/compatibility impact ==
That change should have no impact on upgrade or compatibility. The TLS
1.3 protocol is designed in a way that does not cause incompatibility
issues with existing (and even broken) implementations.
== How To Test ==
* Existing work-flows which include secure communications should be tested
* Command line applications which use TLS (e.g., wget, lftp), should
be tested against web-sites using TLS 1.3 (e.g., www.google.com)
== User Experience ==
That change should not be noticeable by users except for applications
which report the connected protocol. Other things users will notice
- Latency on TLS sessions will be reduced
- Performance of establishment of TLS sessions will be improved due
to ed25519/x25519 support
- Privacy of TLS sessions will be improved from the perspective of
passive eavesdroppers; no client certificate will be sent in the clear
- Transparent rekey of long-running sessions
== Dependencies ==
GNOME, samba, rsyslog, wget, lftp, ...
== Contingency Plan ==
If the expected transparent addition of TLS 1.3 cannot be assured
(e.g., important issues are reported), the enablement of TLS1.3
protocol will be postponed for the next fedora release.
* Contingency mechanism: The gnutls maintainer will not enable TLS1.3
by default in the build
* Contingency deadline: Fedora 29 beta
* Blocks release? No; the contingency plan is sufficient and can avoid
a release block
== Documentation ==
Fedora Program Manager
Phoronix recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
Best regards / S pozdravem,
The container effort in Fedora has until now been looked after by the
Atomic WG, since this Working Group is now going to focus mostly on
Fedora CoreOS, I propose to create a new container SIG to regroup
people interested in the maintenance of application containers in
This SIG would look after the container guidelines , the container
review process  and also the release process and tooling.
Please Reply if you're interested with helping out making the
Container story great in Fedora. If there is a good response, I will
create a Container SIG wiki page, and I guess we can ask for
container-devel mailing list for SIG discussions.
 - https://fedoraproject.org/wiki/Container:Guidelines
 - https://fedoraproject.org/wiki/Container:Review_Process
I'd like to fix some issues (including security problems) which are for
a long time present in dokuwiki package. Maintainers of the dokuwiki
however seem unresponsive.
Does anyone know how to contact maintainers?
Peter "Pessoft" Kolínek
Freehosting PIPNI - http://www.pipni.cz/
I just submitted a review request  for kcov  that I recently
discovered. It has no relation to Linux's kcov and is more akin to
lcov, except that all it needs is a binary with DWARF debuginfo
instead of requiring compile-time instrumentation.
I came across kcov when I was looking for a way to measure code
coverage in a Rust project and I'm impressed. It supposedly has a low
overhead, but so far I've been monitoring small single-threaded
programs so I can't really tell. I haven't tested python and shell
support, although I have cases where it would be relevant, but I don't
have time yet.
build on all main platforms so I may have to be granted an exception
from some group starting with an F. Been busy lately, I'm a little
behind on anything Fedora. If that's the case, please RTFM me a link
to the wiki, and if you want to take the review I'll gladly take one
I intend to retire python-svg. Tests are failing on Python 3.7 for a
reason I cannot figure, there was no commit during the last year and
according to `repoquery --whatrequires python2-svgwrite` and `repoquery
--whatrequires python3-svgwrite` nothing uses it anymore.
If you want to maintain it, please step up.
My name is Iñaki Ucar, and I am based in Madrid, Spain. I have been a
happy Fedora user and advocate for many many years (since Fedora Core
2). Now I would love to start contributing to the project as a package
maintainer, so I am seeking a sponsor.
I am package maintainer for the R Project since 2015, so I am
primarily interested in this ecosystem, which has grown spectacularly
in recent years. To start with, I have submitted my first package,
'simmer', for which I am the upstream maintainer. It is a
discrete-event simulator, and you can find the review request here:
For more information, please visit my GitHub profile
https://github.com/Enchufa2, and feel free to drop me an email. My GPG
key can be found in my Keybase profile: https://keybase.io/enchufa2.
it seems that lately there has been more people maintaining Go package in the Fedora. I would like to propose to join up and form Go SIG so we could better co-ordinate and collaborate on the packaging issues and general developer experience.
There are few big outstanding issues that needs to be solved that need more than individual work, most notably the Go packaging guidelines and tooling. I think that should be one of the first tasks for the SIG.
To introduce myself. I'm for some while golang (co-)maintainer and recently started co-maintaining origin package. I'm mostly interested in the compiler and developer experience.
Please reply if you would like to participate.
PS: Also I will be at Flock this year and would like to meet up with anyone interested there.
= Proposed System Wide Change: uEFI for ARMv7 =
* Peter Robinson <pbrobinson at fedoraproject dot org>
Move to uEFI as the default boot mechanism for ARMv7 devices.
== Detailed description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
== Scope ==
* Proposal owners:
Patches, updates to the process, testing
* Other developers:
System component owners will need to review and merge patches for
* Release engineering:
** List of deliverables:
* Policies and guidelines:
N/A I don't believe this changes any policies or guidelines
* Trademark approval:
N/A (not needed for this Change)
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic