devel-announce July 2017

devel-announce@lists.fedoraproject.org

7 participants
31 discussions

F27 Self Contained Change: New default cipher in OpenVPN
by Jaroslav Reznik 18 Jul '17

18 Jul '17

= Proposed Self Contained Change: New default cipher in OpenVPN = https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN Change owner(s): * David Sommerseth <davids(a)openvpn.net> Since the discovery of the SWEET32 flaw [1], ciphers using cipher-blocks smaller than 128-bits are considered vulnerable and should not be used any more. OpenVPN uses Blowfish (BF-128-CBC) as the default cipher, which is hit by the SWEET32 flaw. This proposal changes the default cipher to AES-256-GCM while in parallel allowing clients to connect using AES-256-CBC, AES-128-CBC or the deprecated BF-CBC, This proposal will make use of that possibility by modifying the openvpn-server@.service unit file slightly. == Detailed Description == There have been two independent security audits of OpenVPN recently, performed by QuarksLab SAS [2] and Cryptography Engineering [3]. Both recommends moving away from the default Blowfish cipher (BF/BF-CBC) to a stronger cipher. The concept is fairly simple. In today's openvpn-server@.service systemd unit file the following command line is used to start OpenVPN: ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf By adding --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC before the --config option, the default cipher will be modified. The --ncp-ciphers list allows clients to use any of the listed ciphers as well. The new line will look like this: ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf This will result in the following: * OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM, regardless if they have --cipher in their configuration file or not. For OpenVPN v2.4 configurations not wanting this cipher upgrade, the client configuration needs to deploy --ncp-disable. * OpenVPN 2.3 based clients and older (and v2.4 clients using --ncp-disable in the client configuration) can connect to the server using any of the --ncp-ciphers list; this is what is called "poor man's cipher negotiation" by the upstream OpenVPN developers. * Any client not providing --cipher defaults to BF-CBC. These clients should still be able to connect to the server as the server allows BF-CBC through --ncp-ciphers. If an already configured OpenVPN v2.4 based server configuration deploys --cipher and/or --ncp-ciphers, the options in the configuration file will override command line options set before --config. This should not break any existing configuration. The log files will still complain about the use of BF-CBC if a client uses that. But the advantage is that OpenVPN v2.3 and older clients can be updated one-by-one, by adding the recommended --cipher AES-256-CBC option in the client configurations in their own pace, independent of the server - or upgrade to OpenVPN v2.4 or newer. == Scope == * Proposal owners: Patch the openvpn-server@.service unit file which adds the --cipher and --ncp-ciphers options. * Other developers: N/A (not a System Wide Change) * Release engineering: [4] (a check of an impact with Release Engineering is needed) * 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) [1] https://sweet32.info/ [2] https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf [3] https://www.privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation-s… [4] https://pagure.io/releng/issue/6908 Jaroslav

1 0

F27 Self Contained Change: Authselect: new tool to replace authconfig
by Jaroslav Reznik 18 Jul '17

18 Jul '17

= Proposed Self Contained Change: Authselect: new tool to replace authconfig = https://fedoraproject.org/wiki/Changes/Authselect Change owner(s): * Pavel Březina <pbrezina(a)redhat.com> Authselect is a tool to select system authentication and identity sources from a list of supported profiles. It is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it would ship several tested stacks (profiles) that solve a use-case and are well tested and supported. At the same time, some obsolete features of authconfig would not be supported by authselect. This tool aims to be first shipped along and later deprecate and later replace authconfig in a future Fedora release. == Detailed Description == Authselect will allow the administrator to choose one of the supported profiles. A profile provides description of how the resulting pam and nsswitch configuration looks like. The tool will be packaged with a default profile set that will be fully supported. If an administrator has different needs they can create a custom profile and make it accessible by authselect by dropping it in the tool directory. The authentication and identity configuration is hardcoded within the profile. However each profile is also allowed to contain some conditional modules that can be either enabled or disabled to allow the administrator to enable some optional behaviour such as password policy or ecryptfs support. Authselect will not configure daemons that provide the selected identity and authentication services such as SSSD or winbind, it will only configure pam and nsswitch. Daemons must be configured manually or through other system tools like realmd or ipa-client-install. The default profile set will contain the following profiles: Local users + SSSD -- local users and remote users are handled by sssd Local users + SSSD + Fingerprint -- same as above but also pam_fprintd is enabled Local users + winbind -- local users are handled by files and remote users by winbind Local users + winbind + Fingerprint -- same as above but also pam_fprintd is enabled We do not want to support nss-pam-ldapd and pam_krb5 in default profiles since their use-cases are completely or almost completely covered by SSSD. SSSD can be used as a complete replacement for pam_krb5 and there are only few old and rarely used maps for LDAP that remain unimplemented within SSSD such as hosts and aliases. These maps will be added in a future SSSD version. == Scope == * Proposal owners: implement the change * Other developers: N/A (not a System Wide Change) * Release engineering: [1] (a check of an impact with Release Engineering is needed) * 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) [1] https://pagure.io/releng/issue/6907 Jaroslav

