Congratulations to the last System-Wide Change proposal of F30!
https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_Langpacks
== Summary ==
Language support groups in Comps file will get replaced by langpacks
package. With this Change we want meta-packages like langpacks-ja to
also install required fonts and input-methods for the given language.
== Owner ==
* Name: [[User:petersen| Jens Petersen]]
* Email: petersen at fedoraproject dot org
* Name: [[User:pnemade| Parag Nemade]]
* Email: pnemade at fedoraproject dot org
== Detailed Description ==
This change will remove the need of having the language specific comps
groups in Fedora.
We already have ''langpacks-*'' packages in Fedora since F24.
Currently they are installing language packages for translations,
dictionaries etc. but not fonts or input-methods. With this Change we
will try to install fonts and input-methods as well.
E.g. if you net-install Fedora in Japanese language then installation
of any base package like libreoffice-core or man-pages are installing
automatically libreoffice-langpack-ja or man-pages-ja but langpacks-ja
is not installing any Japanese font or input-method.
But now with using RPM tags or weak dependencies like Supplements, we
can get font as well as input-method packages installed as well on the
system.
There is no need of language comps groups to exist, they will be
replaced by langpacks.
This Change is originally submitted at https://pagure.io/i18n/issue/97
== Benefit to Fedora ==
Users can install complete language support now using langpacks only.
This will also help to remove the language support groups from the
comps file.
== Scope ==
* Proposal owners: Check all langpacks providing packages (like fonts,
input-methods) add Supplements tag in their SPEC file and build them.
We will track the progress of this Change in
[https://copr.fedorainfracloud.org/coprs/pnemade/langpacks/ Langpacks
Copr] project.
* Other developers: To all other developers of packages who provides
langpacks, they need to add the Supplements tag as given in this
[https://fedoraproject.org/wiki/Packaging:Langpacks Langpacks
guideline] to each langpack subpackage.
* Release engineering: none
* Policies and guidelines: none
== Upgrade/compatibility impact ==
None.
== How To Test ==
* [[QA:Langpacks]]
== User Experience ==
Currently users can get complete language support installed only using
"''dnf group install <lang-support>''" command. After this Change gets
implemented end users can get language support installed using
meta-packages "''langpacks-<langcode>"'' only
== Dependencies ==
No Other Change depend on this.
== Contingency Plan ==
* Contingency mechanism: If this change is not completed by final
development freeze then we need to target this for F31. We are just
proposing to add additional information in langpacks packages that is
Supplements tag. This should not affect individual langpacks packages
installation by dnf.
* Contingency deadline: I don't think we will need anything to revert
or apply any contingency plan here if this is not completed by beta
freeze.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
* Need to add about this in the Release notes
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
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
Wednesday, January 9, 2019
[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:03.sqlite
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:03.sqlite Errata Notice
The FreeBSD Project
Topic: sqlite update
Category: contrib
Module: sqlite3
Announced: 2019-01-09
Credits: Cy Schubert
Affects: All supported versions of FreeBSD.
Corrected: 2018-12-21 01:58:01 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:47:10 UTC (releng/12.0, 12.0-RELEASE-p2)
2018-12-21 02:04:15 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:50:27 UTC (releng/11.2, 11.2-RELEASE-p8)
CVE Name: CVE-2018-20346, CVE-2018-20505, CVE-2018-20506
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
SQLite is an SQL database engine in a C library. Programs that link the
SQLite library can have SQL database access without running a separate RDBMS
process. The distribution comes with a standalone command-line access
program (sqlite3) that can be used to administer an SQLite database and which
serves as an example of how to use the SQLite library.
II. Problem Description
According to https://blade.tencent.com/magellan/index_en.html, the
vulnerabilities known as Magellan are a group vulnerabilities that exist
in sqlite3, documented by CVE-2018-20346, CVE-2018-20505, and CVE-2018-20506.
When the FTS3 extension is enabled an integer overflow resulting in a buffer
overflow when allowing remote attackers to run arbitrary SQL statements which
can be leveraged to execute arbitrary code.
III. Impact
The vulnerabilities were discovered by Tencent Blade Team and verified to be
able to successfully implement remote code execution in Chromium browsers.
IV. Workaround
No workaround is available.
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.
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
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.2]
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-11.patch
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-11.patch.asc
# gpg --verify sqlite-11.patch.asc
[FreeBSD 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-12.patch
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-12.patch.asc
# gpg --verify sqlite-12.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
Restart all daemons that use the library, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r342291
releng/12.0/ r342895
stable/11/ r342292
releng/11.2/ r342896
- -------------------------------------------------------------------------
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://blade.tencent.com/magellan/index_en.html>
<URL:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234113>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:03.sqlite.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cLtJg/9EM0jQbTBrSgVy5X1AyQ2rcFz9KbjtA0L48wOuOLiAh7eeYxh4Wxuz9k1
QnEJavMbpVr71yhmt6maEAbRzyGUvemDh4vlu0wjcYSlEzcvk7xaRzfXimippxky
GumFBCvs7UKDIiGRr62ukmxu3FgfEaTM/Cc4bNcuV5k4za+DWIGTu+97i0+B2ieX
/IZ5hQq42w1YIUY5QOy2vj87rnQf2t+uShcBjRg8HsnPsG9BfQfI8vfuWjjtaKMI
iva++F5UJWcsykjZo5J3aaZFxnHsW2hs3buQN+AhoEt7oKdGquOHdweSw8xtSlp9
3Y+qj+veD7u4Mt95OtnYrJOg8Kynlrzg5uMDbNGbyqktbxfpi2gqBbPEVmx2+nGj
Aj9PDSHMliBZsVKvr1opExfYp4HL0LB9Kqhato08lFxs05TUxiT6LRcel/iXiIfl
vCqfWhKJYVZ+alAW+Kjic6iWw7AtmVLbV64dDu03jxS/14RtRp1Hbk1BRCrnJeLn
sLSdFj6bi2mQx6OXAd9G9jhReoxylyZwRXyhPSsPG1E4mzX6ZRbJfnkriSazW4hq
F+PjTyXidn3uhS6z6CZB08Ltw2NBd3baRl/TQBEiFHd6SSGByqX6gMguK/tQV92U
uM/Q4Ak4H/Q+nEN8/LdXioW0P7ZEC6X/9GXKWv+bUs6LjcZXftA=
=TG5W
-----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-19:03.sqlite Errata Notice
The FreeBSD Project
Topic: sqlite update
Category: contrib
Module: sqlite3
Announced: 2019-01-09
Credits: Cy Schubert
Affects: All supported versions of FreeBSD.
Corrected: 2018-12-21 01:58:01 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:47:10 UTC (releng/12.0, 12.0-RELEASE-p2)
2018-12-21 02:04:15 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:50:27 UTC (releng/11.2, 11.2-RELEASE-p8)
CVE Name: CVE-2018-20346, CVE-2018-20505, CVE-2018-20506
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
SQLite is an SQL database engine in a C library. Programs that link the
SQLite library can have SQL database access without running a separate RDBMS
process. The distribution comes with a standalone command-line access
program (sqlite3) that can be used to administer an SQLite database and which
serves as an example of how to use the SQLite library.
II. Problem Description
According to https://blade.tencent.com/magellan/index_en.html, the
vulnerabilities known as Magellan are a group vulnerabilities that exist
in sqlite3, documented by CVE-2018-20346, CVE-2018-20505, and CVE-2018-20506.
When the FTS3 extension is enabled an integer overflow resulting in a buffer
overflow when allowing remote attackers to run arbitrary SQL statements which
can be leveraged to execute arbitrary code.
III. Impact
The vulnerabilities were discovered by Tencent Blade Team and verified to be
able to successfully implement remote code execution in Chromium browsers.
IV. Workaround
No workaround is available.
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.
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
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.2]
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-11.patch
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-11.patch.asc
# gpg --verify sqlite-11.patch.asc
[FreeBSD 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-12.patch
# fetch https://security.FreeBSD.org/patches/EN-19:03/sqlite-12.patch.asc
# gpg --verify sqlite-12.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
Restart all daemons that use the library, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r342291
releng/12.0/ r342895
stable/11/ r342292
releng/11.2/ r342896
- -------------------------------------------------------------------------
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://blade.tencent.com/magellan/index_en.html>
<URL:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234113>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:03.sqlite.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdFfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cLtJg/9EM0jQbTBrSgVy5X1AyQ2rcFz9KbjtA0L48wOuOLiAh7eeYxh4Wxuz9k1
QnEJavMbpVr71yhmt6maEAbRzyGUvemDh4vlu0wjcYSlEzcvk7xaRzfXimippxky
GumFBCvs7UKDIiGRr62ukmxu3FgfEaTM/Cc4bNcuV5k4za+DWIGTu+97i0+B2ieX
/IZ5hQq42w1YIUY5QOy2vj87rnQf2t+uShcBjRg8HsnPsG9BfQfI8vfuWjjtaKMI
iva++F5UJWcsykjZo5J3aaZFxnHsW2hs3buQN+AhoEt7oKdGquOHdweSw8xtSlp9
3Y+qj+veD7u4Mt95OtnYrJOg8Kynlrzg5uMDbNGbyqktbxfpi2gqBbPEVmx2+nGj
Aj9PDSHMliBZsVKvr1opExfYp4HL0LB9Kqhato08lFxs05TUxiT6LRcel/iXiIfl
vCqfWhKJYVZ+alAW+Kjic6iWw7AtmVLbV64dDu03jxS/14RtRp1Hbk1BRCrnJeLn
sLSdFj6bi2mQx6OXAd9G9jhReoxylyZwRXyhPSsPG1E4mzX6ZRbJfnkriSazW4hq
F+PjTyXidn3uhS6z6CZB08Ltw2NBd3baRl/TQBEiFHd6SSGByqX6gMguK/tQV92U
uM/Q4Ak4H/Q+nEN8/LdXioW0P7ZEC6X/9GXKWv+bUs6LjcZXftA=
=TG5W
-----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 Errata Notice FreeBSD-EN-19:04.tzdata
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:04.tzdata Errata Notice
The FreeBSD Project
Topic: Timezone database information update
Category: contrib
Module: zoneinfo
Announced: 2019-01-09
Credits: Philip Paeps
Affects: All supported versions of FreeBSD.
Corrected: 2019-01-01 10:04:49 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:53:35 UTC (releng/12.0, 12.0-RELEASE-p2)
2019-01-01 10:05:12 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:54:42 UTC (releng/11.2, 11.2-RELEASE-p8)
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
The tzsetup(8) program allows the user to specify the default local timezone.
Based on the selected timezone, tzsetup(8) copies one of the files from
/usr/share/zoneinfo to /etc/localtime. This file actually controls the
conversion.
II. Problem Description
Several changes in Daylight Savings Time happened after previous FreeBSD
releases were released that would affect many people who live in different
countries. Because of these changes, the data in the zoneinfo files need to
be updated, and if the local timezone on the running system is affected,
tzsetup(8) needs to be run so the /etc/localtime is updated.
III. Impact
An incorrect time will be displayed on a system configured to use one of the
affected timezones if the /usr/share/zoneinfo and /etc/localtime files are
not updated, and all applications on the system that rely on the system time,
such as cron(8) and syslog(8), will be affected.
IV. Workaround
The system administrator can install an updated timezone database from the
misc/zoneinfo port and run tzsetup(8) to get the timezone database corrected.
Applications that store and display times in Coordinated Universal Time (UTC)
are not affected.
V. Solution
Please note that some third party software, for instance PHP, Ruby, Java and
Perl, may be using different zoneinfo data source, in such cases this
software must be updated separately. For software packages that is installed
via binary packages, they can be upgraded by executing `pkg upgrade'.
Following the instructions in this Errata Notice will update all of the
zoneinfo files to be the same as what was released with FreeBSD release.
Perform one of the following:
1) Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date. Restart all the affected
applications and daemons, or 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
Restart all the affected applications and daemons, or 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.
# fetch https://security.FreeBSD.org/patches/EN-19:04/tzdata-2018i.patch
# fetch https://security.FreeBSD.org/patches/EN-19:04/tzdata-2018i.patch.asc
# gpg --verify tzdata-2018i.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
Restart all the affected applications and daemons, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r342667
releng/12.0/ r342897
stable/11/ r342668
releng/11.2/ r342898
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:04.tzdata.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdRfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cKd+Q//QYBUcMdBnW6URT8bWCrIOTPP84aGpMKmU4ZZYidUfI6CJiiWVaGQHJgD
tmdQjaHemSRfxQ+yAZ5XR8oUIBxrzBhA51cM5QMNnJMXBkpqz9yCbHefH3Fxfr6n
Dg+Vt2cZ745MHPK9uhjtUTmLYRF2iztUqlATr3R1NxBbJ6QQzQuVEyeAvTSY9Jdw
/+cQM72m28iHPP+ff5v9n2MLqoTg74HbchwJthtDvgK9elfQFuC1F07i8I6F4krT
FHnPRISpg4EEOKYG/Jjedk9FQBUpKiOhsDz+siGtjQoivz8TemaH5nTMI7P/WP/7
jFJ6+jQirc2vCvcUzmiPGrBXRx3OptYcIiLOeKfgc+wCtgEHap4Nrl4Damt1QC13
T4kpaOi3TcqtDtKxZyxwR8tOtJGEayqXFHA5FL1Fgr63JcvbZTXlBg0BT4oAd7mX
DuvDkap5hXh6jlQ2BM4L9J+I+GNMfrpULsM4drsqd7GVBcLrnu06po3M8jgja44T
rVzNB62FuOX19Q2W8kZ7LOfAwW+ho02GNzwuYWiLCpP4JSTaxtHrd1LexpCzO4Lg
zsttA2bkNjmzHxfcbAPbS5IMX539iJdTgZiDlBNzUi+QqiCG83/fRcVvgD7qH1iM
kF7DipZUURjlV/RbtCZFU/fsKVzR7rF5MSQl9q7llwe5uMto6lQ=
=1NIG
-----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-19:04.tzdata Errata Notice
The FreeBSD Project
Topic: Timezone database information update
Category: contrib
Module: zoneinfo
Announced: 2019-01-09
Credits: Philip Paeps
Affects: All supported versions of FreeBSD.
Corrected: 2019-01-01 10:04:49 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:53:35 UTC (releng/12.0, 12.0-RELEASE-p2)
2019-01-01 10:05:12 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:54:42 UTC (releng/11.2, 11.2-RELEASE-p8)
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
The tzsetup(8) program allows the user to specify the default local timezone.
Based on the selected timezone, tzsetup(8) copies one of the files from
/usr/share/zoneinfo to /etc/localtime. This file actually controls the
conversion.
II. Problem Description
Several changes in Daylight Savings Time happened after previous FreeBSD
releases were released that would affect many people who live in different
countries. Because of these changes, the data in the zoneinfo files need to
be updated, and if the local timezone on the running system is affected,
tzsetup(8) needs to be run so the /etc/localtime is updated.
III. Impact
An incorrect time will be displayed on a system configured to use one of the
affected timezones if the /usr/share/zoneinfo and /etc/localtime files are
not updated, and all applications on the system that rely on the system time,
such as cron(8) and syslog(8), will be affected.
IV. Workaround
The system administrator can install an updated timezone database from the
misc/zoneinfo port and run tzsetup(8) to get the timezone database corrected.
Applications that store and display times in Coordinated Universal Time (UTC)
are not affected.
V. Solution
Please note that some third party software, for instance PHP, Ruby, Java and
Perl, may be using different zoneinfo data source, in such cases this
software must be updated separately. For software packages that is installed
via binary packages, they can be upgraded by executing `pkg upgrade'.
Following the instructions in this Errata Notice will update all of the
zoneinfo files to be the same as what was released with FreeBSD release.
Perform one of the following:
1) Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date. Restart all the affected
applications and daemons, or 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
Restart all the affected applications and daemons, or 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.
# fetch https://security.FreeBSD.org/patches/EN-19:04/tzdata-2018i.patch
# fetch https://security.FreeBSD.org/patches/EN-19:04/tzdata-2018i.patch.asc
# gpg --verify tzdata-2018i.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
Restart all the affected applications and daemons, or reboot the system.
VI. Correction details
The following list contains the correction revision numbers for each
affected branch.
Branch/path Revision
- -------------------------------------------------------------------------
stable/12/ r342667
releng/12.0/ r342897
stable/11/ r342668
releng/11.2/ r342898
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:04.tzdata.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdRfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cKd+Q//QYBUcMdBnW6URT8bWCrIOTPP84aGpMKmU4ZZYidUfI6CJiiWVaGQHJgD
tmdQjaHemSRfxQ+yAZ5XR8oUIBxrzBhA51cM5QMNnJMXBkpqz9yCbHefH3Fxfr6n
Dg+Vt2cZ745MHPK9uhjtUTmLYRF2iztUqlATr3R1NxBbJ6QQzQuVEyeAvTSY9Jdw
/+cQM72m28iHPP+ff5v9n2MLqoTg74HbchwJthtDvgK9elfQFuC1F07i8I6F4krT
FHnPRISpg4EEOKYG/Jjedk9FQBUpKiOhsDz+siGtjQoivz8TemaH5nTMI7P/WP/7
jFJ6+jQirc2vCvcUzmiPGrBXRx3OptYcIiLOeKfgc+wCtgEHap4Nrl4Damt1QC13
T4kpaOi3TcqtDtKxZyxwR8tOtJGEayqXFHA5FL1Fgr63JcvbZTXlBg0BT4oAd7mX
DuvDkap5hXh6jlQ2BM4L9J+I+GNMfrpULsM4drsqd7GVBcLrnu06po3M8jgja44T
rVzNB62FuOX19Q2W8kZ7LOfAwW+ho02GNzwuYWiLCpP4JSTaxtHrd1LexpCzO4Lg
zsttA2bkNjmzHxfcbAPbS5IMX539iJdTgZiDlBNzUi+QqiCG83/fRcVvgD7qH1iM
kF7DipZUURjlV/RbtCZFU/fsKVzR7rF5MSQl9q7llwe5uMto6lQ=
=1NIG
-----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 Errata Notice FreeBSD-EN-19:02.tcp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:02.tcp Errata Notice
The FreeBSD Project
Topic: TCP connections may stall and eventually fail in case of
packet loss
Category: core
Module: kernel
Announced: 2019-01-09
Credits: Michael Tuexen
Affects: FreeBSD 12.0
Corrected: 2018-12-23 09:48:36 UTC (stable/12, 12.0-STABLE)
2019-09-09 18:42:40 UTC (releng/12.0, 12.0-RELEASE-p2)
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
The TCP stack limits the resources used for TCP connections. Once a limit
is reached, further received TCP segments for the TCP connection are dropped.
II. Problem Description
To continue delivering data to the application, accepting the TCP segment
with the next expected sequence number is required. If this TCP segment is
dropped due to a resource limit, no further progress can be made. Therefore
exceptions for this particular TCP segment have to be implemented.
III. Impact
In case of lost TCP segments, TCP connections may stall and then eventually
fail.
IV. Workaround
No workaround is available.
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 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:02/tcp.patch
# fetch https://security.FreeBSD.org/patches/EN-19:02/tcp.patch.asc
# gpg --verify tcp.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/12/ r342378
releng/12.0/ r342894
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:02.tcp.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2Rc1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJtnxAAgOIJjP9Dg76onxJUPJWiKTAR5VZeZ8od0RJREIeZMUpgFiVUVH82fr8z
ajAzGZbVFhEgFvYwQRU4R/MokNqONoG1O3YPdjcMFyW5HPBoAG+9h67qD3CtLgTN
xnXMR72ed83oY8ts1WSfYVAKF+9X6U5G6FtchBgAhap2k9tI22QKiEmTTmqzUnoy
ddLZatOyKmig8MZKshMmleEpvU+BoYR66d2K9CYxcjHqgNNJOQwQK6yLR3oX41Z9
n5Akkg/KC7wD02CPFjmO9008ZC4fFiQ8D4eGt9D/lPI4AzLcfkvRdzt5CjMlamXm
Rjf2H5/2f4iYSXiEi2wkChFJHh+MQuYgcfTqRJdNB0qf3DbLwTL5wULfrMVNn7LU
rLHd8CNRTN4+d+//p7nZ/atFbuLjJE08YFqE2ODcMa8eJFaY09/+X+NMIqO6AdTE
hGzqDuiVmI/1MSFjD7dxUotw6Y2iRf+DiLx+JUmb0L+C0FXfl/u8x1ErYbzuLyyL
vD1qb66fDuuSC8aNWO6Qv55bBWAhYhO668CQwfmvEgree72ShbzJPEn3vUN2dIX4
zg0kTs30QOlizAT2lxQchiPBKkQ+IExPurTT7lW0cZ5PID8y/FSKl49yeQo/nhrD
j/vnF7yMgc6roCyasNlREdi20yTYbp2PItfhaSXWVrtYAFN1jNc=
=3a3w
-----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-19:02.tcp Errata Notice
The FreeBSD Project
Topic: TCP connections may stall and eventually fail in case of
packet loss
Category: core
Module: kernel
Announced: 2019-01-09
Credits: Michael Tuexen
Affects: FreeBSD 12.0
Corrected: 2018-12-23 09:48:36 UTC (stable/12, 12.0-STABLE)
2019-09-09 18:42:40 UTC (releng/12.0, 12.0-RELEASE-p2)
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
The TCP stack limits the resources used for TCP connections. Once a limit
is reached, further received TCP segments for the TCP connection are dropped.
II. Problem Description
To continue delivering data to the application, accepting the TCP segment
with the next expected sequence number is required. If this TCP segment is
dropped due to a resource limit, no further progress can be made. Therefore
exceptions for this particular TCP segment have to be implemented.
III. Impact
In case of lost TCP segments, TCP connections may stall and then eventually
fail.
IV. Workaround
No workaround is available.
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 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:02/tcp.patch
# fetch https://security.FreeBSD.org/patches/EN-19:02/tcp.patch.asc
# gpg --verify tcp.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/12/ r342378
releng/12.0/ r342894
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:02.tcp.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2Rc1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJtnxAAgOIJjP9Dg76onxJUPJWiKTAR5VZeZ8od0RJREIeZMUpgFiVUVH82fr8z
ajAzGZbVFhEgFvYwQRU4R/MokNqONoG1O3YPdjcMFyW5HPBoAG+9h67qD3CtLgTN
xnXMR72ed83oY8ts1WSfYVAKF+9X6U5G6FtchBgAhap2k9tI22QKiEmTTmqzUnoy
ddLZatOyKmig8MZKshMmleEpvU+BoYR66d2K9CYxcjHqgNNJOQwQK6yLR3oX41Z9
n5Akkg/KC7wD02CPFjmO9008ZC4fFiQ8D4eGt9D/lPI4AzLcfkvRdzt5CjMlamXm
Rjf2H5/2f4iYSXiEi2wkChFJHh+MQuYgcfTqRJdNB0qf3DbLwTL5wULfrMVNn7LU
rLHd8CNRTN4+d+//p7nZ/atFbuLjJE08YFqE2ODcMa8eJFaY09/+X+NMIqO6AdTE
hGzqDuiVmI/1MSFjD7dxUotw6Y2iRf+DiLx+JUmb0L+C0FXfl/u8x1ErYbzuLyyL
vD1qb66fDuuSC8aNWO6Qv55bBWAhYhO668CQwfmvEgree72ShbzJPEn3vUN2dIX4
zg0kTs30QOlizAT2lxQchiPBKkQ+IExPurTT7lW0cZ5PID8y/FSKl49yeQo/nhrD
j/vnF7yMgc6roCyasNlREdi20yTYbp2PItfhaSXWVrtYAFN1jNc=
=3a3w
-----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 Errata Notice FreeBSD-EN-19:01.cc_cubic
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:01.cc_cubic Errata Notice
The FreeBSD Project
Topic: Connection stalls with CUBIC congestion control
Category: core
Module: tcp
Announced: 2019-01-09
Credits: Matt Garber, Hiren Panchasara
Affects: FreeBSD 12.0
Corrected: 2018-12-17 21:46:42 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:38:35 UTC (releng/12.0, 12.0-RELEASE-p2)
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
CUBIC is a modern congestion control algorithm for the Transmission Control
Protocol (TCP), which along with its predecessor BIC TCP is specifically
optimized for high bandwidth, high latency networks. It is widely
implemented across a variety of operating systems, and is the default TCP
implementation or enabled by default in recent versions of Linux and
Microsoft Windows. CUBIC is available as an alternate congestion control
algorithm since FreeBSD 9.0 using the cc_cubic module.
II. Problem Description
Changes to the cc_cubic module in FreeBSD 12.0 can cause network stuttering
or connection stalls when loaded and enabled as default.
III. Impact
FreeBSD 12.0 systems loading cc_cubic and setting non-default sysctl value
net.inet.tcp.cc.algorithm=cubic exhibit stuttering and complete stalls of
network connections. Under certain conditions, this may cause loss of system
availability over the network or service unreachability.
IV. Workaround
Disabling cc_cubic and selecting one of the alternate included congestion
control algorithms (e.g., newreno, htcp) will restore normal network
connectivity and alleviate stuttering and stalls. Note that disabling CUBIC
may cause a reduction in expected performance based on specific, unique
network condition characteristics and the module used as a workaround.
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, and 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
# shutdown -r +30 "Rebooting for FreeBSD errata update"
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 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:01/cc_cubic.patch
# fetch https://security.FreeBSD.org/patches/EN-19:01/cc_cubic.patch.asc
# gpg --verify cc_cubic.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/12/ r342181
releng/12.0/ r342893
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:01.cc_cubic.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2Rb5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJGyRAAnpturBqU4XIZMdvInaVHOXA5P6KemeFuJkwz/aMtIbgefm49lvZVS4q6
RO8/GytONX1OHaoJQDdincVfRbe9x+ID+ulCJfSLuZMhjLYpxDQJo9d4NWZtvpBn
3wJNEQEXB0AjrYUOrebiT7yd3zA4f+7zSHu0Uvq4k5Tk0Xxsqxsx3/MG5ezEmdxx
IWub1RnYvgmUVJBKn/C5A4v17dE12VnZtLrnfhZ4K3U3mVZYc3cJxF34wSscVqYd
iAsntF786FV+hAXBX7wHa3JIqe+uXE2uemrquNmxgup+zrbVWPWPirgku2TVcvsm
m9aQILNc9RvJ/XkViLV8+ypqCymBFsl3VhO3dzmOnsbL72G9rqjQtgdYWT2dp69p
VyU4EWsTULXIbIBNxyrYhinT+DAqyt8bdrtyT3AhcVJaVk5B5APWnXiwjgS4mPN9
hf2mCjZw10tJgsqYYrBlTERomgHU/pyliu0Rt2sof5+iGArbe7ZhEorHrM7YhD9n
Hc+3oNzA0dYDStJQpEb4rJ7dEKP/mpppwIosMhPbku6u3ViafCJVq2dIGNQpDope
Mh00Kk7cY0o3Rukw2lGNc9vDbIyUSqT/jV4lBDhp4k5ilQynvkMZETLlynI+KQUH
J2uOOvYzkIZLzZyXtaQfkmrkV6DxzmjxDsqwiMz5DB7o70w/M54=
=e8Wg
-----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-19:01.cc_cubic Errata Notice
The FreeBSD Project
Topic: Connection stalls with CUBIC congestion control
Category: core
Module: tcp
Announced: 2019-01-09
Credits: Matt Garber, Hiren Panchasara
Affects: FreeBSD 12.0
Corrected: 2018-12-17 21:46:42 UTC (stable/12, 12.0-STABLE)
2019-01-09 18:38:35 UTC (releng/12.0, 12.0-RELEASE-p2)
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
CUBIC is a modern congestion control algorithm for the Transmission Control
Protocol (TCP), which along with its predecessor BIC TCP is specifically
optimized for high bandwidth, high latency networks. It is widely
implemented across a variety of operating systems, and is the default TCP
implementation or enabled by default in recent versions of Linux and
Microsoft Windows. CUBIC is available as an alternate congestion control
algorithm since FreeBSD 9.0 using the cc_cubic module.
II. Problem Description
Changes to the cc_cubic module in FreeBSD 12.0 can cause network stuttering
or connection stalls when loaded and enabled as default.
III. Impact
FreeBSD 12.0 systems loading cc_cubic and setting non-default sysctl value
net.inet.tcp.cc.algorithm=cubic exhibit stuttering and complete stalls of
network connections. Under certain conditions, this may cause loss of system
availability over the network or service unreachability.
IV. Workaround
Disabling cc_cubic and selecting one of the alternate included congestion
control algorithms (e.g., newreno, htcp) will restore normal network
connectivity and alleviate stuttering and stalls. Note that disabling CUBIC
may cause a reduction in expected performance based on specific, unique
network condition characteristics and the module used as a workaround.
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, and 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
# shutdown -r +30 "Rebooting for FreeBSD errata update"
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 12.0]
# fetch https://security.FreeBSD.org/patches/EN-19:01/cc_cubic.patch
# fetch https://security.FreeBSD.org/patches/EN-19:01/cc_cubic.patch.asc
# gpg --verify cc_cubic.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/12/ r342181
releng/12.0/ r342893
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:01.cc_cubic.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2Rb5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cJGyRAAnpturBqU4XIZMdvInaVHOXA5P6KemeFuJkwz/aMtIbgefm49lvZVS4q6
RO8/GytONX1OHaoJQDdincVfRbe9x+ID+ulCJfSLuZMhjLYpxDQJo9d4NWZtvpBn
3wJNEQEXB0AjrYUOrebiT7yd3zA4f+7zSHu0Uvq4k5Tk0Xxsqxsx3/MG5ezEmdxx
IWub1RnYvgmUVJBKn/C5A4v17dE12VnZtLrnfhZ4K3U3mVZYc3cJxF34wSscVqYd
iAsntF786FV+hAXBX7wHa3JIqe+uXE2uemrquNmxgup+zrbVWPWPirgku2TVcvsm
m9aQILNc9RvJ/XkViLV8+ypqCymBFsl3VhO3dzmOnsbL72G9rqjQtgdYWT2dp69p
VyU4EWsTULXIbIBNxyrYhinT+DAqyt8bdrtyT3AhcVJaVk5B5APWnXiwjgS4mPN9
hf2mCjZw10tJgsqYYrBlTERomgHU/pyliu0Rt2sof5+iGArbe7ZhEorHrM7YhD9n
Hc+3oNzA0dYDStJQpEb4rJ7dEKP/mpppwIosMhPbku6u3ViafCJVq2dIGNQpDope
Mh00Kk7cY0o3Rukw2lGNc9vDbIyUSqT/jV4lBDhp4k5ilQynvkMZETLlynI+KQUH
J2uOOvYzkIZLzZyXtaQfkmrkV6DxzmjxDsqwiMz5DB7o70w/M54=
=e8Wg
-----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 Errata Notice FreeBSD-EN-19:05.kqueue
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-EN-19:05.kqueue Errata Notice
The FreeBSD Project
Topic: kqueue race condition and kernel panic
Category: core
Module: kqueue
Announced: 2019-01-09
Credits: Mark Johnston
Affects: FreeBSD 11.2
Corrected: 2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:57:38 UTC (releng/11.2, 11.2-RELEASE-p8)
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
kevent(2) is a system call which provides a generic method of notifying the
caller when a caller-specified event happens or a condition holds. One use
for kevent(2) is to wait for a specified timeout to elapse.
II. Problem Description
The kevent(2) implementation in the kernel contains a race condition which
can be triggered when an event is added and fires shortly after. Most event
types are not affected, but timer events can trigger the race if the timeout
duration is very short.
III. Impact
The race condition can cause corruption of a queue structure, leading to
a kernel panic when it is later accessed. Applications using kevent(2) may
trigger the panic if their usage causes the race condition to occur.
IV. Workaround
No workaround is available.
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, and reboot.
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
# shutdown -r +30 "Rebooting for errata update"
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.2]
# fetch https://security.FreeBSD.org/patches/EN-19:05/kqueue.patch
# fetch https://security.FreeBSD.org/patches/EN-19:05/kqueue.patch.asc
# gpg --verify kqueue.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/ r340904
releng/11.2/ r342899
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:05.kqueue.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cK0nRAAgPsdkc/TyBTqpvJrvvNaVd0xgNC2lxnYK3HxOPbo5kqj6XHZxb3KvrrN
He6TyGvwGCPHNzlFwHILH+FtFkgrvGVBoPu/U0e/NKRrkhyxPHJMz0bZPu7yqQoG
GDFRIsw5D3JKZW38yMD9Menh3mag81OVZii1LfzkcDLLKfwX/zcx1vV7MSwMzoNs
5L7Fm8lg0uIxrrlKvvmrPxfWoZENhCr9CAAdg8moL3thl64NaVVmPo7tXDXosNGo
EQYT19SY0FBSboUcpVaChgyZaCFzOeCPuXuJPoUYppIWNiv2S8ZTjuq9d1g4R4SD
7GBMozz8EG1rN0pzhx8mVEECZBzdt5rjggiWKjkOVxH/sy5LQjppONK3VVOygoCz
dve2wGq6S1ke/b2NDRpAinmIr8I3x3b7JLNkE5OvNJ6bTLk3ZmpIRYQNYT+eu8Fx
GNe/oTU9DRbB4yv0kcKsypHqQ0cKdn6+duYzKGZ4+c86B7IHJgsYoG/NTKYfFzQx
BHWuI/P/9pakHESNiDidKRz+z5w679+jIfZDcbBIXaw+PCqzg5a1GFN8Bub2mGLw
2wmVQJV1nbdE+6UbWvaV2seV/bo+N/L8k4QS6OPIDUefLPGgCdRFr/MlLoiTaJ43
p+L3iVlVbiOTCfsCGI/QVQq+IOngKzqSUXN3Ys7PXvvAzSyaTFg=
=fD2U
-----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-19:05.kqueue Errata Notice
The FreeBSD Project
Topic: kqueue race condition and kernel panic
Category: core
Module: kqueue
Announced: 2019-01-09
Credits: Mark Johnston
Affects: FreeBSD 11.2
Corrected: 2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE)
2019-01-09 18:57:38 UTC (releng/11.2, 11.2-RELEASE-p8)
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
kevent(2) is a system call which provides a generic method of notifying the
caller when a caller-specified event happens or a condition holds. One use
for kevent(2) is to wait for a specified timeout to elapse.
II. Problem Description
The kevent(2) implementation in the kernel contains a race condition which
can be triggered when an event is added and fires shortly after. Most event
types are not affected, but timer events can trigger the race if the timeout
duration is very short.
III. Impact
The race condition can cause corruption of a queue structure, leading to
a kernel panic when it is later accessed. Applications using kevent(2) may
trigger the panic if their usage causes the race condition to occur.
IV. Workaround
No workaround is available.
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, and reboot.
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
# shutdown -r +30 "Rebooting for errata update"
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.2]
# fetch https://security.FreeBSD.org/patches/EN-19:05/kqueue.patch
# fetch https://security.FreeBSD.org/patches/EN-19:05/kqueue.patch.asc
# gpg --verify kqueue.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/ r340904
releng/11.2/ r342899
- -------------------------------------------------------------------------
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 advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-19:05.kqueue.asc>
-----BEGIN PGP SIGNATURE-----
iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAlw2RdZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD
MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n
5cK0nRAAgPsdkc/TyBTqpvJrvvNaVd0xgNC2lxnYK3HxOPbo5kqj6XHZxb3KvrrN
He6TyGvwGCPHNzlFwHILH+FtFkgrvGVBoPu/U0e/NKRrkhyxPHJMz0bZPu7yqQoG
GDFRIsw5D3JKZW38yMD9Menh3mag81OVZii1LfzkcDLLKfwX/zcx1vV7MSwMzoNs
5L7Fm8lg0uIxrrlKvvmrPxfWoZENhCr9CAAdg8moL3thl64NaVVmPo7tXDXosNGo
EQYT19SY0FBSboUcpVaChgyZaCFzOeCPuXuJPoUYppIWNiv2S8ZTjuq9d1g4R4SD
7GBMozz8EG1rN0pzhx8mVEECZBzdt5rjggiWKjkOVxH/sy5LQjppONK3VVOygoCz
dve2wGq6S1ke/b2NDRpAinmIr8I3x3b7JLNkE5OvNJ6bTLk3ZmpIRYQNYT+eu8Fx
GNe/oTU9DRbB4yv0kcKsypHqQ0cKdn6+duYzKGZ4+c86B7IHJgsYoG/NTKYfFzQx
BHWuI/P/9pakHESNiDidKRz+z5w679+jIfZDcbBIXaw+PCqzg5a1GFN8Bub2mGLw
2wmVQJV1nbdE+6UbWvaV2seV/bo+N/L8k4QS6OPIDUefLPGgCdRFr/MlLoiTaJ43
p+L3iVlVbiOTCfsCGI/QVQq+IOngKzqSUXN3Ys7PXvvAzSyaTFg=
=fD2U
-----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"
[USN-3850-1] NSS vulnerabilities
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEUMSg3c8x5FLOsZtRZWnYVadEvpMFAlw2R5IACgkQZWnYVadE
vpNUMw/+N4hFDAwNWEqYbpt8GzQg/BFpFhXDfq/a1lUUZuCbiFzhXshoGdVyoKjR
ZDmvGkLPg1G7+iAT1U3mh0TG/hmz0lEvSmxbMKWrqjwNVAAB560Xo1bjodgDbub1
P0ndVkz4KmqNbXntbg4ZOET7H/EsKLkethWIOEGxhvMYTDfykaaYiSugmlNB6gb3
jrQEv/X/J2KJxuBMu6bkL9RCea4Q/EzxTupZabNKkx7sG9n3HNIPiufuEQk0DuTS
5FfqGaa1b9lOkALG2A6UeC/hMsmLdH4OTTeDC7KD17Z65NdBDubmrTzkVzjJn3/N
AC85YBORKfOUGxLoiJVi/xh7FRTV3aqOYy2sv+PdRnUq+r1tbLp3Svn9Wq4GhHFR
BIfSYyS7oEo+Iw9rBwCi5CEsxqnlfeSvd1UWaVL7Id+K8ZnjdKSOpTw2r0HMHZWi
lvwnLEEwVu2Co2OsvfSQo1AK7XJqIZR5dbCDw5vXUDwrzTo+h09QtmRG9qcePX5m
IqJV6eXDeMsMY6++F5Gq4CIY0Pnr+jCsrAP/JNqmyikRP6voCp8z/YAbioD49LUS
9fW9TpQwu6LUjupSY3eXV1lpyGxwj5CLo6H/56YNXq7cDhnZvfYDOX/7BSWtjMAu
yE4OoVR2ku/ij3VonSKieX623LwBaRIjWXZMOslOGhGDhSOdEmw=
=kiYz
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-3850-1
January 09, 2019
nss vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.10
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
Several security issues were fixed in NSS.
Software Description:
- nss: Network Security Service library
Details:
Keegan Ryan discovered that NSS incorrectly handled ECDSA key generation.
A local attacker could possibly use this issue to perform a cache-timing
attack and recover private ECDSA keys. (CVE-2018-0495)
It was discovered that NSS incorrectly handled certain v2-compatible
ClientHello messages. A remote attacker could possibly use this issue to
perform a replay attack. (CVE-2018-12384)
It was discovered that NSS incorrectly handled certain padding oracles. A
remote attacker could possibly use this issue to perform a variant of the
Bleichenbacher attack. (CVE-2018-12404)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.10:
libnss3 2:3.36.1-1ubuntu1.1
Ubuntu 18.04 LTS:
libnss3 2:3.35-2ubuntu2.1
Ubuntu 16.04 LTS:
libnss3 2:3.28.4-0ubuntu0.16.04.4
Ubuntu 14.04 LTS:
libnss3 2:3.28.4-0ubuntu0.14.04.4
After a standard system update you need to restart any applications that
use NSS, such as Evolution, to make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3850-1
CVE-2018-0495, CVE-2018-12384, CVE-2018-12404
Package Information:
https://launchpad.net/ubuntu/+source/nss/2:3.36.1-1ubuntu1.1
https://launchpad.net/ubuntu/+source/nss/2:3.35-2ubuntu2.1
https://launchpad.net/ubuntu/+source/nss/2:3.28.4-0ubuntu0.16.04.4
https://launchpad.net/ubuntu/+source/nss/2:3.28.4-0ubuntu0.14.04.4
iQIzBAEBCgAdFiEEUMSg3c8x5FLOsZtRZWnYVadEvpMFAlw2R5IACgkQZWnYVadE
vpNUMw/+N4hFDAwNWEqYbpt8GzQg/BFpFhXDfq/a1lUUZuCbiFzhXshoGdVyoKjR
ZDmvGkLPg1G7+iAT1U3mh0TG/hmz0lEvSmxbMKWrqjwNVAAB560Xo1bjodgDbub1
P0ndVkz4KmqNbXntbg4ZOET7H/EsKLkethWIOEGxhvMYTDfykaaYiSugmlNB6gb3
jrQEv/X/J2KJxuBMu6bkL9RCea4Q/EzxTupZabNKkx7sG9n3HNIPiufuEQk0DuTS
5FfqGaa1b9lOkALG2A6UeC/hMsmLdH4OTTeDC7KD17Z65NdBDubmrTzkVzjJn3/N
AC85YBORKfOUGxLoiJVi/xh7FRTV3aqOYy2sv+PdRnUq+r1tbLp3Svn9Wq4GhHFR
BIfSYyS7oEo+Iw9rBwCi5CEsxqnlfeSvd1UWaVL7Id+K8ZnjdKSOpTw2r0HMHZWi
lvwnLEEwVu2Co2OsvfSQo1AK7XJqIZR5dbCDw5vXUDwrzTo+h09QtmRG9qcePX5m
IqJV6eXDeMsMY6++F5Gq4CIY0Pnr+jCsrAP/JNqmyikRP6voCp8z/YAbioD49LUS
9fW9TpQwu6LUjupSY3eXV1lpyGxwj5CLo6H/56YNXq7cDhnZvfYDOX/7BSWtjMAu
yE4OoVR2ku/ij3VonSKieX623LwBaRIjWXZMOslOGhGDhSOdEmw=
=kiYz
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-3850-1
January 09, 2019
nss vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.10
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
Several security issues were fixed in NSS.
Software Description:
- nss: Network Security Service library
Details:
Keegan Ryan discovered that NSS incorrectly handled ECDSA key generation.
A local attacker could possibly use this issue to perform a cache-timing
attack and recover private ECDSA keys. (CVE-2018-0495)
It was discovered that NSS incorrectly handled certain v2-compatible
ClientHello messages. A remote attacker could possibly use this issue to
perform a replay attack. (CVE-2018-12384)
It was discovered that NSS incorrectly handled certain padding oracles. A
remote attacker could possibly use this issue to perform a variant of the
Bleichenbacher attack. (CVE-2018-12404)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.10:
libnss3 2:3.36.1-1ubuntu1.1
Ubuntu 18.04 LTS:
libnss3 2:3.35-2ubuntu2.1
Ubuntu 16.04 LTS:
libnss3 2:3.28.4-0ubuntu0.16.04.4
Ubuntu 14.04 LTS:
libnss3 2:3.28.4-0ubuntu0.14.04.4
After a standard system update you need to restart any applications that
use NSS, such as Evolution, to make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3850-1
CVE-2018-0495, CVE-2018-12384, CVE-2018-12404
Package Information:
https://launchpad.net/ubuntu/+source/nss/2:3.36.1-1ubuntu1.1
https://launchpad.net/ubuntu/+source/nss/2:3.35-2ubuntu2.1
https://launchpad.net/ubuntu/+source/nss/2:3.28.4-0ubuntu0.16.04.4
https://launchpad.net/ubuntu/+source/nss/2:3.28.4-0ubuntu0.14.04.4
[USN-3851-1] Django vulnerability
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEUMSg3c8x5FLOsZtRZWnYVadEvpMFAlw2R6YACgkQZWnYVadE
vpNp0w//RdO/FxHs+HMr7kctISPTsWTt/mY0YbEFXNtfdjrPoOfwLkQvOZ7/y3tZ
BzhU5zCeX+E5MjdxvexCSR7SLlTtG6SIcWa3orKlSiwCz1vUv/ASLc76nGwxHWas
B1xslQiZ3WeIthpv070pB+HKuyaJNOK/Q3q+cucLHJNWITKnKrAVKTUVdewL6p6M
cAxBfwJcsgaLMZKTfkKBoSALEfyxjtoecg34hJQal6OIRtrI8lhfa2W0RYEJMdG5
4pkCEvJ0zpIs9zTUlbSCGGEGfsy4KbtmNprp5sggI9dMRkOSSorsJ8wrh+HifUhS
ZY/9RCvQrrVUvV7tSI6Q/qLfTEjJJmQdWnqS3MuckL518RufgO5IqUd8cihOpRq5
WM0xHetMy3ggC6mhdwYGBErygi5wRr2AC9Ci870sFUAhJ2yU7O3N5otj16RpqrG2
FoI30K1uRV/k2XgpeCatOG6Wqopf4aN/g2asPGv7RqDzq/DnDLFgsFTZBbsWjkmt
UNAfdWDTLwTvw5vNU1L6PY1RODuEMuZYKW0TdCNAnUoWyzQtcjEXsFZl/qEDACGY
0teR2YYER981gu4s0eXVXClSpj5bQuzjgHmrqz4xARhO9yWxmIvZ7htBvcLUMJB1
QTZHvpe3ve4RCp6yQc7YI8UQQNMc5zblBOcgTngoQWliOkWXYWE=
=PX5v
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-3851-1
January 09, 2019
python-django vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.10
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
Django could be made to expose spoofed information over the network.
Software Description:
- python-django: High-level Python web development framework
Details:
It was discovered that Django incorrectly handled the default 404 page. A
remote attacker could use this issue to spoof content using a malicious
URL.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.10:
python-django 1:1.11.15-1ubuntu1.1
python3-django 1:1.11.15-1ubuntu1.1
Ubuntu 18.04 LTS:
python-django 1:1.11.11-1ubuntu1.2
python3-django 1:1.11.11-1ubuntu1.2
Ubuntu 16.04 LTS:
python-django 1.8.7-1ubuntu5.7
python3-django 1.8.7-1ubuntu5.7
Ubuntu 14.04 LTS:
python-django 1.6.11-0ubuntu1.3
In general, a standard system update will make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3851-1
CVE-2019-3498
Package Information:
https://launchpad.net/ubuntu/+source/python-django/1:1.11.15-1ubuntu1.1
https://launchpad.net/ubuntu/+source/python-django/1:1.11.11-1ubuntu1.2
https://launchpad.net/ubuntu/+source/python-django/1.8.7-1ubuntu5.7
https://launchpad.net/ubuntu/+source/python-django/1.6.11-0ubuntu1.3
iQIzBAEBCgAdFiEEUMSg3c8x5FLOsZtRZWnYVadEvpMFAlw2R6YACgkQZWnYVadE
vpNp0w//RdO/FxHs+HMr7kctISPTsWTt/mY0YbEFXNtfdjrPoOfwLkQvOZ7/y3tZ
BzhU5zCeX+E5MjdxvexCSR7SLlTtG6SIcWa3orKlSiwCz1vUv/ASLc76nGwxHWas
B1xslQiZ3WeIthpv070pB+HKuyaJNOK/Q3q+cucLHJNWITKnKrAVKTUVdewL6p6M
cAxBfwJcsgaLMZKTfkKBoSALEfyxjtoecg34hJQal6OIRtrI8lhfa2W0RYEJMdG5
4pkCEvJ0zpIs9zTUlbSCGGEGfsy4KbtmNprp5sggI9dMRkOSSorsJ8wrh+HifUhS
ZY/9RCvQrrVUvV7tSI6Q/qLfTEjJJmQdWnqS3MuckL518RufgO5IqUd8cihOpRq5
WM0xHetMy3ggC6mhdwYGBErygi5wRr2AC9Ci870sFUAhJ2yU7O3N5otj16RpqrG2
FoI30K1uRV/k2XgpeCatOG6Wqopf4aN/g2asPGv7RqDzq/DnDLFgsFTZBbsWjkmt
UNAfdWDTLwTvw5vNU1L6PY1RODuEMuZYKW0TdCNAnUoWyzQtcjEXsFZl/qEDACGY
0teR2YYER981gu4s0eXVXClSpj5bQuzjgHmrqz4xARhO9yWxmIvZ7htBvcLUMJB1
QTZHvpe3ve4RCp6yQc7YI8UQQNMc5zblBOcgTngoQWliOkWXYWE=
=PX5v
-----END PGP SIGNATURE-----
==========================================================================
Ubuntu Security Notice USN-3851-1
January 09, 2019
python-django vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.10
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 14.04 LTS
Summary:
Django could be made to expose spoofed information over the network.
Software Description:
- python-django: High-level Python web development framework
Details:
It was discovered that Django incorrectly handled the default 404 page. A
remote attacker could use this issue to spoof content using a malicious
URL.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.10:
python-django 1:1.11.15-1ubuntu1.1
python3-django 1:1.11.15-1ubuntu1.1
Ubuntu 18.04 LTS:
python-django 1:1.11.11-1ubuntu1.2
python3-django 1:1.11.11-1ubuntu1.2
Ubuntu 16.04 LTS:
python-django 1.8.7-1ubuntu5.7
python3-django 1.8.7-1ubuntu5.7
Ubuntu 14.04 LTS:
python-django 1.6.11-0ubuntu1.3
In general, a standard system update will make all the necessary changes.
References:
https://usn.ubuntu.com/usn/usn-3851-1
CVE-2019-3498
Package Information:
https://launchpad.net/ubuntu/+source/python-django/1:1.11.15-1ubuntu1.1
https://launchpad.net/ubuntu/+source/python-django/1:1.11.11-1ubuntu1.2
https://launchpad.net/ubuntu/+source/python-django/1.8.7-1ubuntu5.7
https://launchpad.net/ubuntu/+source/python-django/1.6.11-0ubuntu1.3
Tuesday, January 8, 2019
Re: OUTAGE: Koji system 2019-01-11 -> 2019-01-14
This is a reminder that this begins this Friday and will probably be in place for 4 days. If there are increased downtimes, we will update the data when we know it.
On Fri, 7 Dec 2018 at 14:51, Stephen John Smoogen <smooge@gmail.com> wrote:
Planned Outage - Koji Services - 2019-01-11 22:00 UTC
There will be an koji outage starting at 2019-01-11 22:00 UTC, which
will last approximately 4 days.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2019-01-11 22:00UTC'
Reason for outage:
The facility that houses the Fedora s390 server will have a major
power outage starting 2019-01-11 22:00 UTC and ending 2019-01-14 22:00
UTC. During this time the s390 builders will not be available and all
builds will be queued up until they are available and will not
complete.
Affected Services:
koji and related services which make composes and builds
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/7429
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
--
Stephen J Smoogen.
Stephen J Smoogen.
F30 Self-Contained Change proposal: Avoid Fedora-specific build flags in non-RPM Python extensions
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags
== Summary ==
The build flags (<code>CFLAGS</code>, <code>CXXFLAGS</code> and
<code>LDFLAGS</code>) saved in the Python's distutils module for
building extension modules are switched from:
* <code>%{build_cflags}</code>,
* <code>%{build_cxxflags}</code> and
* <code>%{build_ldflags}</code>
to:
* <code>%{extension_cflags}</code>,
* <code>%{extension_cxxflags}</code> and
* <code>%{extension_ldflags}</code>.
This [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
currently means] that no GCC plugins (such as annobin) are activated
and no GCC spec files (<code>-specs=</code> arguments) are used by
default when building Python extension modules (e.g. with
<code>python3 setup.py build</code>).
The {{package|python3-devel}} package will lose its runtime dependency
on {{package|redhat-rpm-config}} (which was only required for annobin
support and GCC spec files).
The change will affect building extension modules by users, outside of
the RPM environment. The Python standard library and Fedora's Python 3
RPM packages are still built with the "traditional" set of flags
(<code>%{build_cflags}</code> and friends), unless the package uses
nonstandard methods to build the extensions.
Only Python 3.7 ({{package|python3}}) and 3.6 ({{package|python36}})
will be changed.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Cstratak|Charalampos
Stratakis]]
* Email: python-maint@redhat.com
=== The Problem ===
When Python is built, it saves the flags (<code>CFLAGS</code>,
<code>CXXFLAGS</code> and <code>LDFLAGS</code>) for further use when
building extension modules into a designated <code>Makefile</code>.
The distutils module (a component responsible for building Python
packages and extension modules) then reads the file and applies the
flags. You can see the file at
<code>/usr/lib64/python3.7/config-3.7m-x86_64-linux-gnu/Makefile</code>
in {{package|python3-libs}}. This is mostly done to make user-built
extension modules binary compatible with the Python interpreter they
are being built for.
Traditionally (=before this change), the {{package|python3}} package
was created in a way that it simply saved the same set of flags used
for building itself.
This proved problematic as the flags used to build Fedora packages
grew specific things (not actually needed for binary compatibility of
the extension modules) and several workarounds needed to be made, most
specifically the {{package|python3-devel}} package got a runtime
dependency on {{package|redhat-rpm-config}}:
* https://bugzilla.redhat.com/show_bug.cgi?id=1217376
* https://bugzilla.redhat.com/show_bug.cgi?id=1496757
* https://bugzilla.redhat.com/show_bug.cgi?id=1218294
The problematic flags are GCC plugins (such as annobin) and GCC spec
files (<code>-specs=</code> arguments).
Example: Any Python developer using Fedora automatically builds Python
extension modules with annobin and hardening flags by default even if
they don't need that. They might build the extension on Fedora, test
it and later ship it and build it on a CI that is not based on Fedora
and get different results.
=== The Solution ===
The solution is not to save the problematic flags, but only the flags
needed. Until recently, this would be hackish, but
[https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
a designated set of flags] was created in Fedora 30, supposed to be
used by extension builders (such as the Python's distutil module):
<code>%{extension_cflags}</code>, <code>%{extension_cxxflags}</code>
and <code>%{extension_ldflags}</code>.
The [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
documentation for the flags] currently reads:
<blockquote>
The current set of differences are:
* No GCC plugins (such as annobin) are activated.
* No GCC spec files (<code>-specs=</code> arguments) are used.
Additional flags may be removed in the future if they prove to be
incompatible with alternative toolchains.
</blockquote>
Python already had (incomplete) support for specifying different sets
of flags for itself and for the extensions. In Python 3.7.2 and 3.6.8
the ability was completed by providing a way to do this for
<code>LDFAGS</code> (this was actually driven by Fedora's needs).
Currently we are able to set a different set of flags for building
Python and for building user extension modules. The code implementing
this change can be inspected at
[https://src.fedoraproject.org/rpms/python3/pull-request/75 Fedora
python3 PR #75] and [https://github.com/python/cpython/pull/10900
CPython PR #10900].
=== Impact on users building extension modules ===
When an user compiles a Python extension module outside of RPMBuild
and does not specify any flags explicitly, this is what they used to
have:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python3.7m -c demo.c
-o build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
After the change, they will get:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv
-fPIC -I/usr/include/python3.7m -c demo.c -o
build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
Users are able to provide their own flags by setting the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
environment variables. They can, for example, opt-in for annobin if
they wish to do so.
=== Impact on RPM packages building extension modules ===
When the spec file of the package sets the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
variables to the expected Fedora values (e.g.
<code>CFLAGS=${RPM_OPT_FLAGS} LDFLAGS=${RPM_LD_FLAGS}</code> or
<code>%{build_cflags}</code>, <code>%{build_cxxflags}</code>,
<code>%{build_ldflags}</code>, <code>%{optflags}</code> etc.)
everything works as expected. The currently documented way of building
Python packages (<code>%py3_build</code> and
<code>%py3_install</code>)
[https://src.fedoraproject.org/rpms/python-rpm-macros/blob/master/f/macros.python3
does this] for you, we recommend using it.
There might be some differences in the log, because the flags
concatenate. Here is the example from the {{package|python-psycopg2 }}
build.log.
Before this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -D_GNU_SOURCE -fPIC -fwrapv '''-O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
After this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection''' -D_GNU_SOURCE -fPIC
-fwrapv '''-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
If the package does <code>python3 setup.py build</code> to build the
extension modules manually without setting the flags, the flags are
not set properly. This is probably very rare. Even before the
<code>%py3_build</code> and <code>%py3_install</code> macros, the
preferred way was to call:
CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build # from EL4
However, <code>LDFLAGS</code> are not set in that example.
There are 485 packages that have the <code>%{python3_sitearch}</code>
macro in them and hence are most likely to build Python extension
modules.
Out of those, 173 have <code>setup.py</code> directly in the spec. 65
have <code>setup.py build</code>. Change owners will go trough the
list and provide fixes. Packages are encouraged to switch to the
<code>%py3_build</code> macro themselves.
Worst case: Some package won't have annobin.
=== Python interpreters affected by this change ===
This change is fully possible (without backporting) in Python 3.6.8 /
3.7.2 or newer. Hence we'll only change the {{package|python3}} and
{{package|python36}} packages.
We'll keep older Pythons intact and let them finish their lifetime as
they are. Newer Python versions will inherit this change.
PyPy 3 ({{package|pypy3}}) might eventually be updated to a version
that supports this fully. Since no packages in Fedora use PyPy 3,
we'll update it then without a change proposal and we'll document the
fact on this Change page. (If any package starts using PyPy 3 untill
then, we'll coordinate with the maintainer/s).
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules.
Python developers won't need {{package|redhat-rpm-macros}} (and dozens
of other language-specific packages that go with that) installed just
to do so.
New decisions made about the distro packages won't necessarily affect
Python developers building their extension modules.
== Scope ==
* Proposal owners:
** Review, merge and build the
[https://src.fedoraproject.org/rpms/python3/pull-request/75 pull
request with the implementation].
** Go through the packages manually invoking <code>setup.py</code> to
build extension modules and provide fixes. Update to
<code>%py3_build</code> where possible, set the flags manually
otherwise.
* Other developers: Are encouraged to switch to
<code>%py3_build</code> (but they don't need to do anything, this is
not a System Wide Change).
* Release engineering: [https://pagure.io/releng/issue/8027 #8027]
(mass rebuild not needed, no releng impact anticipated).
* Policies and guidelines: already in place.
== Upgrade/compatibility impact ==
Not anticipated. Extension modules (built for the same Python version)
are compatible with the interpreter with or without the removed flags
back and forth.
== How To Test ==
=== For users (Python developers) ===
# build your favorite Python extension module in venv or outside venv
with <code>setup.py build</code> or <code>setup.py build_ext</code>
# observe the used flags and check annobin and <code>-specs</code>
'''are not there''', report bugs for {{package|python3}} otherwise
(and block our tracking bug)
# check if the extension works as expected
=== For packagers (Fedora contributors) ===
# build your favorite RPM package with Python extension module
# observe the used flags and check annobin and <code>-specs</code>
'''are there''', report bugs for that package otherwise (and block our
tracking bug)
# check if the package works as expected
== User Experience ==
See '''Benefit to Fedora''' above.
== Dependencies ==
Changes in {{package|redhat-rpm-config}} are already done.
We will check dependent Fedora packages.
== Contingency Plan ==
* Contingency mechanism: Change owners can revert the change at any
point. If removing the {{package|redhat-rpm-config}} dependency turns
out to be problematic, it can be added back until the problem is
fixed.
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
This page is the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
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
== Summary ==
The build flags (<code>CFLAGS</code>, <code>CXXFLAGS</code> and
<code>LDFLAGS</code>) saved in the Python's distutils module for
building extension modules are switched from:
* <code>%{build_cflags}</code>,
* <code>%{build_cxxflags}</code> and
* <code>%{build_ldflags}</code>
to:
* <code>%{extension_cflags}</code>,
* <code>%{extension_cxxflags}</code> and
* <code>%{extension_ldflags}</code>.
This [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
currently means] that no GCC plugins (such as annobin) are activated
and no GCC spec files (<code>-specs=</code> arguments) are used by
default when building Python extension modules (e.g. with
<code>python3 setup.py build</code>).
The {{package|python3-devel}} package will lose its runtime dependency
on {{package|redhat-rpm-config}} (which was only required for annobin
support and GCC spec files).
The change will affect building extension modules by users, outside of
the RPM environment. The Python standard library and Fedora's Python 3
RPM packages are still built with the "traditional" set of flags
(<code>%{build_cflags}</code> and friends), unless the package uses
nonstandard methods to build the extensions.
Only Python 3.7 ({{package|python3}}) and 3.6 ({{package|python36}})
will be changed.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Cstratak|Charalampos
Stratakis]]
* Email: python-maint@redhat.com
=== The Problem ===
When Python is built, it saves the flags (<code>CFLAGS</code>,
<code>CXXFLAGS</code> and <code>LDFLAGS</code>) for further use when
building extension modules into a designated <code>Makefile</code>.
The distutils module (a component responsible for building Python
packages and extension modules) then reads the file and applies the
flags. You can see the file at
<code>/usr/lib64/python3.7/config-3.7m-x86_64-linux-gnu/Makefile</code>
in {{package|python3-libs}}. This is mostly done to make user-built
extension modules binary compatible with the Python interpreter they
are being built for.
Traditionally (=before this change), the {{package|python3}} package
was created in a way that it simply saved the same set of flags used
for building itself.
This proved problematic as the flags used to build Fedora packages
grew specific things (not actually needed for binary compatibility of
the extension modules) and several workarounds needed to be made, most
specifically the {{package|python3-devel}} package got a runtime
dependency on {{package|redhat-rpm-config}}:
* https://bugzilla.redhat.com/show_bug.cgi?id=1217376
* https://bugzilla.redhat.com/show_bug.cgi?id=1496757
* https://bugzilla.redhat.com/show_bug.cgi?id=1218294
The problematic flags are GCC plugins (such as annobin) and GCC spec
files (<code>-specs=</code> arguments).
Example: Any Python developer using Fedora automatically builds Python
extension modules with annobin and hardening flags by default even if
they don't need that. They might build the extension on Fedora, test
it and later ship it and build it on a CI that is not based on Fedora
and get different results.
=== The Solution ===
The solution is not to save the problematic flags, but only the flags
needed. Until recently, this would be hackish, but
[https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
a designated set of flags] was created in Fedora 30, supposed to be
used by extension builders (such as the Python's distutil module):
<code>%{extension_cflags}</code>, <code>%{extension_cxxflags}</code>
and <code>%{extension_ldflags}</code>.
The [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders
documentation for the flags] currently reads:
<blockquote>
The current set of differences are:
* No GCC plugins (such as annobin) are activated.
* No GCC spec files (<code>-specs=</code> arguments) are used.
Additional flags may be removed in the future if they prove to be
incompatible with alternative toolchains.
</blockquote>
Python already had (incomplete) support for specifying different sets
of flags for itself and for the extensions. In Python 3.7.2 and 3.6.8
the ability was completed by providing a way to do this for
<code>LDFAGS</code> (this was actually driven by Fedora's needs).
Currently we are able to set a different set of flags for building
Python and for building user extension modules. The code implementing
this change can be inspected at
[https://src.fedoraproject.org/rpms/python3/pull-request/75 Fedora
python3 PR #75] and [https://github.com/python/cpython/pull/10900
CPython PR #10900].
=== Impact on users building extension modules ===
When an user compiles a Python extension module outside of RPMBuild
and does not specify any flags explicitly, this is what they used to
have:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/python3.7m -c demo.c
-o build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
After the change, they will get:
$ python3 setup.py build
running build
running build_ext
building 'demo' extension
creating build
creating build/temp.linux-x86_64-3.7
gcc -pthread -Wno-unused-result -Wsign-compare
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv
-fPIC -I/usr/include/python3.7m -c demo.c -o
build/temp.linux-x86_64-3.7/demo.o
creating build/lib.linux-x86_64-3.7
gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g
build/temp.linux-x86_64-3.7/demo.o -L/usr/lib64 -lpython3.7m -o
build/lib.linux-x86_64-3.7/demo.cpython-37m-x86_64-linux-gnu.so
Users are able to provide their own flags by setting the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
environment variables. They can, for example, opt-in for annobin if
they wish to do so.
=== Impact on RPM packages building extension modules ===
When the spec file of the package sets the
<code>CFLAGS</code>/<code>CXXFLAGS</code> and <code>LDFLAGS</code>
variables to the expected Fedora values (e.g.
<code>CFLAGS=${RPM_OPT_FLAGS} LDFLAGS=${RPM_LD_FLAGS}</code> or
<code>%{build_cflags}</code>, <code>%{build_cxxflags}</code>,
<code>%{build_ldflags}</code>, <code>%{optflags}</code> etc.)
everything works as expected. The currently documented way of building
Python packages (<code>%py3_build</code> and
<code>%py3_install</code>)
[https://src.fedoraproject.org/rpms/python-rpm-macros/blob/master/f/macros.python3
does this] for you, we recommend using it.
There might be some differences in the log, because the flags
concatenate. Here is the example from the {{package|python-psycopg2 }}
build.log.
Before this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -D_GNU_SOURCE -fPIC -fwrapv '''-O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
After this change:
gcc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG '''-O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection''' -D_GNU_SOURCE -fPIC
-fwrapv '''-O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection''' -fPIC -DPSYCOPG_DEFAULT_PYDATETIME=1
-DPSYCOPG_VERSION=2.7.5 (dt dec pq3 ext lo64) -DPG_VERSION_NUM=110000
-DHAVE_LO64=1 -I/usr/include/python3.7m -I. -I/usr/include
-I/usr/include/pgsql/server -c psycopg/psycopgmodule.c -o
build/temp.linux-x86_64-3.7/psycopg/psycopgmodule.o
-Wdeclaration-after-statement
If the package does <code>python3 setup.py build</code> to build the
extension modules manually without setting the flags, the flags are
not set properly. This is probably very rare. Even before the
<code>%py3_build</code> and <code>%py3_install</code> macros, the
preferred way was to call:
CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py build # from EL4
However, <code>LDFLAGS</code> are not set in that example.
There are 485 packages that have the <code>%{python3_sitearch}</code>
macro in them and hence are most likely to build Python extension
modules.
Out of those, 173 have <code>setup.py</code> directly in the spec. 65
have <code>setup.py build</code>. Change owners will go trough the
list and provide fixes. Packages are encouraged to switch to the
<code>%py3_build</code> macro themselves.
Worst case: Some package won't have annobin.
=== Python interpreters affected by this change ===
This change is fully possible (without backporting) in Python 3.6.8 /
3.7.2 or newer. Hence we'll only change the {{package|python3}} and
{{package|python36}} packages.
We'll keep older Pythons intact and let them finish their lifetime as
they are. Newer Python versions will inherit this change.
PyPy 3 ({{package|pypy3}}) might eventually be updated to a version
that supports this fully. Since no packages in Fedora use PyPy 3,
we'll update it then without a change proposal and we'll document the
fact on this Change page. (If any package starts using PyPy 3 untill
then, we'll coordinate with the maintainer/s).
== Benefit to Fedora ==
Python developers will get more upstream-like experience when building
Python extension modules.
Python developers won't need {{package|redhat-rpm-macros}} (and dozens
of other language-specific packages that go with that) installed just
to do so.
New decisions made about the distro packages won't necessarily affect
Python developers building their extension modules.
== Scope ==
* Proposal owners:
** Review, merge and build the
[https://src.fedoraproject.org/rpms/python3/pull-request/75 pull
request with the implementation].
** Go through the packages manually invoking <code>setup.py</code> to
build extension modules and provide fixes. Update to
<code>%py3_build</code> where possible, set the flags manually
otherwise.
* Other developers: Are encouraged to switch to
<code>%py3_build</code> (but they don't need to do anything, this is
not a System Wide Change).
* Release engineering: [https://pagure.io/releng/issue/8027 #8027]
(mass rebuild not needed, no releng impact anticipated).
* Policies and guidelines: already in place.
== Upgrade/compatibility impact ==
Not anticipated. Extension modules (built for the same Python version)
are compatible with the interpreter with or without the removed flags
back and forth.
== How To Test ==
=== For users (Python developers) ===
# build your favorite Python extension module in venv or outside venv
with <code>setup.py build</code> or <code>setup.py build_ext</code>
# observe the used flags and check annobin and <code>-specs</code>
'''are not there''', report bugs for {{package|python3}} otherwise
(and block our tracking bug)
# check if the extension works as expected
=== For packagers (Fedora contributors) ===
# build your favorite RPM package with Python extension module
# observe the used flags and check annobin and <code>-specs</code>
'''are there''', report bugs for that package otherwise (and block our
tracking bug)
# check if the package works as expected
== User Experience ==
See '''Benefit to Fedora''' above.
== Dependencies ==
Changes in {{package|redhat-rpm-config}} are already done.
We will check dependent Fedora packages.
== Contingency Plan ==
* Contingency mechanism: Change owners can revert the change at any
point. If removing the {{package|redhat-rpm-config}} dependency turns
out to be problematic, it can be added back until the problem is
fixed.
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
This page is the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
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
F30 System-Wide Change proposal: Reset locale if not available
https://fedoraproject.org/wiki/Changes/Reset-locale-if-not-available
== Summary ==
When logging in over ssh or another mechanism, locale settings are
forwarded. If the destination does not support that locale, C.UTF-8
will be used instead.
== Owner ==
* Name: [[User:Zbyszek | Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek@in.waw.pl
== Detailed Description ==
This is a continuation of [[Changes/Remove glibc-langpacks-all from
buildroot]]. With that change implemented, it is much more likely for
a system to only support C.UTF-8 or some other small set of locales.
When logging in into such an image from a normal system that uses a
"full" locale like en_US.UTF-8 or the equivalent for another language,
those locale settings are forwarded, resulting in a session with
invalid locale settings and errors from various tools.
The same problem could occur previously, for example when logging in
from a desktop with LANG=fr_FR.UTF-8 to a container with only
en_EN.UTF-8 installed.
To avoid this, the locale setting will be reset to C.UTF-8 if the
current setting is "invalid" (not found).
We already have a mechanism to reset locale information if it is
unusable. `/etc/profile.d/lang.sh` will unset
Japanese/Korean/Chinese/... locales only the tty, because the kernel
cannot display such fonts properly, so we switch to `en_US.UTF-8` to
get ''something'' displayed. The same mechanism will be used for this.
== Benefit to Fedora ==
Avoid stupid warnings like
<pre>
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_CTYPE = "fr_FR.UTF-8",
LANG = "en_US.UTF-8"
...
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
</pre>
== Scope ==
* Proposal owners:
** Provide a patch to `/etc/profile.d/lang.{sh,csh}` to check if the
inherited locale is present, and if not, reset to C.UTF-8.
* Other developers: n/a
* Release engineering: https://pagure.io/releng/issue/8036
** List of deliverables: N/A
* Policies and guidelines: no changes needed
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
I ''think'' this should be beneficial in all cases. I doubt that
anyone runs with broken locale settings on purpose.
== How To Test ==
Login to a different machine with a locale not installed on that
machine. Verify that the locale is set to C.UTF-8. If the locale is
installed on the target machine, it should not be reset.
== User Experience ==
Slightly easier ssh sessions.
See also [https://bugzilla.redhat.com/show_bug.cgi?id=1432426 1432426].
== Dependencies ==
None.
== Contingency Plan ==
Revert the change to `/etc/profile.d/lang.*`.
* Contingency mechanism: revert the patch, rebuild `setup` package
* Contingency deadline: any time before relase
* Blocks release? no
* Blocks product? no
== Documentation ==
None needed.
== Release Notes ==
Locale settings will be reset to C.UTF-8 when logging into a machine
which does not have the locale that is used on the source machine.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
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
== Summary ==
When logging in over ssh or another mechanism, locale settings are
forwarded. If the destination does not support that locale, C.UTF-8
will be used instead.
== Owner ==
* Name: [[User:Zbyszek | Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek@in.waw.pl
== Detailed Description ==
This is a continuation of [[Changes/Remove glibc-langpacks-all from
buildroot]]. With that change implemented, it is much more likely for
a system to only support C.UTF-8 or some other small set of locales.
When logging in into such an image from a normal system that uses a
"full" locale like en_US.UTF-8 or the equivalent for another language,
those locale settings are forwarded, resulting in a session with
invalid locale settings and errors from various tools.
The same problem could occur previously, for example when logging in
from a desktop with LANG=fr_FR.UTF-8 to a container with only
en_EN.UTF-8 installed.
To avoid this, the locale setting will be reset to C.UTF-8 if the
current setting is "invalid" (not found).
We already have a mechanism to reset locale information if it is
unusable. `/etc/profile.d/lang.sh` will unset
Japanese/Korean/Chinese/... locales only the tty, because the kernel
cannot display such fonts properly, so we switch to `en_US.UTF-8` to
get ''something'' displayed. The same mechanism will be used for this.
== Benefit to Fedora ==
Avoid stupid warnings like
<pre>
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_CTYPE = "fr_FR.UTF-8",
LANG = "en_US.UTF-8"
...
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
</pre>
== Scope ==
* Proposal owners:
** Provide a patch to `/etc/profile.d/lang.{sh,csh}` to check if the
inherited locale is present, and if not, reset to C.UTF-8.
* Other developers: n/a
* Release engineering: https://pagure.io/releng/issue/8036
** List of deliverables: N/A
* Policies and guidelines: no changes needed
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
I ''think'' this should be beneficial in all cases. I doubt that
anyone runs with broken locale settings on purpose.
== How To Test ==
Login to a different machine with a locale not installed on that
machine. Verify that the locale is set to C.UTF-8. If the locale is
installed on the target machine, it should not be reset.
== User Experience ==
Slightly easier ssh sessions.
See also [https://bugzilla.redhat.com/show_bug.cgi?id=1432426 1432426].
== Dependencies ==
None.
== Contingency Plan ==
Revert the change to `/etc/profile.d/lang.*`.
* Contingency mechanism: revert the patch, rebuild `setup` package
* Contingency deadline: any time before relase
* Blocks release? no
* Blocks product? no
== Documentation ==
None needed.
== Release Notes ==
Locale settings will be reset to C.UTF-8 when logging into a machine
which does not have the locale that is used on the source machine.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
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
Subscribe to:
Posts (Atom)