We have released LibreSSL 2.6.4, the first stable maintenance release from the
2.6.x series. It contains the following changes from the 2.6.3 release:
* Made tls_config_parse_protocols() work correctly when passed a NULL
pointer for a protocol string. Issue found by semarie@, who also
provided the diff.
* Corrected TLS extensions handling when no extensions are present.
If no TLS extensions are present in a client hello or server hello,
omit the entire extensions block, rather than including it with a
length of zero. Thanks to Eric Elena <eric at voguemerry dot com> for
providing packet captures and testing the fix.
* Fixed portable builds on older Android systems, and systems without
IPV6_TCLASS support.
The LibreSSL project continues improvement of the codebase to reflect modern,
safe programming practices. We welcome feedback and improvements from the
broader community. Thanks to all of the contributors who helped make this
release possible.
Thursday, December 21, 2017
Tuesday, December 19, 2017
Modularity is Dead, Long Live Modularity!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Modularity is Dead, Long Live Modularity! ========================================= See this post in glorious technicolor at: https://communityblog.fedoraproject.org/modularity-dead-long-live-modularity/ Summary - ------- Fedora's Modularity initiative aims to make it easy for packagers to create alternative versions of software and for users to consume those streams simply. We've been working on this for several years, resulting in the "Boltron" prototype this summer and the recent Fedora Modular Server beta. Feedback shows that these test releases didn't meet the goal, and we're incorporating that in a modified design which we think _will_. We plan to demo the new approach by DevConf.cz and FOSDEM. Retrospective - ------------- As you have probably read, the members of the Modularity Working Group and the Server Working Group decided that the current implementation of Modularity would not meet Fedora's standard of excellence in time for a release in Fedora 27 — even with the extra time that the Fedora Council granted to the project. In particular, feedback received from the Fedora 27 Modular Server Beta release alerted us to several serious problems in the design. The most common feedback from users was: "How do I install package `foo` in Modular Server?". In this case, `foo` ranged across a wide variety of software, including everything from the screen package to complex third-party applications. In that version of Modularity, a system was either all Modular or none of it was. To make software available in the fully-modular system, its packages needed to be part of a module — and unfortunately, we didn't succeed in making many of those. The lack of available modules was a symptom of a larger problem with packager involvement. Some of this problem was due to disagreements with the implementation or design, and some of it was because creating modules turned out to be more time-consuming and had a steeper learning curve than we wanted. Additionally, the whole process was not obvious or well-socialized. The team produced a lot of documentation, but packagers needed to understand a whole lot of it before even getting started. As a result, all of the modules slated for delivery in F27 Modular Server were being developed by the Modularity team, a group that had limited expertise around many of the packages we desired to ship. There were other problems, of course. We didn't really have a strong plan for how to handle upgrades from traditional deployments. We lacked a story for how third-party software should be loaded onto the system. And, we never got away from needing a "bootstrap" module (as explained below). So, we decided not to ship Modular Server in Fedora 27, and we activated our fallback plan of releasing Fedora 27 Server Edition in its classic incarnation at https://getfedora.org/server/. Moving Forward - -------------- With all of this in mind, we took Modularity back to the drawing board (or perhaps "chopping board"). We analyzed the various functionality that the design offered us and made some trade-offs. First and foremost, we gave up on the idea of a strictly-maintained, stable buildroot. Traditional Fedora builds are performed by building an RPM in a buildroot containing the latest packages available in the stable updates repository for a release (plus the overrides repo when needed to allow building against pre-release packages). With modularity, we hoped that we could define a small and specific buildroot which would be stable and maintained for the life of a release. We would then build every module against it. It turned out when we tried to implement this that it was basically impossible. It required us to find a point at which the entire buildroot could be used to build _itself_, a feat which has not been accomplished in Fedora for many years (if ever). Fedora packages are really only guaranteed to build successfully against a buildroot for which they have _already_ been built. If it builds against any other buildroot, this is a happy accident. There are many reasons for this; something in the dependency chain for one of the build dependencies may have broken, a bug may have been introduced in the compiler or linker resulting in an inability to continue, new default compiler flags may have been added that result in warnings becoming errors and so on. This was the easiest requirement to drop as it had never worked. We used a kludgy "bootstrap" module to work around this which provided a set of packages copied from non-Modular Fedora to be able to build the platform. In its place, **we will now build modules against the standard Fedora buildroot**. Since our buildroot now has access to everything that has been built for Fedora, we reconsidered another of our original goals that of providing a module to be the base platform upon which all of the other modules would depend. Originally, this was intended to define the provided API of the Base and indicate which portions of it should be considered stable. However, Fedora already has a stable updates policy for how things must act within a release. This policy has only a few outliers (Kernel, KDE, etc.), but for the most part, once we release the Beta, the platform API is stable for the life of the Fedora release. By relaxing this requirement, we realized that we could eliminate (or at least postpone) the requirement for having a defined platform module. What we decided instead is to treat Fedora's "Everything" repository (essentially, the complete set of software available within a Fedora release) as the "platform module", though the tooling will not report this content as a module. In practical terms, this means that **creators of modules will no longer need to go through the very painful process of tracking down which modules provide a dependency that they need**. Instead, they will be able to depend on the system version available in the Everything repo. If that version does not meet their needs, they will have several options described later. This provides us with several advantages, including **a straightforward upgrade path from a traditional deployment**, because we will retain the traditional repositories as well as a set of default modules. This means it will be possible to upgrade from a current Fedora 27 system to a modular Fedora 28 system without any special steps. In fact, this approach will also mean that modularity need not be limited to the Server Edition. Another practical advantage to this change is that **module-creation will become _significantly_ simpler**. Instead of a complex collection of a package and all of its dependencies, modules will now only need to describe the parts that differ from the base repository. For example, Fedora 28 will ship with the Node.js 8.x LTS release in the standard repository, and a module could be built to provide the 9.x experimental release as an option. We could also easily provide the older 6.x LTS release to support older applications. In these cases, we can ship very simple module definitions which just lists the dist-git branches matching the desired upstream releases. In fact, this will now be so simple that **we plan to provide tools to automate the creation of these modules**. Since most modules will now only require a single source package be in the components list, we plan to enable support for automatically building a single branch in dist-git for all active Fedora (and EPEL) releases. Even for more complex multi-package modules, the automatically-created module definitions provide an easy and obvious starting point. What Will It Look Like? - ----------------------- From an end-user's perspective, **Fedora will ship with two sets of repositories.** One will be the traditional Fedora repositories (fedora, updates, and updates-testing) and the other will be a new set of repositories providing alternative and supplementary modules. We haven't decided on a final name for these yet, so we will use the placeholder terms modular, modular-updates, and modular-updates-testing. With this design, **anyon who does not wish to access the additional versions of software provided by modules can disable the modular and modular-updates repositories and their system will function exactly as it does today**. Packages built with Fedora's traditional process will be installed and managed from the regular fedora repository, as will default versions of packages which use the new process behind the scenes. **For anyone who wants access to additional versions of packages, these new module repositories will make them available**. Users will be able to interact with these new repositories by taking advantage of some new syntax in DNF, the same as was used in the Modular Server Beta. If a user wants to install a particular module stream, they can do `dnf install module[:stream[/profile]]` (e.g. `dnf install @nodejs:6`, which will install the default profile containing the nodejs and npm packages). If the user just wants to install whatever version is the default for this system, a `dnf install package` will continue to work as it always has. Conclusion - ---------- This refined plan offers an understandable, approachable, and deliverable future for Modularity. Packagers who don't want to produce modules will be able to continue packaging exactly as they always have with **no modification** to their workflows. Those who want to provide alternative versions of software in a single release or to easily provide the same version across multiple releases will have new tools to simplify this. As the number of available modules grows, users of Fedora will have a much easier access to the exact version of software they want to accomplish their tasks. People doing rapid-prototyping can more easily access newer versions of packages and at the same time people running older applications can continue to access the older streams that they need. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.1.0 Comment: https://www.mailvelope.com wkYEAREIABAFAlo5f/YJEHolVWI2uqOjAAD5RgCfeRL8DcETF34kmCOT5pXJ yzL0LLYAmwVmmd2DPHf1gzKZOjUfxiHlbuML =ZnhF -----END PGP SIGNATURE-----
Monday, December 18, 2017
[USN-3382-2] PHP vulnerabilities
==========================================================================
Ubuntu Security Notice USN-3382-2
December 18, 2017
php5 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in PHP.
Software Description:
- php5: HTML-embedded scripting language interpreter
Details:
USN-3382-1 fixed several vulnerabilities in PHP. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that the PHP URL parser incorrectly handled certain
URI components. A remote attacker could possibly use this issue to
bypass hostname-specific URL checks. (CVE-2016-10397)
It was discovered that PHP incorrectly handled certain boolean
parameters when unserializing data. A remote attacker could possibly
use this issue to cause PHP to crash, resulting in a denial of
service. (CVE-2017-11143)
Sebastian Li, Wei Lei, Xie Xiaofei, and Liu Yang discovered that PHP
incorrectly handled the OpenSSL sealing function. A remote attacker
could possibly use this issue to cause PHP to crash, resulting in a
denial of service. (CVE-2017-11144)
Wei Lei and Liu Yang discovered that the PHP date extension
incorrectly handled memory. A remote attacker could possibly use this
issue to disclose sensitive information from the server.
(CVE-2017-11145)
It was discovered that PHP incorrectly handled certain PHAR archives.
A remote attacker could use this issue to cause PHP to crash or
disclose sensitive information. This issue only affected Ubuntu 14.04
LTS. (CVE-2017-11147)
Wei Lei and Liu Yang discovered that PHP incorrectly handled parsing
ini files. An attacker could possibly use this issue to cause PHP to
crash, resulting in a denial of service. (CVE-2017-11628)
It was discovered that PHP mbstring incorrectly handled certain
regular expressions. A remote attacker could use this issue to cause
PHP to crash, resulting in a denial of service, or possibly execute
arbitrary code. (CVE-2017-9224, CVE-2017-9226, CVE-2017-9227, CVE-
2017-9228, CVE-2017-9229)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libapache2-mod-php5 5.3.10-1ubuntu3.28
php5 5.3.10-1ubuntu3.28
php5-cgi 5.3.10-1ubuntu3.28
php5-cli 5.3.10-1ubuntu3.28
php5-fpm 5.3.10-1ubuntu3.28
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3382-2
https://www.ubuntu.com/usn/usn-3382-1
CVE-2016-10397, CVE-2017-11143, CVE-2017-11144, CVE-2017-11145,
CVE-2017-11147, CVE-2017-11628, CVE-2017-9224, CVE-2017-9226,
CVE-2017-9227, CVE-2017-9228, CVE-2017-9229
Ubuntu Security Notice USN-3382-2
December 18, 2017
php5 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
Several security issues were fixed in PHP.
Software Description:
- php5: HTML-embedded scripting language interpreter
Details:
USN-3382-1 fixed several vulnerabilities in PHP. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that the PHP URL parser incorrectly handled certain
URI components. A remote attacker could possibly use this issue to
bypass hostname-specific URL checks. (CVE-2016-10397)
It was discovered that PHP incorrectly handled certain boolean
parameters when unserializing data. A remote attacker could possibly
use this issue to cause PHP to crash, resulting in a denial of
service. (CVE-2017-11143)
Sebastian Li, Wei Lei, Xie Xiaofei, and Liu Yang discovered that PHP
incorrectly handled the OpenSSL sealing function. A remote attacker
could possibly use this issue to cause PHP to crash, resulting in a
denial of service. (CVE-2017-11144)
Wei Lei and Liu Yang discovered that the PHP date extension
incorrectly handled memory. A remote attacker could possibly use this
issue to disclose sensitive information from the server.
(CVE-2017-11145)
It was discovered that PHP incorrectly handled certain PHAR archives.
A remote attacker could use this issue to cause PHP to crash or
disclose sensitive information. This issue only affected Ubuntu 14.04
LTS. (CVE-2017-11147)
Wei Lei and Liu Yang discovered that PHP incorrectly handled parsing
ini files. An attacker could possibly use this issue to cause PHP to
crash, resulting in a denial of service. (CVE-2017-11628)
It was discovered that PHP mbstring incorrectly handled certain
regular expressions. A remote attacker could use this issue to cause
PHP to crash, resulting in a denial of service, or possibly execute
arbitrary code. (CVE-2017-9224, CVE-2017-9226, CVE-2017-9227, CVE-
2017-9228, CVE-2017-9229)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libapache2-mod-php5 5.3.10-1ubuntu3.28
php5 5.3.10-1ubuntu3.28
php5-cgi 5.3.10-1ubuntu3.28
php5-cli 5.3.10-1ubuntu3.28
php5-fpm 5.3.10-1ubuntu3.28
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3382-2
https://www.ubuntu.com/usn/usn-3382-1
CVE-2016-10397, CVE-2017-11143, CVE-2017-11144, CVE-2017-11145,
CVE-2017-11147, CVE-2017-11628, CVE-2017-9224, CVE-2017-9226,
CVE-2017-9227, CVE-2017-9228, CVE-2017-9229
Friday, December 15, 2017
Elections in January 2018 to FESCo, Council, Mindshare - the schedule
Hi,
I have published schedule for elections in January 2018 on the
Elections [1] wiki page. The schedule is as follows:
* Dec 15 - Jan 02: Selection of questions from Questionnaire
* Jan 03 - Jan 10: Nomination period
* Jan 11 - Jan 15: Interviews
* Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews
* Jan 17 - Jan 24: Voting period
* Jan 25: Result Announcement
Please check the Election page [1] for more details on how the
Elections (and interviews) are going to be organized.
I am going to be on vacations, mostly off-grid, until January 4th, so
if you need any help, please contact Bex [2] (and CC me, please).
[1] https://fedoraproject.org/wiki/Elections
[2] https://fedoraproject.org/wiki/User:Bex
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
I have published schedule for elections in January 2018 on the
Elections [1] wiki page. The schedule is as follows:
* Dec 15 - Jan 02: Selection of questions from Questionnaire
* Jan 03 - Jan 10: Nomination period
* Jan 11 - Jan 15: Interviews
* Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews
* Jan 17 - Jan 24: Voting period
* Jan 25: Result Announcement
Please check the Election page [1] for more details on how the
Elections (and interviews) are going to be organized.
I am going to be on vacations, mostly off-grid, until January 4th, so
if you need any help, please contact Bex [2] (and CC me, please).
[1] https://fedoraproject.org/wiki/Elections
[2] https://fedoraproject.org/wiki/User:Bex
Regards,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
[USN-3509-3] Linux kernel regression
==========================================================================
Ubuntu Security Notice USN-3509-3
December 15, 2017
linux, linux-aws, linux-kvm, linux-raspi2 regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 LTS
Summary:
USN-3509-1 introduced a regression in the Linux kernel for Ubuntu 16.04 LTS.
Software Description:
- linux: Linux kernel
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-kvm: Linux kernel for cloud environments
- linux-raspi2: Linux kernel for Raspberry Pi 2
Details:
USN-3509-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. Unfortunately, it also introduced a regression that prevented the
Ceph network filesystem from being used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 LTS:
linux-image-4.4.0-1013-kvm 4.4.0-1013.18
linux-image-4.4.0-104-generic 4.4.0-104.127
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127
linux-image-4.4.0-104-lowlatency 4.4.0-104.127
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127
linux-image-4.4.0-1044-aws 4.4.0-1044.53
linux-image-4.4.0-1080-raspi2 4.4.0-1080.88
linux-image-aws 4.4.0.1044.46
linux-image-generic 4.4.0.104.109
linux-image-generic-lpae 4.4.0.104.109
linux-image-kvm 4.4.0.1013.13
linux-image-lowlatency 4.4.0.104.109
linux-image-powerpc-e500mc 4.4.0.104.109
linux-image-powerpc-smp 4.4.0.104.109
linux-image-powerpc64-emb 4.4.0.104.109
linux-image-powerpc64-smp 4.4.0.104.109
linux-image-raspi2 4.4.0.1080.80
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-3
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux/4.4.0-104.127
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1044.53
https://launchpad.net/ubuntu/+source/linux-kvm/4.4.0-1013.18
https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1080.88
Ubuntu Security Notice USN-3509-3
December 15, 2017
linux, linux-aws, linux-kvm, linux-raspi2 regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 16.04 LTS
Summary:
USN-3509-1 introduced a regression in the Linux kernel for Ubuntu 16.04 LTS.
Software Description:
- linux: Linux kernel
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
- linux-kvm: Linux kernel for cloud environments
- linux-raspi2: Linux kernel for Raspberry Pi 2
Details:
USN-3509-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. Unfortunately, it also introduced a regression that prevented the
Ceph network filesystem from being used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 16.04 LTS:
linux-image-4.4.0-1013-kvm 4.4.0-1013.18
linux-image-4.4.0-104-generic 4.4.0-104.127
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127
linux-image-4.4.0-104-lowlatency 4.4.0-104.127
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127
linux-image-4.4.0-1044-aws 4.4.0-1044.53
linux-image-4.4.0-1080-raspi2 4.4.0-1080.88
linux-image-aws 4.4.0.1044.46
linux-image-generic 4.4.0.104.109
linux-image-generic-lpae 4.4.0.104.109
linux-image-kvm 4.4.0.1013.13
linux-image-lowlatency 4.4.0.104.109
linux-image-powerpc-e500mc 4.4.0.104.109
linux-image-powerpc-smp 4.4.0.104.109
linux-image-powerpc64-emb 4.4.0.104.109
linux-image-powerpc64-smp 4.4.0.104.109
linux-image-raspi2 4.4.0.1080.80
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-3
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux/4.4.0-104.127
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1044.53
https://launchpad.net/ubuntu/+source/linux-kvm/4.4.0-1013.18
https://launchpad.net/ubuntu/+source/linux-raspi2/4.4.0-1080.88
[USN-3509-4] Linux kernel (Xenial HWE) regression
==========================================================================
Ubuntu Security Notice USN-3509-4
December 15, 2017
linux-lts-xenial, linux-aws regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
USN-3509-2 introduced a regression in the Linux HWE kernel for Ubuntu 14.04 LTS.
Software Description:
- linux-lts-xenial: Linux hardware enablement kernel from Xenial for Trusty
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
Details:
USN-3509-2 fixed vulnerabilities in the Linux Hardware Enablement
kernel for Ubuntu 14.04 LTS. Unfortunately, it also introduced a
regression that prevented the Ceph network filesystem from being
used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
linux-image-4.4.0-1006-aws 4.4.0-1006.6
linux-image-4.4.0-104-generic 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-lowlatency 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127~14.04.1
linux-image-aws 4.4.0.1006.6
linux-image-generic-lpae-lts-xenial 4.4.0.104.87
linux-image-generic-lts-xenial 4.4.0.104.87
linux-image-lowlatency-lts-xenial 4.4.0.104.87
linux-image-powerpc-e500mc-lts-xenial 4.4.0.104.87
linux-image-powerpc-smp-lts-xenial 4.4.0.104.87
linux-image-powerpc64-emb-lts-xenial 4.4.0.104.87
linux-image-powerpc64-smp-lts-xenial 4.4.0.104.87
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-4
https://www.ubuntu.com/usn/usn-3509-2
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1006.6
https://launchpad.net/ubuntu/+source/linux-lts-xenial/4.4.0-104.127~14.04.1
Ubuntu Security Notice USN-3509-4
December 15, 2017
linux-lts-xenial, linux-aws regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
USN-3509-2 introduced a regression in the Linux HWE kernel for Ubuntu 14.04 LTS.
Software Description:
- linux-lts-xenial: Linux hardware enablement kernel from Xenial for Trusty
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems
Details:
USN-3509-2 fixed vulnerabilities in the Linux Hardware Enablement
kernel for Ubuntu 14.04 LTS. Unfortunately, it also introduced a
regression that prevented the Ceph network filesystem from being
used. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
Mohamed Ghannam discovered that a use-after-free vulnerability existed in
the Netlink subsystem (XFRM) in the Linux kernel. A local attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2017-16939)
It was discovered that the Linux kernel did not properly handle copy-on-
write of transparent huge pages. A local attacker could use this to cause a
denial of service (application crashes) or possibly gain administrative
privileges. (CVE-2017-1000405)
Fan Wu, Haoran Qiu, and Shixiong Zhao discovered that the associative array
implementation in the Linux kernel sometimes did not properly handle adding
a new entry. A local attacker could use this to cause a denial of service
(system crash). (CVE-2017-12193)
Andrey Konovalov discovered an out-of-bounds read in the GTCO digitizer USB
driver for the Linux kernel. A physically proximate attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2017-16643)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
linux-image-4.4.0-1006-aws 4.4.0-1006.6
linux-image-4.4.0-104-generic 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-generic-lpae 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-lowlatency 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-e500mc 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc-smp 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-emb 4.4.0-104.127~14.04.1
linux-image-4.4.0-104-powerpc64-smp 4.4.0-104.127~14.04.1
linux-image-aws 4.4.0.1006.6
linux-image-generic-lpae-lts-xenial 4.4.0.104.87
linux-image-generic-lts-xenial 4.4.0.104.87
linux-image-lowlatency-lts-xenial 4.4.0.104.87
linux-image-powerpc-e500mc-lts-xenial 4.4.0.104.87
linux-image-powerpc-smp-lts-xenial 4.4.0.104.87
linux-image-powerpc64-emb-lts-xenial 4.4.0.104.87
linux-image-powerpc64-smp-lts-xenial 4.4.0.104.87
After a standard system update you need to reboot your computer to make
all the necessary changes.
ATTENTION: Due to an unavoidable ABI change the kernel updates have
been given a new version number, which requires you to recompile and
reinstall all third party kernel modules you might have installed.
Unless you manually uninstalled the standard kernel metapackages
(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,
linux-powerpc), a standard system upgrade will automatically perform
this as well.
References:
https://www.ubuntu.com/usn/usn-3509-4
https://www.ubuntu.com/usn/usn-3509-2
https://www.ubuntu.com/usn/usn-3509-1
https://launchpad.net/bugs/1737033
Package Information:
https://launchpad.net/ubuntu/+source/linux-aws/4.4.0-1006.6
https://launchpad.net/ubuntu/+source/linux-lts-xenial/4.4.0-104.127~14.04.1
Wednesday, December 13, 2017
[CentOS-announce] Announcing the release for Gluster 3.13 on CentOS Linux 6 x86_64
I am happy to announce the General Availability of Gluster 3.13 for
CentOS 6 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 6 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects.
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
CentOS 6 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 6 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects.
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
[CentOS-announce] Announcing the release for Gluster 3.13 on CentOS Linux 7 x86_64
I am happy to announce the General Availability of Gluster 3.13 for
CentOS 7 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 7 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects (possibly for oVirt, there may be others).
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
CentOS 7 on x86_64. These packages are following the upstream Gluster
Community releases, and will receive monthly bugfix updates.
Gluster 3.13 is a Short-Term-Maintenance release, and will only receive
updates until the next version (4.0) becomes available. The difference
between Long-Term-Maintenance and Short-Term-Maintenance releases is
explained on the Gluster release schedule page:
https://www.gluster.org/community/release-schedule/
Users of CentOS 7 can now simply install Gluster 3.13 with only these two
commands:
# yum install centos-release-gluster313
# yum install glusterfs-server
The centos-release-gluster313 package is delivered via CentOS Extras
repos. This contains all the metadata and dependancy information, needed
to install Gluster 3.13.
Note that the standard centos-release-gluster (virtual) package is
still available and points to the 3.12 version. This is intentional
because 3.12 is a Long-Term-Maintenance version and does not require
users to update the major versions avery couple of months. Some
deployments may need to install the centos-release-gluster package as
well as centos-release-gluster313 to fullfill dependencies for other
projects (possibly for oVirt, there may be others).
We have a quickstart guide specifically built around the packages are
available, it makes for a good introduction to Gluster and will help get
you started in just a few simple steps, this quick start is available at
https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart
More details about the packages that the Gluster project provides in the
Storage SIG is available in the documentation:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster
The centos-release-gluster* repositories offer additional packages that
enhance the usability of Gluster itself. Utilities and tools that were
working with previous versions of Gluster are expected to stay working
fine. If there are any proboems, or requests for additional tools and
applications to be provided, just send us an email with your
suggestions. The current list of packages that is (planned to become)
available can be found here:
https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs
We welcome all feedback, comments and contributions. You can get in
touch with the CentOS Storage SIG on the centos-devel mailing list
( https://lists.centos.org ) and with the Gluster developer and user
communities at https://www.gluster.org/mailman/listinfo , we are also
available on irc at #gluster on irc.freenode.net, and on twitter at
@gluster .
Cheers,
Niels de Vos
Storage SIG member & Gluster maintainer
[USN-3513-2] libxml2 vulnerability
==========================================================================
Ubuntu Security Notice USN-3513-2
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
USN-3513-1 fixed a vulnerability in libxml2. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libxml2 2.7.8.dfsg-5.1ubuntu4.20
libxml2-utils 2.7.8.dfsg-5.1ubuntu4.20
python-libxml2 2.7.8.dfsg-5.1ubuntu4.20
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-2
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
Ubuntu Security Notice USN-3513-2
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 12.04 ESM
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
USN-3513-1 fixed a vulnerability in libxml2. This update provides
the corresponding update for Ubuntu 12.04 ESM.
Original advisory details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 12.04 ESM:
libxml2 2.7.8.dfsg-5.1ubuntu4.20
libxml2-utils 2.7.8.dfsg-5.1ubuntu4.20
python-libxml2 2.7.8.dfsg-5.1ubuntu4.20
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-2
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
[USN-3513-1] libxml2 vulnerability
==========================================================================
Ubuntu Security Notice USN-3513-1
December 13, 2017
Ubuntu Security Notice USN-3513-1
December 13, 2017
libxml2 vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 17.10
- Ubuntu 17.04
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
libxml2 could be made to crash or run arbitrary code if it
opened a specially crafted file.
Software Description:
- libxml2: GNOME XML library
Details:
It was discovered that libxml2 incorrecty handled certain files. An
attacker could use this issue with specially constructed XML data to
cause libxml2 to consume resources, leading to a denial of service.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 17.10:
libxml2 2.9.4+dfsg1-4ubuntu1.2
libxml2-utils 2.9.4+dfsg1-4ubuntu1.2
python-libxml2 2.9.4+dfsg1-4ubuntu1.2
python3-libxml2 2.9.4+dfsg1-4ubuntu1.2
Ubuntu 17.04:
libxml2 2.9.4+dfsg1-2.2ubuntu0.3
libxml2-utils 2.9.4+dfsg1-2.2ubuntu0.3
python-libxml2 2.9.4+dfsg1-2.2ubuntu0.3
python3-libxml2 2.9.4+dfsg1-2.2ubuntu0.3
Ubuntu 16.04 LTS:
libxml2 2.9.3+dfsg1-1ubuntu0.5
libxml2-utils 2.9.3+dfsg1-1ubuntu0.5
python-libxml2 2.9.3+dfsg1-1ubuntu0.5
Ubuntu 14.04 LTS:
libxml2 2.9.1+dfsg1-3ubuntu4.12
libxml2-utils 2.9.1+dfsg1-3ubuntu4.12
python-libxml2 2.9.1+dfsg1-3ubuntu4.12
In general, a standard system update will make all the necessary
changes.
References:
https://www.ubuntu.com/usn/usn-3513-1
CVE-2017-15412
Package Information:
https://launchpad.net/ubuntu/+source/libxml2/2.9.4+dfsg1-4ubuntu1.2
https://launchpad.net/ubuntu/+source/libxml2/2.9.4+dfsg1-2.2ubuntu0.3
https://launchpad.net/ubuntu/+source/libxml2/2.9.3+dfsg1-1ubuntu0.5
https://launchpad.net/ubuntu/+source/libxml2/2.9.1+dfsg1-3ubuntu4.12
Tuesday, December 12, 2017
Fedora 27 Server classic release after all — and Modularity goes back to the drawing board
You may remember reading about our plans for Fedora 27 Server. The
working group decided not to release that at the same time as the
general F27 release, and instead provided a beta of Fedora 27
Modular Server. Based on feedback from that beta, they decided to
take a different approach, and the Modularity subproject is going
back to the drawing board.
Fortunately, there is a contingency plan: Fedora's release
engineering team made a "classic" version of Fedora 27 Server —
very similar to F26 Server, but with F27's updated package set. The
quality assurance ran this version through validation testing, and
it's being released, so:
Quick Summary
-------------
* You can now download Fedora 27 Server from the Get Fedora site.
https://getfedora.org/server/
This is the "classic" Fedora Server, without Modularity.
* The Modularity Working Group is going back to the drawing
board. Plans are still in progress, but it will likely produce a
separate package repository which will build on top of and coexist
with the traditional Fedora operating systems.
Modularity Past and Future
--------------------------
Modularity has a very straightforward mission: to enable Fedora to
deliver multiple versions of components on different lifecycles
across multiple base OS releases. It includes some other ideas
about improving packager and user experiences in the process, but
that's the basic thing. Every Linux user has some things they want
to move quickly, and others they want to not worry about. Fedora
wants to give you that choice.
The approach in last summer's "Boltron" and the recent beta
envisioned an entirely new distribution of Fedora software, with
the base operating system itself composed as a module. This offers
some interesting benefits — in particular, it keeps the build
dependencies of a piece of software well-defined and
well-contained. But it has a huge drawback: if some random piece of
software isn't contained in a module, it wouldn't be available on
that edition of Fedora at all. Also, the definition files for
modules were another layer of complication, and it became clear
that wouldn't get to an acceptable level of available software for
real use.
So, the Modularity Working Group and Server Working Group together
decided, rather than offer users and early adopters another
iteration down that path, to release the traditional Fedora 27
Server you can find above and take a different approach. The teams
are still working out what exactly that will look like, but the
most promising involves adding an entirely separate package
repository which can be layered on top of traditional Fedora,
rather than building a new modular base operating system. This will
make it easy for users to opt-in when they want to, and greatly
reduces the complication for packagers.
"First" is one of the core foundations of the Fedora Project. At
the leading edge of innovation, every step Fedora takes advances
the state of the art, even when it's not directly successful. And,
if every try succeeds, Fedora's not trying hard enough. Sometimes
experiments produce negative results. That's okay — the project
learns even when trying a path that doesn't work out, and it
iterates to something better. That process is happening now, and if
you're interested, please join the conversation on the devel
mailing list or watch for updates on the Fedora Community Blog in
the Modularity Category.
https://communityblog.fedoraproject.org/category/modularity/
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
announce mailing list -- announce@lists.fedoraproject.org
To unsubscribe send an email to announce-leave@lists.fedoraproject.org
working group decided not to release that at the same time as the
general F27 release, and instead provided a beta of Fedora 27
Modular Server. Based on feedback from that beta, they decided to
take a different approach, and the Modularity subproject is going
back to the drawing board.
Fortunately, there is a contingency plan: Fedora's release
engineering team made a "classic" version of Fedora 27 Server —
very similar to F26 Server, but with F27's updated package set. The
quality assurance ran this version through validation testing, and
it's being released, so:
Quick Summary
-------------
* You can now download Fedora 27 Server from the Get Fedora site.
https://getfedora.org/server/
This is the "classic" Fedora Server, without Modularity.
* The Modularity Working Group is going back to the drawing
board. Plans are still in progress, but it will likely produce a
separate package repository which will build on top of and coexist
with the traditional Fedora operating systems.
Modularity Past and Future
--------------------------
Modularity has a very straightforward mission: to enable Fedora to
deliver multiple versions of components on different lifecycles
across multiple base OS releases. It includes some other ideas
about improving packager and user experiences in the process, but
that's the basic thing. Every Linux user has some things they want
to move quickly, and others they want to not worry about. Fedora
wants to give you that choice.
The approach in last summer's "Boltron" and the recent beta
envisioned an entirely new distribution of Fedora software, with
the base operating system itself composed as a module. This offers
some interesting benefits — in particular, it keeps the build
dependencies of a piece of software well-defined and
well-contained. But it has a huge drawback: if some random piece of
software isn't contained in a module, it wouldn't be available on
that edition of Fedora at all. Also, the definition files for
modules were another layer of complication, and it became clear
that wouldn't get to an acceptable level of available software for
real use.
So, the Modularity Working Group and Server Working Group together
decided, rather than offer users and early adopters another
iteration down that path, to release the traditional Fedora 27
Server you can find above and take a different approach. The teams
are still working out what exactly that will look like, but the
most promising involves adding an entirely separate package
repository which can be layered on top of traditional Fedora,
rather than building a new modular base operating system. This will
make it easy for users to opt-in when they want to, and greatly
reduces the complication for packagers.
"First" is one of the core foundations of the Fedora Project. At
the leading edge of innovation, every step Fedora takes advances
the state of the art, even when it's not directly successful. And,
if every try succeeds, Fedora's not trying hard enough. Sometimes
experiments produce negative results. That's okay — the project
learns even when trying a path that doesn't work out, and it
iterates to something better. That process is happening now, and if
you're interested, please join the conversation on the devel
mailing list or watch for updates on the Fedora Community Blog in
the Modularity Category.
https://communityblog.fedoraproject.org/category/modularity/
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
announce mailing list -- announce@lists.fedoraproject.org
To unsubscribe send an email to announce-leave@lists.fedoraproject.org
Subscribe to:
Posts (Atom)