1 0

F27 Self Contained Change: Improved Bay- and Cherry-Trail device support
by Jaroslav Reznik 12 Jul '17

12 Jul '17

= Proposed Self Contained Change: mproved Bay- and Cherry-Trail device support = https://fedoraproject.org/wiki/Changes/Improved_Bay_Cherry_Trail_Support Change owner(s): * Hans de Goede <hdegoede(a)redhat.com> Improve support for hardware using Intel Bay Trail and Cherry Trail SoCs. == Detailed Description == There are many affordable x86 laptops / tablets using Intel Bay Trail and Cherry Trail SoCs this change is about improving support for these SoCs and the peripherals typically found on devices with these SoCs. Examples of improvements in progress are fixing battery monitoring, touchscreen, audio and accelerometers (sometimes) not working. == Scope == * Proposal owners: Most of the work on this is kernel work and most of this is being done upstream The Fedora kernel package needs to have the right drivers enabled as well as some patches backported Some small userspace changes like adding new entries to hwdb for accelerometer orientation * Other developers: The non-upstream kernel and hwdb changes need to be coordinated with their resp. package owners * Release engineering: [1] (a check of an impact with Release Engineering is needed) * 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) [1] https://pagure.io/releng/issue/6881 Thanks, Jaroslav

1 0

F27 Self Contained Change: No More i686 Kernels
by Jaroslav Reznik 12 Jul '17

12 Jul '17

= Proposed Self Contained Change: No More i686 Kernels = https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels Change owner(s): * Justin Forbes <jforbes(a)fedoraproject.org> Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else. == Detailed Description == The i686 kernel is of limited use as most x86 hardware supports 64bit these days. It has been in a status of "community supported" for several Fedora releases now. As such, it gets very little testing, and issues frequently appear upstream. These tend to go unnoticed for long periods of time. When issues are found, it is often a long time before they are fixed because they are considered low priority by most developers upstream. This can leave other architectures waiting for important updates, and provides a less than desirable experience for people choosing to run a 32bit kernel. With this proposal, the i686 kernel will no longer be built. A kernel headers package will still exist, and all 32bit packages should continue to build as normal. The main difference is there would no longer be bootable 32bit images. == Scope == * Proposal owners: Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package. * Other developers: NA * Release engineering: [1] (a check of an impact with Release Engineering is needed) * 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) [1] https://pagure.io/releng/issues/6894 Thanks, Jaroslav

1 0

F27 Self Contained Change: Packaging Rust applications/libraries
by Jaroslav Reznik 12 Jul '17

12 Jul '17

= Proposed Self Contained Change: Packaging Rust applications/libraries = https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libr… Change owner(s): * Igor Gnatenko <ignatenkobrain(a)fedoraproject.org > (on behalf of Rust SIG) Add required tools/instructions for packaging applications/libraries written in Rust. Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. == Detailed Description == During initial research of SIG about packaging we identified that inability to specify version range dependencies (1.0 <= foo < 2.0) in RPM is main blocker. This problem hits almost every other language ecosystem (esp. NodeJS), but it is not very noticable due to having not more than 2 versions. While packaging some applications we discovered need of having 3 or more versions of same crate. The most of the work already has been done and users can consume applications without needing to do anything from Rust/Playground COPR repository [1]. == Scope == * Proposal owners: Create tool for automatic creation of rpm-spec-file from crate on crates.io, create RPM macro for easy packaging, write packaging guidelines. * Other developers: RPM developers to add support for expressing version range dependencies. * Release engineering: #6889 (a check of an impact with Release Engineering is needed) * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: Packaging Guidelines needs to be written for packaging Rust applications/libraries. * Trademark approval: N/A (not needed for this Change) [1] https://copr.fedorainfracloud.org/coprs/g/rust/playground/ [2] https://pagure.io/releng/issue/6889 Thanks, Jaroslav -- Jaroslav Řezník <jreznik(a)redhat.com> Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 Red Hat, Inc. http://www.redhat.com/

1 0

F27 Self Contained Change: Unified database for DNF
by Jaroslav Reznik 12 Jul '17

12 Jul '17

