CentOS Errata and Security Advisory 2018:1957 Important
Upstream details at : https://access.redhat.com/errata/RHSA-2018:1957
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
167fd79268f2b8fdfa6ee58092dcaf8236ccca141d5f7eae97ecfeed7ecd7b43 emacs-git-1.8.3.1-14.el7_5.noarch.rpm
55b0c4b3ae8ec08ef3ffd76cd439c8c9c7a8b14f0b3f2ba360a1e92f308eab4c emacs-git-el-1.8.3.1-14.el7_5.noarch.rpm
fd449c6043c02bc1b4f887c0a2a49a363876ff74dca584193d0e0b2d2f626ad7 git-1.8.3.1-14.el7_5.x86_64.rpm
a5c0ae80f60567126c4b5a6064f35f47b204225b4af133b86e6d1f95670f936b git-all-1.8.3.1-14.el7_5.noarch.rpm
be9132d10409efd7ab01d6be469d2a0adf43bfcadeb7f4baeeb4ca1d0b398153 git-bzr-1.8.3.1-14.el7_5.noarch.rpm
62869df37659056de226a727e39c68e970912b4234195426d4be81f237e8c401 git-cvs-1.8.3.1-14.el7_5.noarch.rpm
1bbfbc68feb28abb5287f446ec3e7793fed9d02ec82ce6b1988de6a545e916f8 git-daemon-1.8.3.1-14.el7_5.x86_64.rpm
c47eb38ac2d722f42506456386fcce3e9189d393440915e51d89ff62550541db git-email-1.8.3.1-14.el7_5.noarch.rpm
c5bbdb6ba3c98007b2499cac78be95477e7af8a973e806e485556af2149f9289 git-gui-1.8.3.1-14.el7_5.noarch.rpm
b3ba3bf4e07d848ecd00f27fda64f5fa29ace32b7057f67508181abb540e3498 git-hg-1.8.3.1-14.el7_5.noarch.rpm
3827997cf98b18a3c8772971b0b2e1d95047ec05c463d714d2e54f7b43fa0176 gitk-1.8.3.1-14.el7_5.noarch.rpm
4b37b601b4d5ebdafd001bd2030245f31380941d782c8ede357a166ed82fc890 git-p4-1.8.3.1-14.el7_5.noarch.rpm
76c0b861bef3543ed2d9b9f9816036417432ab8310ff26ade51fd41d37f8e44a git-svn-1.8.3.1-14.el7_5.x86_64.rpm
65d06e031321d768b1cf6828d745621777a596e220cc15cc9078435ee10ba67a gitweb-1.8.3.1-14.el7_5.noarch.rpm
b83ca338e62ff77dbc73e0f35f1501cc7164d936d1b54f47dbbbdc0626490bec perl-Git-1.8.3.1-14.el7_5.noarch.rpm
b5875a3f8d0a8e228625d5c9f59cf8116ab5112fcdb58d9ef2957a2dbd6123ec perl-Git-SVN-1.8.3.1-14.el7_5.noarch.rpm
Source:
2877d887cac48bd998e54341ed6534afb0508759cddc6bee1cac899b3a3173b1 git-1.8.3.1-14.el7_5.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Friday, June 22, 2018
Thursday, June 21, 2018
Re: OpenBSD Errata: June 17th, 2018 (intelfpu)
On Sun, Jun 17, 2018 at 09:29:48AM -0400, T.J. Townsend wrote:
> Errata patches for x86 floating-point units have been released for OpenBSD 6.3.
>
> Intel CPUs speculatively access FPU registers even when the FPU is disabled,
> so data (including AES keys) from previous contexts could be discovered if
> using the lazy-save approach.
>
> Binary updates for the amd64 platform are available via the syspatch utility.
> Source code patches can be found on the errata page:
>
> https://www.openbsd.org/errata63.html
>
> As this affects the kernel, a reboot will be needed after patching.
>
Errata patches and binary updates for this issue are now also available
for OpenBSD 6.2/amd64:
https://www.openbsd.org/errata62.html
> Errata patches for x86 floating-point units have been released for OpenBSD 6.3.
>
> Intel CPUs speculatively access FPU registers even when the FPU is disabled,
> so data (including AES keys) from previous contexts could be discovered if
> using the lazy-save approach.
>
> Binary updates for the amd64 platform are available via the syspatch utility.
> Source code patches can be found on the errata page:
>
> https://www.openbsd.org/errata63.html
>
> As this affects the kernel, a reboot will be needed after patching.
>
Errata patches and binary updates for this issue are now also available
for OpenBSD 6.2/amd64:
https://www.openbsd.org/errata62.html
[USN-3691-1] OpenJDK 7 vulnerabilities
==========================================================================
Ubuntu Security Notice USN-3691-1
June 21, 2018
openjdk-7 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
Several security issues were fixed in OpenJDK 7.
Software Description:
- openjdk-7: Open Source Java implementation
Details:
It was discovered that the Security component of OpenJDK did not correctly
perform merging of multiple sections for the same file listed in JAR
archive file manifests. An attacker could possibly use this to modify
attributes in a manifest without invalidating the signature.
(CVE-2018-2790)
Francesco Palmarini, Marco Squarcina, Mauro Tempesta, and Riccardo Focardi
discovered that the Security component of OpenJDK did not restrict which
classes could be used when deserializing keys from the JCEKS key stores. An
attacker could use this to specially craft a JCEKS key store to execute
arbitrary code. (CVE-2018-2794)
It was discovered that the Security component of OpenJDK in some situations
did not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2795)
It was discovered that the Concurrency component of OpenJDK in some
situations did not properly limit the amount of memory allocated when
performing deserialization. An attacker could use this to cause a denial of
service (memory exhaustion). (CVE-2018-2796)
It was discovered that the JMX component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2797)
It was discovered that the AWT component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2798)
It was discovered that the JAXP component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2799)
Moritz Bechler discovered that the RMI component of OpenJDK enabled HTTP
transport for RMI servers by default. A remote attacker could use this to
gain access to restricted services. (CVE-2018-2800)
It was discovered that a vulnerability existed in the Hotspot component of
OpenJDK affecting confidentiality, data integrity, and availability. An
attacker could use this to specially craft an Java application that caused
a denial of service or bypassed sandbox restrictions. (CVE-2018-2814)
Apostolos Giannakidis discovered that the Serialization component of
OpenJDK did not properly bound memory allocations in some situations. An
attacker could use this to cause a denial of service (memory exhaustion).
(CVE-2018-2815)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
icedtea-7-jre-jamvm 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-headless 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-lib 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-zero 7u181-2.6.14-0ubuntu0.1
This update uses a new upstream release, which includes additional bug
fixes. After a standard system update you need to restart any Java
applications or applets to make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3691-1
CVE-2018-2790, CVE-2018-2794, CVE-2018-2795, CVE-2018-2796,
CVE-2018-2797, CVE-2018-2798, CVE-2018-2799, CVE-2018-2800,
CVE-2018-2814, CVE-2018-2815
Package Information:
https://launchpad.net/ubuntu/+source/openjdk-7/7u181-2.6.14-0ubuntu0.1
Ubuntu Security Notice USN-3691-1
June 21, 2018
openjdk-7 vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 14.04 LTS
Summary:
Several security issues were fixed in OpenJDK 7.
Software Description:
- openjdk-7: Open Source Java implementation
Details:
It was discovered that the Security component of OpenJDK did not correctly
perform merging of multiple sections for the same file listed in JAR
archive file manifests. An attacker could possibly use this to modify
attributes in a manifest without invalidating the signature.
(CVE-2018-2790)
Francesco Palmarini, Marco Squarcina, Mauro Tempesta, and Riccardo Focardi
discovered that the Security component of OpenJDK did not restrict which
classes could be used when deserializing keys from the JCEKS key stores. An
attacker could use this to specially craft a JCEKS key store to execute
arbitrary code. (CVE-2018-2794)
It was discovered that the Security component of OpenJDK in some situations
did not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2795)
It was discovered that the Concurrency component of OpenJDK in some
situations did not properly limit the amount of memory allocated when
performing deserialization. An attacker could use this to cause a denial of
service (memory exhaustion). (CVE-2018-2796)
It was discovered that the JMX component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2797)
It was discovered that the AWT component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2798)
It was discovered that the JAXP component of OpenJDK in some situations did
not properly limit the amount of memory allocated when performing
deserialization. An attacker could use this to cause a denial of service
(memory exhaustion). (CVE-2018-2799)
Moritz Bechler discovered that the RMI component of OpenJDK enabled HTTP
transport for RMI servers by default. A remote attacker could use this to
gain access to restricted services. (CVE-2018-2800)
It was discovered that a vulnerability existed in the Hotspot component of
OpenJDK affecting confidentiality, data integrity, and availability. An
attacker could use this to specially craft an Java application that caused
a denial of service or bypassed sandbox restrictions. (CVE-2018-2814)
Apostolos Giannakidis discovered that the Serialization component of
OpenJDK did not properly bound memory allocations in some situations. An
attacker could use this to cause a denial of service (memory exhaustion).
(CVE-2018-2815)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 14.04 LTS:
icedtea-7-jre-jamvm 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-headless 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-lib 7u181-2.6.14-0ubuntu0.1
openjdk-7-jre-zero 7u181-2.6.14-0ubuntu0.1
This update uses a new upstream release, which includes additional bug
fixes. After a standard system update you need to restart any Java
applications or applets to make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3691-1
CVE-2018-2790, CVE-2018-2794, CVE-2018-2795, CVE-2018-2796,
CVE-2018-2797, CVE-2018-2798, CVE-2018-2799, CVE-2018-2800,
CVE-2018-2814, CVE-2018-2815
Package Information:
https://launchpad.net/ubuntu/+source/openjdk-7/7u181-2.6.14-0ubuntu0.1
OpenBSD Errata: June 21th, 2018 (perl)
Errata patches for perl have been released for OpenBSD 6.2 and 6.3.
Perl's Archive::Tar module could be made to write files outside of
its working directory.
Binary updates for the amd64, i386, and arm64 platforms are available
via the syspatch utility. Source code patches can be found on the
respective errata pages:
https://www.openbsd.org/errata62.html
https://www.openbsd.org/errata63.html
Perl's Archive::Tar module could be made to write files outside of
its working directory.
Binary updates for the amd64, i386, and arm64 platforms are available
via the syspatch utility. Source code patches can be found on the
respective errata pages:
https://www.openbsd.org/errata62.html
https://www.openbsd.org/errata63.html
Red Hat bugzilla upgrade coming -- test now!
Red Hat is planning on upgrading Bugzilla to BZ5 in September. There's
a test instance running now at http://bugzilla5.redhat.com/
Since Fedora is a major user and stakeholder here, it'd be helpful if
we make sure everything works for us. If you find any bugs, report at
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=5.0
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/
a test instance running now at http://bugzilla5.redhat.com/
Since Fedora is a major user and stakeholder here, it'd be helpful if
we make sure everything works for us. If you find any bugs, report at
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=5.0
--
Matthew Miller
<mattdm@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/ZWVCDPB3CBEJJ5FQOGVFA2RAWWK3NOXK/
F29 System Wide Change: IBus 1.5.19
= Proposed System Wide Change: IBus 1.5.19 =
https://fedoraproject.org/wiki/Changes/IBus_1.5.19
Owner(s):
* Takao Fujiwara <fujiwara at redhat dot com>
IBus 1.5.19 will have two features.
# Move the input entry on IBus emoji dialog to the input entry on each
application using IBus pre-edit text so that the focus event is not
changed when the emoji typing is enabled# Ctrl-Shift-u feature of
typing Unicode code points is separated from Ctrl-Shift-e feature so
that neither an additional dialog or popup window is needed.
# Typing compose keys will have a pre-edit text
== Detailed description ==
Currently Ctrl-Shift-e launches an IBus emoji dialog and users type
emoji annotations in an input entry on the dialog and the input entry
can convert the muti-byte annotation to an emoji character, besides
ASCII annotation. However the dialog takes the current input focus in
any desktop environments and also the dialog position cannot
determined in Wayland because the dialog has no parent windows.
IBus 1.5.19 will move the input entry on the emoji dialog to the
current input context on each applications using IBus pre-edit
feature. Users type emoji annotations on the pre-edit text after they
type Ctrl-Shift-e and typing space key launches a lookup window to
show emoji candidates.
Currently Ctrl-Shift-u feature of typing Unicode code point is
consolidated in the emoji dialog because one shortcut key of
Ctrl-Shift-e can cover the feature but the code point feature would
not need to launch the dialog because the candidate character is only
one so IBus 1.5.19 will separate the Ctrl-Shift-u feature from
Ctrl-Shift-e one and both keybindings can be customizable with
ibus-setup.
Currently IBus compose feature does not show anything until the output
character is determined. IBus 1.5.9 will shows the pre-edit text
during users compose a sequence.
E.g. Multi_key-apostrophe-e outputs 'é' and shows the apostrophe as a
character on the pre-edit until 'e' is typed.
== Scope ==
* Proposal owners:
IBusEngine class will be changed in ibus-libs package to handle
Ctrl-Shift-e and Ctrl-Shift-u and it will effects all IBus engines.
* Other developers:
N/A
* Release engineering:
#7582 [https://pagure.io/releng/issue/7582]
** List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/IHIKAUYGSUUA6FXE5DM5KKOX7MM3INHM/
https://fedoraproject.org/wiki/Changes/IBus_1.5.19
Owner(s):
* Takao Fujiwara <fujiwara at redhat dot com>
IBus 1.5.19 will have two features.
# Move the input entry on IBus emoji dialog to the input entry on each
application using IBus pre-edit text so that the focus event is not
changed when the emoji typing is enabled# Ctrl-Shift-u feature of
typing Unicode code points is separated from Ctrl-Shift-e feature so
that neither an additional dialog or popup window is needed.
# Typing compose keys will have a pre-edit text
== Detailed description ==
Currently Ctrl-Shift-e launches an IBus emoji dialog and users type
emoji annotations in an input entry on the dialog and the input entry
can convert the muti-byte annotation to an emoji character, besides
ASCII annotation. However the dialog takes the current input focus in
any desktop environments and also the dialog position cannot
determined in Wayland because the dialog has no parent windows.
IBus 1.5.19 will move the input entry on the emoji dialog to the
current input context on each applications using IBus pre-edit
feature. Users type emoji annotations on the pre-edit text after they
type Ctrl-Shift-e and typing space key launches a lookup window to
show emoji candidates.
Currently Ctrl-Shift-u feature of typing Unicode code point is
consolidated in the emoji dialog because one shortcut key of
Ctrl-Shift-e can cover the feature but the code point feature would
not need to launch the dialog because the candidate character is only
one so IBus 1.5.19 will separate the Ctrl-Shift-u feature from
Ctrl-Shift-e one and both keybindings can be customizable with
ibus-setup.
Currently IBus compose feature does not show anything until the output
character is determined. IBus 1.5.9 will shows the pre-edit text
during users compose a sequence.
E.g. Multi_key-apostrophe-e outputs 'é' and shows the apostrophe as a
character on the pre-edit until 'e' is typed.
== Scope ==
* Proposal owners:
IBusEngine class will be changed in ibus-libs package to handle
Ctrl-Shift-e and Ctrl-Shift-u and it will effects all IBus engines.
* Other developers:
N/A
* Release engineering:
#7582 [https://pagure.io/releng/issue/7582]
** List of deliverables:
N/A
* Policies and guidelines:
N/A
* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/IHIKAUYGSUUA6FXE5DM5KKOX7MM3INHM/
[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-18:07.pmap
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-18:07.pmap Errata Notice
The FreeBSD Project
Topic: Incorrect TLB shootdown for Xen based guests
Category: core
Module: kernel
Announced: 2018-06-21
Credits: Colin Percival
Affects: FreeBSD 11.1
Corrected: 2018-05-22 14:36:46 UTC (stable/11, 11.2-BETA2)
2018-06-21 05:18:08 UTC (releng/11.1, 11.1-RELEASE-p11)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:https://security.FreeBSD.org/>.
I. Background
CPUs rely on a Translation Lookaside Buffer (TLB) to cache virtual memory
paging information. When a page is unmapped from the virtual address space
of a process on a multiprocessor system, an Inter-Processor Interrupt (IPI)
may be sent to instruct other CPUs to invalidate ("shoot down") their TLB
entries for the addresses in question.
For virtualization-related performance reasons, FreeBSD has IPI code for the
Xen platform which is separate from the generic x86 IPI code.
II. Problem Description
In the course of changes to the FreeBSD virtual memory system to address
FreeBSD-SA-18:03.speculative_execution, changes were made to the IPIs used
for shooting down TLB entries. Unfortunately, the IPI handlers for Xen were
left non-PTI, even when PTI was enabled, which result in TLB shootdowns for
the user mode portion of the address space not being consistently performed
correctly.
III. Impact
Processes on Xen based guests may "see" pages of memory which were previously
mapped but have since been unmapped, resulted in data being corrupted and/or
processes crashing due to internal data structures becoming inconsistent.
IV. Workaround
Only Xen based guests are affected by this issue. All other platforms are
not susceptible.
For Xen based guests, disabling PTI will workaround the issue. Add the
following line to /boot/loader.conf:
vm.pmap.pti=0
Please be aware, by disabling PTI, the system will be vulnerable to
FreeBSD-SA-18:03.speculative_execution.
V. Solution
Perform one of the following:
1) Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
Afterward, reboot the system.
2) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
3) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/EN-18:07/pmap.patch
# fetch https://security.FreeBSD.org/patches/EN-18:07/pmap.patch.asc
# gpg --verify pmap.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/11/ r334047
releng/11.1/ r335466
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
The latest revision of this notice is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-18:07.pmap.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlsrN3hfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cIOow/+P+zdQ8dmZcEIy7HjYdpTAbPIGNnSdvuXV5O5XGamOziTJOuEEDBxeNiE
QE9VM8a94Ybl0CJZhfBVPhqrDpYuXOqKvnfHlcXWjppDliUPWohF6kTj4ugqGKrl
T2VckEvjltgJQ1/XqnkE7n1LuezLcqF/RbW3xOeRkAhf3X+IXd/E3uCuw/n4yknl
O5EvLmjq3bGlN7OfHOM4E+PHvYOxxfbjYH5S+1Z9g0/apR6HOUi9WU0hV5YEB9Cz
hUCsnx15Nla97jD9P1xy0tr3FkPpvZRJGj2BelNaQoFNrZB7oWB9xwOmwSqxye/b
zvp+/WUuGlo1KWU8RldzVPP6A7piuL6oAvYqW8/wcpwd9HqNGXblWz1XodpE3x1F
TKHTGcP/e/wgU6810SolylwJKxhGVZaQK3UH1iVKPRRTw+HUR1OVDY+q7XAyFD7c
QbKRyWQIYr2X98LhiT8TMVssharFg7AcviRSDEdCYt+A6S9jiDWMe+C3hGndSSET
Cf/0q6PQ89GQKw3lQOgwvtWlMaKPwfg3W8lxkusK5o935aXWhbRee3Hzkld7eUl0
8/uGBCgDnSk7hPIHLDcddIKI+QT0IpHKCPlBRRoTJUhpXo/g5bVkbUnMKBZ7zf3O
mBvci+KPc2yqp///fw1eMhgRTOOOOnXAHUMsb/FH1b+yIcikudo=
=fw9I
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
Hash: SHA512
=============================================================================
FreeBSD-EN-18:07.pmap Errata Notice
The FreeBSD Project
Topic: Incorrect TLB shootdown for Xen based guests
Category: core
Module: kernel
Announced: 2018-06-21
Credits: Colin Percival
Affects: FreeBSD 11.1
Corrected: 2018-05-22 14:36:46 UTC (stable/11, 11.2-BETA2)
2018-06-21 05:18:08 UTC (releng/11.1, 11.1-RELEASE-p11)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:https://security.FreeBSD.org/>.
I. Background
CPUs rely on a Translation Lookaside Buffer (TLB) to cache virtual memory
paging information. When a page is unmapped from the virtual address space
of a process on a multiprocessor system, an Inter-Processor Interrupt (IPI)
may be sent to instruct other CPUs to invalidate ("shoot down") their TLB
entries for the addresses in question.
For virtualization-related performance reasons, FreeBSD has IPI code for the
Xen platform which is separate from the generic x86 IPI code.
II. Problem Description
In the course of changes to the FreeBSD virtual memory system to address
FreeBSD-SA-18:03.speculative_execution, changes were made to the IPIs used
for shooting down TLB entries. Unfortunately, the IPI handlers for Xen were
left non-PTI, even when PTI was enabled, which result in TLB shootdowns for
the user mode portion of the address space not being consistently performed
correctly.
III. Impact
Processes on Xen based guests may "see" pages of memory which were previously
mapped but have since been unmapped, resulted in data being corrupted and/or
processes crashing due to internal data structures becoming inconsistent.
IV. Workaround
Only Xen based guests are affected by this issue. All other platforms are
not susceptible.
For Xen based guests, disabling PTI will workaround the issue. Add the
following line to /boot/loader.conf:
vm.pmap.pti=0
Please be aware, by disabling PTI, the system will be vulnerable to
FreeBSD-SA-18:03.speculative_execution.
V. Solution
Perform one of the following:
1) Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
Afterward, reboot the system.
2) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
3) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/EN-18:07/pmap.patch
# fetch https://security.FreeBSD.org/patches/EN-18:07/pmap.patch.asc
# gpg --verify pmap.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/11/ r334047
releng/11.1/ r335466
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
The latest revision of this notice is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-18:07.pmap.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlsrN3hfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cIOow/+P+zdQ8dmZcEIy7HjYdpTAbPIGNnSdvuXV5O5XGamOziTJOuEEDBxeNiE
QE9VM8a94Ybl0CJZhfBVPhqrDpYuXOqKvnfHlcXWjppDliUPWohF6kTj4ugqGKrl
T2VckEvjltgJQ1/XqnkE7n1LuezLcqF/RbW3xOeRkAhf3X+IXd/E3uCuw/n4yknl
O5EvLmjq3bGlN7OfHOM4E+PHvYOxxfbjYH5S+1Z9g0/apR6HOUi9WU0hV5YEB9Cz
hUCsnx15Nla97jD9P1xy0tr3FkPpvZRJGj2BelNaQoFNrZB7oWB9xwOmwSqxye/b
zvp+/WUuGlo1KWU8RldzVPP6A7piuL6oAvYqW8/wcpwd9HqNGXblWz1XodpE3x1F
TKHTGcP/e/wgU6810SolylwJKxhGVZaQK3UH1iVKPRRTw+HUR1OVDY+q7XAyFD7c
QbKRyWQIYr2X98LhiT8TMVssharFg7AcviRSDEdCYt+A6S9jiDWMe+C3hGndSSET
Cf/0q6PQ89GQKw3lQOgwvtWlMaKPwfg3W8lxkusK5o935aXWhbRee3Hzkld7eUl0
8/uGBCgDnSk7hPIHLDcddIKI+QT0IpHKCPlBRRoTJUhpXo/g5bVkbUnMKBZ7zf3O
mBvci+KPc2yqp///fw1eMhgRTOOOOnXAHUMsb/FH1b+yIcikudo=
=fw9I
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
[FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-18:07.lazyfpu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-18:07.lazyfpu Security Advisory
The FreeBSD Project
Topic: Lazy FPU State Restore Information Disclosure
Category: core
Module: kernel
Announced: 2018-06-21
Credits: Julian Stecklina from Amazon Germany
Thomas Prescher from Cyberus Technology GmbH
Zdenek Sojka from SYSGO AG
Colin Percival
Affects: All supported version of FreeBSD.
Corrected: 2018-06-14 18:50:49 UTC (stable/11, 11.2-PRERELEASE)
2018-06-15 13:21:37 UTC (releng/11.2, 11.2-RC3)
2018-06-21 05:17:13 UTC (releng/11.1, 11.1-RELEASE-p11)
CVE Name: CVE-2018-3665
Special Note: This advisory only addresses this issue for FreeBSD 11.x on
i386 and amd64. We expect to update this advisory to include
10.x in the near future.
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
I. Background
Modern CPUs have a floating point unit (FPU) which needs to maintain state
per thread. One technique is to only save and to only restore the FPU state
for a thread when a thread attempts to utilize the FPU. This technique is
called Lazy FPU state restore.
II. Problem Description
A subset of Intel processors can allow a local thread to infer data from
another thread through a speculative execution side channel when Lazy FPU
state restore is used.
III. Impact
Any local thread can potentially read FPU state information from other
threads running on the host. This could include cryptographic keys when the
AES-NI CPU feature is present.
IV. Workaround
No workaround is available, but non-Intel branded CPUs are not believed
to be vulnerable.
V. Solution
The patch changes from Lazy FPU state restore to Eager FPU state restore.
This new technique is the recommended practice from Intel and in some cases
can actually increase performance, depending on workload.
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Afterward, reboot the system.
2) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
3) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/SA-18:07/lazyfpu-11.patch
# fetch https://security.FreeBSD.org/patches/SA-18:07/lazyfpu-11.patch.asc
# gpg --verify lazyfpu-11.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/11/ r335169
releng/11.2/ r335196
releng/11.1/ r335465
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html>
<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3665>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:07.lazyfpu.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlsrN1hfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJTLA/+Kt7QLkNCVudaiE+d+VMuC2f1aGhqoyd+36xL9rNsn2ShZhIo+gq1dhXn
2lJiOYCPN5cJkasj1YdP2bSIv25nTcFMp0rKOww0A1scOnzi66LAD+DXmGVUhmaA
MPyrnuL7rbuPq9ls9FGAO2XURwB9IrGYtqPuVWmNyn+HyKBYcGCkL5+UEnHeUCg8
oopJudZgrGBVMFCsqG6K/b+3uc397Hyq0PZzpyWFfkaxrbTwVMMwgWyTxIYaPVs7
2g7WK2JWjJNk0IWQGot9qpKYDRyxc9PPFX/0blwOLe1Wwrt5nEF+9av89HQJ6PXF
+Ws5w8Gnhi9wWuK19ew1j0nvP+f0zw09r4GuEzhZXADAz733HNK5dtsS/dMJi2wa
9fQ0s1joT3JFDvWZKUQS2mNuhpvBfYoI0d0OEJT2H2eycFYe4B+VNhB2V1e9wLn6
9X4+Vbc2LEOF09klQQFMYNMEyQzLtfq2gHIoD37sCw9mMrYKWjgy3NhY5AKrfGHG
OcBsvnaXCW/x9/kV9Pfoel/psrmjcQdp4QEKAZbRNwvJG5sGhtsQXTp0Nk+BCuVy
G0NNB9306dLfk0OTZ02SiOUjVagXObyo+LgWTBO6FryDlHVkopsYNkB5oRx9fLrm
68r7OXidl0ndGqnh87meMVH1/Fu/rr09Jd4osIzS+Gc0Dt7NOEQ=
=8fnI
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
Hash: SHA512
=============================================================================
FreeBSD-SA-18:07.lazyfpu Security Advisory
The FreeBSD Project
Topic: Lazy FPU State Restore Information Disclosure
Category: core
Module: kernel
Announced: 2018-06-21
Credits: Julian Stecklina from Amazon Germany
Thomas Prescher from Cyberus Technology GmbH
Zdenek Sojka from SYSGO AG
Colin Percival
Affects: All supported version of FreeBSD.
Corrected: 2018-06-14 18:50:49 UTC (stable/11, 11.2-PRERELEASE)
2018-06-15 13:21:37 UTC (releng/11.2, 11.2-RC3)
2018-06-21 05:17:13 UTC (releng/11.1, 11.1-RELEASE-p11)
CVE Name: CVE-2018-3665
Special Note: This advisory only addresses this issue for FreeBSD 11.x on
i386 and amd64. We expect to update this advisory to include
10.x in the near future.
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
I. Background
Modern CPUs have a floating point unit (FPU) which needs to maintain state
per thread. One technique is to only save and to only restore the FPU state
for a thread when a thread attempts to utilize the FPU. This technique is
called Lazy FPU state restore.
II. Problem Description
A subset of Intel processors can allow a local thread to infer data from
another thread through a speculative execution side channel when Lazy FPU
state restore is used.
III. Impact
Any local thread can potentially read FPU state information from other
threads running on the host. This could include cryptographic keys when the
AES-NI CPU feature is present.
IV. Workaround
No workaround is available, but non-Intel branded CPUs are not believed
to be vulnerable.
V. Solution
The patch changes from Lazy FPU state restore to Eager FPU state restore.
This new technique is the recommended practice from Intel and in some cases
can actually increase performance, depending on workload.
Perform one of the following:
1) Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Afterward, reboot the system.
2) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the i386 or amd64
platforms can be updated via the freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
Afterward, reboot the system.
3) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 11.1]
# fetch https://security.FreeBSD.org/patches/SA-18:07/lazyfpu-11.patch
# fetch https://security.FreeBSD.org/patches/SA-18:07/lazyfpu-11.patch.asc
# gpg --verify lazyfpu-11.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile your kernel as described in
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/11/ r335169
releng/11.2/ r335196
releng/11.1/ r335465
- -------------------------------------------------------------------------
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html>
<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3665>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-18:07.lazyfpu.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlsrN1hfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJTLA/+Kt7QLkNCVudaiE+d+VMuC2f1aGhqoyd+36xL9rNsn2ShZhIo+gq1dhXn
2lJiOYCPN5cJkasj1YdP2bSIv25nTcFMp0rKOww0A1scOnzi66LAD+DXmGVUhmaA
MPyrnuL7rbuPq9ls9FGAO2XURwB9IrGYtqPuVWmNyn+HyKBYcGCkL5+UEnHeUCg8
oopJudZgrGBVMFCsqG6K/b+3uc397Hyq0PZzpyWFfkaxrbTwVMMwgWyTxIYaPVs7
2g7WK2JWjJNk0IWQGot9qpKYDRyxc9PPFX/0blwOLe1Wwrt5nEF+9av89HQJ6PXF
+Ws5w8Gnhi9wWuK19ew1j0nvP+f0zw09r4GuEzhZXADAz733HNK5dtsS/dMJi2wa
9fQ0s1joT3JFDvWZKUQS2mNuhpvBfYoI0d0OEJT2H2eycFYe4B+VNhB2V1e9wLn6
9X4+Vbc2LEOF09klQQFMYNMEyQzLtfq2gHIoD37sCw9mMrYKWjgy3NhY5AKrfGHG
OcBsvnaXCW/x9/kV9Pfoel/psrmjcQdp4QEKAZbRNwvJG5sGhtsQXTp0Nk+BCuVy
G0NNB9306dLfk0OTZ02SiOUjVagXObyo+LgWTBO6FryDlHVkopsYNkB5oRx9fLrm
68r7OXidl0ndGqnh87meMVH1/Fu/rr09Jd4osIzS+Gc0Dt7NOEQ=
=8fnI
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
Wednesday, June 20, 2018
[USN-3690-1] AMD Microcode update
==========================================================================
Ubuntu Security Notice USN-3690-1
June 20, 2018
amd64-microcode update
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 17.10
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
The system could be made to expose sensitive information.
Software Description:
- amd64-microcode: Processor microcode firmware for AMD CPUs
Details:
Jann Horn discovered that microprocessors utilizing speculative execution
and branch prediction may allow unauthorized memory reads via sidechannel
attacks. This flaw is known as Spectre. A local attacker could use this to
expose sensitive information, including kernel memory.
This update provides the microcode updates for AMD 17H family
processors required for the corresponding Linux kernel updates.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.18.04.1
Ubuntu 17.10:
amd64-microcode 3.20180524.1~ubuntu0.17.10.1
Ubuntu 16.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.16.04.1
Ubuntu 14.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.14.04.1
After a standard system update you need to reboot your computer to make
all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3690-1
CVE-2017-5715
Package Information:
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.18.04.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.17.10.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.16.04.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.14.04.1
Ubuntu Security Notice USN-3690-1
June 20, 2018
amd64-microcode update
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 17.10
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
The system could be made to expose sensitive information.
Software Description:
- amd64-microcode: Processor microcode firmware for AMD CPUs
Details:
Jann Horn discovered that microprocessors utilizing speculative execution
and branch prediction may allow unauthorized memory reads via sidechannel
attacks. This flaw is known as Spectre. A local attacker could use this to
expose sensitive information, including kernel memory.
This update provides the microcode updates for AMD 17H family
processors required for the corresponding Linux kernel updates.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.18.04.1
Ubuntu 17.10:
amd64-microcode 3.20180524.1~ubuntu0.17.10.1
Ubuntu 16.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.16.04.1
Ubuntu 14.04 LTS:
amd64-microcode 3.20180524.1~ubuntu0.14.04.1
After a standard system update you need to reboot your computer to make
all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3690-1
CVE-2017-5715
Package Information:
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.18.04.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.17.10.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.16.04.1
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20180524.1~ubuntu0.14.04.1
F29 System Wide Change: Modules for Everyone
= Proposed System Wide Change: Modules for Everyone =
https://fedoraproject.org/wiki/Changes/ModulesForEveryone
Owner(s):
* Stephen Gallagher <sgallagh at fedoraproject dot org>
* Langdon White <langdon at fedoraproject dot org>
All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition.
== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality, allowing end-users access to alternative versions of popular software. Due to technical limitations with package-management software, it was not available for non-Server deployments of Fedora. Beginning with Fedora 29, all installations of Fedora will have modules available for installation and update. This will be done by merging the `fedora-repos-modular` sub-package back into the `fedora-repos` package.
== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and release-engineering to make sure that the repo subpackage merge only happens once the libdnf enhancements are stable. We will also need to prepare and run a Fedora Test Day with the QA team.
* Other developers:
The DNF team is already committed to providing the necessary changes for libdnf in Fedora 29.
* Release engineering:
#7561 [https://pagure.io/releng/issue/7561]
** List of deliverables:
All Fedora installations
* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this change
* Trademark approval:
N/A (not needed for this Change)
-- https://fedoraproject.org/wiki/Changes/ModulesForEveryone
Owner(s):
* Stephen Gallagher <sgallagh at fedoraproject dot org>
* Langdon White <langdon at fedoraproject dot org>
All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition.
== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality, allowing end-users access to alternative versions of popular software. Due to technical limitations with package-management software, it was not available for non-Server deployments of Fedora. Beginning with Fedora 29, all installations of Fedora will have modules available for installation and update. This will be done by merging the `fedora-repos-modular` sub-package back into the `fedora-repos` package.
== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and release-engineering to make sure that the repo subpackage merge only happens once the libdnf enhancements are stable. We will also need to prepare and run a Fedora Test Day with the QA team.
* Other developers:
The DNF team is already committed to providing the necessary changes for libdnf in Fedora 29.
* Release engineering:
#7561 [https://pagure.io/releng/issue/7561]
** List of deliverables:
All Fedora installations
* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this change
* Trademark approval:
N/A (not needed for this Change)
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Welcome to Fedora CoreOS
Hi everyone. If you saw my talk at DevConf.cz this year
(https://www.youtube.com/watch?v=CiCTTHoxv5c&t=890s), you'll
remember I discussed the Fedora / Red Hat relationship, and
specifically how Fedora has historically worked with new
technologies that come our way through acquisitions made by our
primary sponsor.
Little did I know, but at that very moment, something huge was in
the works, and when my plane landed back in Boston my phone blew up
with messages about CoreOS joining Red Hat.
That's obviously gigantic news, directly relevant to Fedora, since
we are the project Red Hat depends on for operating-system level
integration and innovation. Now, most of the news is about
Kubernetes, OpenShift, Tectonic, and Quay — but there's also
Container Linux (the operating system formerly known just as
"CoreOS"). At Red Hat Summit, the company announced and clarified a
bunch of things around product and corporate plans. Now, it's time
for us to figure out how we can welcome and include the Container
Linux community in the circle of Fedora Friends.
What does this mean for Fedora Atomic Host and other deliverables?
------------------------------------------------------------------
This isn't the place for technical details — see "what next?" at
the bottom of this message for more. I expect that over the next
year or so, Fedora Atomic Host will be replaced by a new thing
combining the best from Container Linux and Project Atomic. This
new thing will be "Fedora CoreOS" and serve as the upstream to Red
Hat CoreOS.
What does this mean for the Fedora community?
---------------------------------------------
Good things! Container Linux is exciting, innovative, and has a
passionate user and developer community. The people who built it
are awesome and well-aligned with the Fedora community foundations.
The "Fedora Editions" strategy intentionally makes space for
exploring emerging areas in operating system distributions. CoreOS
will help us push that even further and bring new ways of doing
things to the project as a whole.
What does this mean for Container Linux users?
----------------------------------------------
More good things! I know this is kind of scary. Fedora CoreOS is
going to be built from Fedora content rather than in the way it's
made now. It won't necessarily be made in the same way we make
Fedora OS deliverables today, though. No matter what, we absolutely
want the CoreOS user experience of "container cluster host OS that
keeps itself up-to-date and you just don't worry about it". Again,
technical details are a discussion for elsewhere, but the goal is
for existing Container Linux users to be as happy as — or happier
than! — you are with the OS today.
And here's the super-important thing: Fedora really is a
community-driven project, and this means that you can get involved
and directly influence how the future Fedora CoreOS works to meet
your needs. If you're interested and need help getting involved,
don't hesitate to talk to me, to the Join Fedora team, or to the
developers and community people already working on the project.
Hey, so… "Fedora Core"!
-----------------------
Everything's a circle, right? But, this has nothing to do with the
Red Hat vs. external split that was Fedora Core and Extras back in
the day. We absolutely do not want to regress to that kind of
community divide. "Core" just happens to be a pretty catchy name
component for an OS that fits the "small, focused base" concept.
This concept is powerful and useful for today's information
technology and computing world, and we want to give it proper focus
in Fedora.
Okay, so, what next?
--------------------
Visit the new website at https://coreos.fedoraproject.org/.
The project is just getting started, so there's not much there yet,
but we have an initial FAQ.
If you have questions that aren't answered, or just want to get
involved, join in discussion on the new Discourse board
https://discussion.fedoraproject.org/c/coreos, sign up for the the
development mailing list at
https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/,
and chat on Freenode IRC in #fedora-coreos.
--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/message/VY5L7JW5I6CGGPWNAN2AJU5MM5DGRWRI/
(https://www.youtube.com/watch?v=CiCTTHoxv5c&t=890s), you'll
remember I discussed the Fedora / Red Hat relationship, and
specifically how Fedora has historically worked with new
technologies that come our way through acquisitions made by our
primary sponsor.
Little did I know, but at that very moment, something huge was in
the works, and when my plane landed back in Boston my phone blew up
with messages about CoreOS joining Red Hat.
That's obviously gigantic news, directly relevant to Fedora, since
we are the project Red Hat depends on for operating-system level
integration and innovation. Now, most of the news is about
Kubernetes, OpenShift, Tectonic, and Quay — but there's also
Container Linux (the operating system formerly known just as
"CoreOS"). At Red Hat Summit, the company announced and clarified a
bunch of things around product and corporate plans. Now, it's time
for us to figure out how we can welcome and include the Container
Linux community in the circle of Fedora Friends.
What does this mean for Fedora Atomic Host and other deliverables?
------------------------------------------------------------------
This isn't the place for technical details — see "what next?" at
the bottom of this message for more. I expect that over the next
year or so, Fedora Atomic Host will be replaced by a new thing
combining the best from Container Linux and Project Atomic. This
new thing will be "Fedora CoreOS" and serve as the upstream to Red
Hat CoreOS.
What does this mean for the Fedora community?
---------------------------------------------
Good things! Container Linux is exciting, innovative, and has a
passionate user and developer community. The people who built it
are awesome and well-aligned with the Fedora community foundations.
The "Fedora Editions" strategy intentionally makes space for
exploring emerging areas in operating system distributions. CoreOS
will help us push that even further and bring new ways of doing
things to the project as a whole.
What does this mean for Container Linux users?
----------------------------------------------
More good things! I know this is kind of scary. Fedora CoreOS is
going to be built from Fedora content rather than in the way it's
made now. It won't necessarily be made in the same way we make
Fedora OS deliverables today, though. No matter what, we absolutely
want the CoreOS user experience of "container cluster host OS that
keeps itself up-to-date and you just don't worry about it". Again,
technical details are a discussion for elsewhere, but the goal is
for existing Container Linux users to be as happy as — or happier
than! — you are with the OS today.
And here's the super-important thing: Fedora really is a
community-driven project, and this means that you can get involved
and directly influence how the future Fedora CoreOS works to meet
your needs. If you're interested and need help getting involved,
don't hesitate to talk to me, to the Join Fedora team, or to the
developers and community people already working on the project.
Hey, so… "Fedora Core"!
-----------------------
Everything's a circle, right? But, this has nothing to do with the
Red Hat vs. external split that was Fedora Core and Extras back in
the day. We absolutely do not want to regress to that kind of
community divide. "Core" just happens to be a pretty catchy name
component for an OS that fits the "small, focused base" concept.
This concept is powerful and useful for today's information
technology and computing world, and we want to give it proper focus
in Fedora.
Okay, so, what next?
--------------------
Visit the new website at https://coreos.fedoraproject.org/.
The project is just getting started, so there's not much there yet,
but we have an initial FAQ.
If you have questions that aren't answered, or just want to get
involved, join in discussion on the new Discourse board
https://discussion.fedoraproject.org/c/coreos, sign up for the the
development mailing list at
https://lists.fedoraproject.org/archives/list/coreos@lists.fedoraproject.org/,
and chat on Freenode IRC in #fedora-coreos.
--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/message/VY5L7JW5I6CGGPWNAN2AJU5MM5DGRWRI/
F29 Self Contained Change: Origin 3.10
= Proposed Self Contained Change: Origin 3.10 =
https://fedoraproject.org/wiki/Changes/origin3.10
Owner(s):
* Jakub Čajka <jcajka at redhat dot com>
Rebase of the Openshift Origin package to the latest upstream version,
along with introduction of necessary infrastructure container images.
== Detailed description ==
Rebase of the Origin package to the latest upstream release. To note
upgrade path from previous version (3.9) will not be covered by this
change(dnf update origin, will most certainly be unable to cleanly
update Origin cluster), any one interested in helping out with the
supportable update path please reach out to the change owner or any
origin maintainer. Upstream provided update ansible playbooks are
located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades
== Scope ==
* Proposal owners:
rebase of the package, creation of the missing infrastructure container images
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
None
https://pagure.io/releng/issue/7581
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
None (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/JWVK5CLUDKH43PMQIGPDCNCPX6BIOWHJ/
https://fedoraproject.org/wiki/Changes/origin3.10
Owner(s):
* Jakub Čajka <jcajka at redhat dot com>
Rebase of the Openshift Origin package to the latest upstream version,
along with introduction of necessary infrastructure container images.
== Detailed description ==
Rebase of the Origin package to the latest upstream release. To note
upgrade path from previous version (3.9) will not be covered by this
change(dnf update origin, will most certainly be unable to cleanly
update Origin cluster), any one interested in helping out with the
supportable update path please reach out to the change owner or any
origin maintainer. Upstream provided update ansible playbooks are
located at https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades
== Scope ==
* Proposal owners:
rebase of the package, creation of the missing infrastructure container images
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
None
https://pagure.io/releng/issue/7581
** List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
None (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/JWVK5CLUDKH43PMQIGPDCNCPX6BIOWHJ/
Subscribe to:
Posts (Atom)