= Proposed Self Contained Change: Unified database for DNF = https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF Change owner(s): * Eduard Čuba <ecuba(a)redhat.com> * Igor Gnatenko <ignatenko(a)redhat.com> Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json) with new unified sqlite database adapted to the current needs of DNF. == Detailed Description == Using single unified database with shared interface enhances data integrity, safety and performance of package managers in Fedora. Database is easily expandable for new features (Modularity support in DNF will use SWDB). == Scope == * Proposal owners: Port DNF to SWDB (patches has been already sent), Port PackageKit to SWDB * Other developers: PackageKit developers should review proposed changes in libdnf for logging PackageKit transactions into SWDB instead of yumdb. In addition PackageKit developers should consider using SWDB for reading transaction data instead of using its own backend. * Release engineering: [1] (a check of an impact with Release Engineering is needed) * List of deliverables: Change affects whole distro rather than some derivable * Policies and guidelines: Nothing is required * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6886 -- Jaroslav Řezník <jreznik(a)redhat.com> Engineering Program Manager Office: +420 532 294 645 Mobile: +420 602 797 774 Red Hat, Inc. http://www.redhat.com/

1 0

Fedora 26 is officially here!
by Matthew Miller 11 Jul '17

11 Jul '17

Fedora 26 is here! Read the official announcement with hyperlinks and fancy formatting and details and (especially) thanks to the community at: https://fedoramagazine.org/fedora-26-is-here/ or just go ahead and grab it from https://getfedora.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

1 0

Cleaning packages with broken deps
by Mohan Boddu 10 Jul '17

10 Jul '17

Hi, We have a ticket on how to clean up packages with broken deps: https://pagure.io/releng/issue/6877 We had a discussion about this issue in our releng meeting on Jul 10th 2017. The problem is that there is no good way of solving this issue, but we came up two options: 1. Blocking the pkgs at branching and unblock them as necessary, pkg maintainers will request to unblock them and releng will review them and unblock them. Advantage is that we will more aware of whats got blocked and whats got unblocked. But it needs releng handling the tickets and we are not sure how many will show up per release cycle. 2. Using bodhi with greenwave to block pkgs. And config waiverdb to waive certain pkgs even if they are having dep issues so that they wont be blocked. And other pkgs can be blocked which can be unblocked by either releng or the pkg maintainer. We can configure it how ever we want like allowing only releng to unblock them when pkg maintainer files a ticket. Please let us know what you think and we are open to any other suggestions.

1 0

F27 System Wide Change: Drop 256term.sh
by Jaroslav Reznik 07 Jul '17

07 Jul '17

= System Wide Change: Drop 256term.sh = https://fedoraproject.org/wiki/Changes/Drop_256term.sh Change owner(s): * Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl > Do not install /etc/profile.d/256term.sh and /etc/profile.d/256term.csh. == Detailed Description == Currently Fedora installs some scripts to be executed every time a shell is started which perform some heuristics to set $TERM based on the terminal emulator being used. This is a work-around and it's better to for the terminal emulator to set $TERM properly on its own. Various terminal emulators have been updated to do that. /etc/profile.d/256term.sh and /etc/profile.d/256term.csh will not be installed anymore and the $TERM variable set by the terminal emulator will be used. [The change is trivial in and of itself. I'm making this a system wide change, and a change at all, only because those scripts take part in every shell startup, so it's possible they will have some unforeseen impact or require adjustments in other components. If FESCo or Wrangler think this does need a change page, I'm ready to drop it.] == Scope == * Proposal owners: do the change in initscripts package, work with other developers to fix any identified issues. * Other developers: fix any identified issues * Release engineering: [1] * List of deliverables: N/A * Policies and guidelines: N/A * Trademark approval: N/A (not needed for this Change) [1] https://pagure.io/releng/issue/6885 Thanks, Jaroslav

1 0

F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
by Jaroslav Reznik 07 Jul '17

07 Jul '17

= System Wide Change: Switch OpenLDAP from NSS to OpenSSL = https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL Change owner(s): * Matus Honek <mhonek (at) redhat.com> Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for cypto. OpenLDAP is going to be compiled with OpenSSL, instead. == Detailed Description == OpenLDAP in Fedora is has been compiled with NSS for crypto for several years now. Support layer for NSS was added back in 2008 but the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons for keeping OpenLDAP compiled with NSS was to make it work with some other packages (esp. 389DS) seamlessly. Fixing and keeping downstream patches has become a burden, thus it was decided to switch to OpenSSL, instead. For more detailed description, check out Change page. == Scope == * Proposal owners: write the Interception code. * Other developers: ensure usage of OpenSSL-like TLS configuration based on the Schedule. * Release engineering: [1] * List of deliverables: Not affected * Policies and guidelines: none. * Trademark approval: none. [1] https://pagure.io/releng/issue/6891 Thanks, Jaroslav

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce July 2017