Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedDiskManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-disk-management-system-wide/124334
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This proposal adds a new dedicated `diskadmin` group, allowing users
to manage external drives without needing to be in the `wheel` group.
It will also enable wheel users to unlock and mount external drives
without a password prompt.
== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquirrel@secure.mailbox.org
== Detailed Description ==
Currently, to mount or (LUKS) unlock external drives, users need to be
in the `wheel` group. Removing a user from the wheel group would
prevent them from using external drives.
This enables an "admin" permission that is not tied to full root
access on the host system.
It will be a change of the polkit rule `org.freedesktop.udisks2.rules`
like following:
<pre>
polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.udisks2.encrypted-unlock-system" ||
action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
subject.active == true && subject.local == true && (
subject.isInGroup("diskadmin") || subject.isInGroup("wheel"))) {
return polkit.Result.YES;
}
});
</pre>
== Feedback ==
none yet
== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the mounting and unlocking of external drives, without needing
all the other privileges that `wheel` users have.
== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `diskadmin` group on GNOME and KDE
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: Documentation needs to get an additional
chapter on disk management with the `diskadmin` group.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Not sure, as it adds a
nonstandard user group.
== Upgrade/compatibility impact ==
The polkit rule will be added, users will not need to enter a password
if they are in these groups. No changes for users outside these
groups.
== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/80-org.freedesktop.udisks2.rules`.
This will be preferred over the default rule and you can test if it works.
== User Experience ==
By default, Anaconda puts users into the `wheel` group. These users
will not need to enter a password when mounting external media or
unlocking them.
It also allows to do these actions without being in the `wheel`
group, by adding a user to the `diskadmin` group.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
Will be added afterwards.
Nonwheel users can be added to the `diskadmin` group:
sudo groupadd diskadmin
sudo usermod -aG diskadmin USERNAME
== Release Notes ==
Users in the 'wheel' or 'diskadmin' group can mount and unlock
external drives without a password.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Monday, July 1, 2024
F41 Change Proposal: Reduce the amount of "dontaudit" rules pertaining to unlabeled_t (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/SELinux_dontaudit_unlabeled_t
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-reduce-the-amount-of-dontaudit-rules-pertaining-to-unlabeled-t-self-contained/124332
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Reduce the amount of rules that prevent reporting of SELinux denials
pertaining to unlabeled_t. This could influence the amount of
SELinux-related logs on some systems, but will not cause any new
permission denials.
== Owner ==
* Name: [[User:vmojzis| Vít Mojžíš]]
* Email: <vmojzis@redhat.com>
* Name: [[User:mmalik| Miloš Malík]]
* Email: <mmalik@redhat.com>
== Detailed Description ==
The SELinux security policy primarily comprises allow rules, which
permit specific operations on a confined system.
However, there are also SELinux rules featuring the "dontaudit" keyword.
In general, these rules signify that the described operation is not
allowed and will not be logged as a permission denial in audit logs.
The primary purpose of these rules is to hide certain false positives
or code defects, such as leaked descriptors.
The drawback is that, in certain instances, these rules might obscure
hints that could expedite debugging and issue resolution.
It is possible to disable all dontaudit rules using "semodule -DB",
but this usually leads to large amounts of benign denials being logged
and hence is not practical for long term use.
The goal of this change is to significantly reduce the amount of
dontaudit rules suppressing "unlabeled_t" denials,
which are often caused by miss-labeled filesystems and can usually be
easily fixed when noticed by the system administrator.
The rules will not be completely removed from the policy, only
disabled by default, so that the change can be reverted by the admin
if needed (<code># setsebool -P dontaudit_unlabeled_files 1</code>).
The change could influence the amount of SELinux-related logs on some
systems, but will not cause any new permission denials.
== Feedback ==
== Benefit to Fedora ==
Access denials caused by labeling issues will more likely be reported
by SELinux.
== Scope ==
* Proposal owners: Determine which dontaudit rules are safe to disable
by default and wrap them in conditional statements in the policy
sources -- changes will be limited to SElinux policy (and possibly
setroubleshoot) packages
* Other developers: Report any unlabeled_t AVCs triggered by their software
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: The change aligns with the
"accessibility" goal as it simplifies debugging of some labeling
issues
== Upgrade/compatibility impact ==
No functionality impact, no configuration or data migration.
The change could influence the amount of SELinux-related logs on some systems.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? - No
== How To Test ==
Run your testsuite with SELinux enabled (Enforcing or Permissive mode)
and record any AVCs containing unlabeld_t keyword.
<code># ausearch -m AVC,USER_AVC | grep unlabeled_t</code>
== User Experience ==
The change could increase the amount of SELinux-related logs on some systems.
== Dependencies ==
Changes will be limited to SElinux policy (and possibly
setroubleshoot) packages.
== Contingency Plan ==
* Contingency mechanism: Do not ship the updated SELinux-policy package
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have
written yourself? Link to that material here so other interested
developers can get involved. -->
Dontaudit rules can be added selectively using audit2allow:
<code># ausearch -m AVC | grep unlabeled_t | audit2allow -D -M
dontaudit_unlabeled </code>
<code># semodule -i dontaudit_unlabeled.pp </code>
All the disabled rules can be re-enabled by switching the
"dontaudit_unlabeled_files" boolean (will be added as part of the
change).
<code># setsebool -P dontaudit_unlabeled_files 1</code>
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-reduce-the-amount-of-dontaudit-rules-pertaining-to-unlabeled-t-self-contained/124332
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Reduce the amount of rules that prevent reporting of SELinux denials
pertaining to unlabeled_t. This could influence the amount of
SELinux-related logs on some systems, but will not cause any new
permission denials.
== Owner ==
* Name: [[User:vmojzis| Vít Mojžíš]]
* Email: <vmojzis@redhat.com>
* Name: [[User:mmalik| Miloš Malík]]
* Email: <mmalik@redhat.com>
== Detailed Description ==
The SELinux security policy primarily comprises allow rules, which
permit specific operations on a confined system.
However, there are also SELinux rules featuring the "dontaudit" keyword.
In general, these rules signify that the described operation is not
allowed and will not be logged as a permission denial in audit logs.
The primary purpose of these rules is to hide certain false positives
or code defects, such as leaked descriptors.
The drawback is that, in certain instances, these rules might obscure
hints that could expedite debugging and issue resolution.
It is possible to disable all dontaudit rules using "semodule -DB",
but this usually leads to large amounts of benign denials being logged
and hence is not practical for long term use.
The goal of this change is to significantly reduce the amount of
dontaudit rules suppressing "unlabeled_t" denials,
which are often caused by miss-labeled filesystems and can usually be
easily fixed when noticed by the system administrator.
The rules will not be completely removed from the policy, only
disabled by default, so that the change can be reverted by the admin
if needed (<code># setsebool -P dontaudit_unlabeled_files 1</code>).
The change could influence the amount of SELinux-related logs on some
systems, but will not cause any new permission denials.
== Feedback ==
== Benefit to Fedora ==
Access denials caused by labeling issues will more likely be reported
by SELinux.
== Scope ==
* Proposal owners: Determine which dontaudit rules are safe to disable
by default and wrap them in conditional statements in the policy
sources -- changes will be limited to SElinux policy (and possibly
setroubleshoot) packages
* Other developers: Report any unlabeled_t AVCs triggered by their software
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: The change aligns with the
"accessibility" goal as it simplifies debugging of some labeling
issues
== Upgrade/compatibility impact ==
No functionality impact, no configuration or data migration.
The change could influence the amount of SELinux-related logs on some systems.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? - No
== How To Test ==
Run your testsuite with SELinux enabled (Enforcing or Permissive mode)
and record any AVCs containing unlabeld_t keyword.
<code># ausearch -m AVC,USER_AVC | grep unlabeled_t</code>
== User Experience ==
The change could increase the amount of SELinux-related logs on some systems.
== Dependencies ==
Changes will be limited to SElinux policy (and possibly
setroubleshoot) packages.
== Contingency Plan ==
* Contingency mechanism: Do not ship the updated SELinux-policy package
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have
written yourself? Link to that material here so other interested
developers can get involved. -->
Dontaudit rules can be added selectively using audit2allow:
<code># ausearch -m AVC | grep unlabeled_t | audit2allow -D -M
dontaudit_unlabeled </code>
<code># semodule -i dontaudit_unlabeled.pp </code>
All the disabled rules can be re-enabled by switching the
"dontaudit_unlabeled_files" boolean (will be added as part of the
change).
<code># setsebool -P dontaudit_unlabeled_files 1</code>
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Retire Python 2.7 (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/RetirePython2.7
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-retire-python-2-7-system-wide/124331
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The {{package|python2.7}} package will be retired without replacement
from [[Releases/41|Fedora Linux 41]].
There will be no Python 2 in Fedora 41+ other than PyPy.
Packages requiring {{package|python2.7}} on runtime or buildtime will
have to deal with the retirement or be retired as well.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok@redhat.com
== Detailed Description ==
The {{package|python2.7}} package with the Python interpreter in
version 2.7 was kept in Fedora after upstream EOL
([https://devguide.python.org/versions/#versions 2020-01-01]) only to
make it possible for Fedora users to test their software against the
Python version shipped in RHEL 7, CentOS 7 and RHEL 8 and to support
remaining packages that could not be ported.
* Fedora 41 is to be released in October 2024, nearly 5 years after
the upstream EOL of Python 2.
* RHEL 7 will reach the end of its maintenance support 2 phase on
[https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhel-7-end-of-maintenance
2024-06-30].
* CentOS Linux 7 will reach end of life (EOL) on
[https://www.redhat.com/en/topics/linux/centos-linux-eol 2024-06-30].
* RHEL 8 Python 2.7 application stream retirement date is
[https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
June 2024].
=== Dependent packages ===
Based on `repoquery --repo=rawhide{,-source} --whatrequires
python2.7`, the following packages still depend on
{{package|python2.7}}:
* {{package|email2trac}} runtime and buidltime.
[https://bugzilla.redhat.com/1738907 rhbz#1738907] -- no response from
package maintainers since 2019. This package will be retired if not
fixed.
* {{package|flatpak-builder}} runtime only (shebang) in the tests
subpackage. [https://bugzilla.redhat.com/2249819 rhbz#2249819] -- no
response from package maintainers since late 2023, but we belive this
is a buggy dependency.
* {{package|flowcanvas}} buidltime only.
[https://bugzilla.redhat.com/1805233 rhbz#1805233] -- no response from
package maintainers since 2021. This package will fail to build and
will be eventually retired when Fedora 41 goes EOL if not fixed.
* {{package|kdissert}} buidltime only.
[https://bugzilla.redhat.com/1807513 rhbz#1807513] -- no response from
package maintainers since 2020. This package will fail to build and
will be eventually retired when Fedora 41 goes EOL if not fixed.
* {{package|qt5-qtwebengine}} buidltime only. No bugzilla. Package
bundles Python 2 for build in EPEL 9 and can probably do the same on
Fedora. Alternativelly, can use PyPy (untested assumption). This
package will fail to build and will be eventually retired when Fedora
41 goes EOL if not fixed.
* {{package|qtwebkit}} buidltime only.
[https://bugzilla.redhat.com/1807543 rhbz#1807543] -- no response from
package maintainers since 2021. The latest meaningful response: "The
plan is still to try to sunset Qt4WebKit entirely". This package will
fail to build and will be eventually retired when Fedora 41 goes EOL
if not fixed.
==== GIMP ====
The rest of the dependents exist merely for GIMP.
* {{package|gimp}}
* {{package|gimp-layer-via-copy-cut}}
* {{package|gimp-resynthesizer}}
* {{package|pygobject2}}
* {{package|pygtk2}}
* {{package|python2-cairo}}
[[Changes/Gimp_3|GIMP will be updated to GIMP 3 with Python 3
support]]. Python 2 dependencies of GIMP will be retired.
If by the time of the Fedora 41 Beta Freeze (2024-08-20) no Release
Candidate of GIMP 3 has come around, we will postpone the retirement
of Python 2 to Fedora 42.
== Feedback ==
See the [https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3-self-contained/120254/38
GIMP 3 discussion] for feedback from the GIMP maintainer.
== Benefit to Fedora ==
The Python maintainers will no longer regularly backport security
fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL
7 and the retirement of the Python 2.7 application stream in RHEL 8.
We provided this obsolete package for 5 years beyond its retirement
date and will continue to provide it until Fedora 40 goes end of life.
Enough has been enough.
We do not wish to simply orphan the package, as we are afraid it would
not receive proper care if taken by somebody else.
If there are potential maintainers interested in maintaining Python 2
in Fedora beyond Fedora 41, they can talk to us and demonstrate their
ability and will to take care of Python 2 by joining the maintenance
early.
Users who need to run their application in Python 2 should do so on a
platform that offers support for it. Running applications on
unsupported Python is dangerous.
Developers who still need to test their software on Python 2 can use
containers with older Fedora releases or unsupported CentOS/RHEL
versions.
== Scope ==
* Proposal owners:
** Coordinate closely with the GIMP maintainers.
** `fedpkg retire python2.7` before the beta freeze if GIMP is ready.
** Remove `Recommends: python2.7` from {{package|asv}} and {{package|tox}}.
* Other developers:
** Retire or fix the remaining dependent packages.
* Release engineering: [https://pagure.io/releng/issue/12175 #12175]
* Policies and guidelines: Using Python 2 is already forbidden for
Fedora packages.
* Trademark approval: not needed for this Change
* Alignment with the Fedora Strategy: n/a
== Upgrade/compatibility impact ==
Unless Python 2 stops being installable, we do not plan to Obsolete it.
Users who upgrade to Fedora Linux 41+ from earlier releases with
Python 2 installed, will likely still get it, but they will receive no
support.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Try installing {{package|python2.7}} on Fedora Linux 41+. It should fail.
== User Experience ==
Some users might be unhappy about this, but we decided to do it
anyway. We cannot keep legacy software forever, Fedora Linux is not
that kind of Linux.
== Dependencies ==
* [[Changes/Gimp_3]]
== Contingency Plan ==
* Contingency mechanism: postpone to Fedora 42
* Contingency deadline: A week after Beta Freeze
* Blocks release? No
== Documentation ==
There is no more Python 2 in Fedora Linux 41+.
== Release Notes ==
There is no more Python 2 in Fedora Linux 41+.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-retire-python-2-7-system-wide/124331
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The {{package|python2.7}} package will be retired without replacement
from [[Releases/41|Fedora Linux 41]].
There will be no Python 2 in Fedora 41+ other than PyPy.
Packages requiring {{package|python2.7}} on runtime or buildtime will
have to deal with the retirement or be retired as well.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok@redhat.com
== Detailed Description ==
The {{package|python2.7}} package with the Python interpreter in
version 2.7 was kept in Fedora after upstream EOL
([https://devguide.python.org/versions/#versions 2020-01-01]) only to
make it possible for Fedora users to test their software against the
Python version shipped in RHEL 7, CentOS 7 and RHEL 8 and to support
remaining packages that could not be ported.
* Fedora 41 is to be released in October 2024, nearly 5 years after
the upstream EOL of Python 2.
* RHEL 7 will reach the end of its maintenance support 2 phase on
[https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux/rhel-7-end-of-maintenance
2024-06-30].
* CentOS Linux 7 will reach end of life (EOL) on
[https://www.redhat.com/en/topics/linux/centos-linux-eol 2024-06-30].
* RHEL 8 Python 2.7 application stream retirement date is
[https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle
June 2024].
=== Dependent packages ===
Based on `repoquery --repo=rawhide{,-source} --whatrequires
python2.7`, the following packages still depend on
{{package|python2.7}}:
* {{package|email2trac}} runtime and buidltime.
[https://bugzilla.redhat.com/1738907 rhbz#1738907] -- no response from
package maintainers since 2019. This package will be retired if not
fixed.
* {{package|flatpak-builder}} runtime only (shebang) in the tests
subpackage. [https://bugzilla.redhat.com/2249819 rhbz#2249819] -- no
response from package maintainers since late 2023, but we belive this
is a buggy dependency.
* {{package|flowcanvas}} buidltime only.
[https://bugzilla.redhat.com/1805233 rhbz#1805233] -- no response from
package maintainers since 2021. This package will fail to build and
will be eventually retired when Fedora 41 goes EOL if not fixed.
* {{package|kdissert}} buidltime only.
[https://bugzilla.redhat.com/1807513 rhbz#1807513] -- no response from
package maintainers since 2020. This package will fail to build and
will be eventually retired when Fedora 41 goes EOL if not fixed.
* {{package|qt5-qtwebengine}} buidltime only. No bugzilla. Package
bundles Python 2 for build in EPEL 9 and can probably do the same on
Fedora. Alternativelly, can use PyPy (untested assumption). This
package will fail to build and will be eventually retired when Fedora
41 goes EOL if not fixed.
* {{package|qtwebkit}} buidltime only.
[https://bugzilla.redhat.com/1807543 rhbz#1807543] -- no response from
package maintainers since 2021. The latest meaningful response: "The
plan is still to try to sunset Qt4WebKit entirely". This package will
fail to build and will be eventually retired when Fedora 41 goes EOL
if not fixed.
==== GIMP ====
The rest of the dependents exist merely for GIMP.
* {{package|gimp}}
* {{package|gimp-layer-via-copy-cut}}
* {{package|gimp-resynthesizer}}
* {{package|pygobject2}}
* {{package|pygtk2}}
* {{package|python2-cairo}}
[[Changes/Gimp_3|GIMP will be updated to GIMP 3 with Python 3
support]]. Python 2 dependencies of GIMP will be retired.
If by the time of the Fedora 41 Beta Freeze (2024-08-20) no Release
Candidate of GIMP 3 has come around, we will postpone the retirement
of Python 2 to Fedora 42.
== Feedback ==
See the [https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3-self-contained/120254/38
GIMP 3 discussion] for feedback from the GIMP maintainer.
== Benefit to Fedora ==
The Python maintainers will no longer regularly backport security
fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL
7 and the retirement of the Python 2.7 application stream in RHEL 8.
We provided this obsolete package for 5 years beyond its retirement
date and will continue to provide it until Fedora 40 goes end of life.
Enough has been enough.
We do not wish to simply orphan the package, as we are afraid it would
not receive proper care if taken by somebody else.
If there are potential maintainers interested in maintaining Python 2
in Fedora beyond Fedora 41, they can talk to us and demonstrate their
ability and will to take care of Python 2 by joining the maintenance
early.
Users who need to run their application in Python 2 should do so on a
platform that offers support for it. Running applications on
unsupported Python is dangerous.
Developers who still need to test their software on Python 2 can use
containers with older Fedora releases or unsupported CentOS/RHEL
versions.
== Scope ==
* Proposal owners:
** Coordinate closely with the GIMP maintainers.
** `fedpkg retire python2.7` before the beta freeze if GIMP is ready.
** Remove `Recommends: python2.7` from {{package|asv}} and {{package|tox}}.
* Other developers:
** Retire or fix the remaining dependent packages.
* Release engineering: [https://pagure.io/releng/issue/12175 #12175]
* Policies and guidelines: Using Python 2 is already forbidden for
Fedora packages.
* Trademark approval: not needed for this Change
* Alignment with the Fedora Strategy: n/a
== Upgrade/compatibility impact ==
Unless Python 2 stops being installable, we do not plan to Obsolete it.
Users who upgrade to Fedora Linux 41+ from earlier releases with
Python 2 installed, will likely still get it, but they will receive no
support.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
Try installing {{package|python2.7}} on Fedora Linux 41+. It should fail.
== User Experience ==
Some users might be unhappy about this, but we decided to do it
anyway. We cannot keep legacy software forever, Fedora Linux is not
that kind of Linux.
== Dependencies ==
* [[Changes/Gimp_3]]
== Contingency Plan ==
* Contingency mechanism: postpone to Fedora 42
* Contingency deadline: A week after Beta Freeze
* Blocks release? No
== Documentation ==
There is no more Python 2 in Fedora Linux 41+.
== Release Notes ==
There is no more Python 2 in Fedora Linux 41+.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: IPU6 camera support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/IPU6_Camera_support
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-ipu6-camera-support-self-contained/124329
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Integrate support into Fedora for Intel IPU6 attached MIPI cameras
using the IPU6 CSI-receiver (isys) driver which has landed in kernel
6.10 together with libcamwera's 0.3 software ISP support and Firefox'
recent support for using cameras through pipewire.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
Many new laptops models have a camera-sensor which is directly
attached to the laptops CPU/SoC over a MIPI CSI2
databus instead of using a USB webcam module talking the standard USB
UVC protocol.
These cameras require a lot of work on the software side to go from
the raw Bayer data received over the CSI2
bus to an usable image. This includes both controlling things like
exposure and gain settings on the sensor
as well as a lot of processing of the raw data, such as debayering and
whitebalancing. Adding support for
these complex cameras is tricky because:
* Applications can no longer directly use /dev/video now
* Supporting ISPs (if supported in the kernel) requires ISP model
specific knowledge in userspace
* Vendor's 3A algorithms for auto-exposure/gain, auto-whitebalance and
auto-focus are secret and need to have open-source counterparts
written and tuned
* Instead of having a single UVC driver this requires CSI-receiver +
ISP + sensor drivers in the kernel
* Different IPU6 laptop models use different sensors, hw-enablement
needs to be done on a laptop by laptop basis
* Good image quality requires per sensor/laptop model tuning
Parts of these challenges are solved by libcamera. For now the aim is
a simple stack with good enough
image quality for video-conferencing. The plan is to have a stack consisting of:
# Mainline kernel sensor driver (currently supported: ov2740, ov01a10, hi556)
# Mainline kernel IPU6 CSI receiver driver
# libcamera simplepipeline-handler using software ISP for debayering + 3A
# pipewire with pipewire libcamera plugin
# pipewire support in Firefox (see [https://jgrulich.cz/tag/pipewire/
Jan Grulich's blog])
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Currently IPU6 cameras do not work OOTB in Fedora, with the new
libcamera software ISP stack
these should work OOTB on laptops with supported camera sensors.
== Scope ==
* Proposal owners:
** The IPU6 CSI receiver has landed in 6.10 and some bugfixes coming
to 6.11 have been added as downstream patches
** libcamera needs a couple of small downstream-patches to enable the
simple pipeline for the IPU6
** pipewire libcamera plugin needs to be made part of the default
Workstation patch-set
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Yes (better hw-support should
help getting more users)
== Upgrade/compatibility impact ==
The pipewire-plugin-libcamera needs to be automatically added on
Fedora workstation updates
to ensure things work. Otherwise there is no upgrade impact.
== How To Test ==
Test plan will be filled in as soon as all necessary bits have landed
in rawhide.
== User Experience ==
IPU6 cameras on laptops with supported camera sensors should work OOTB
after this change, with the caveat
that the image quality may be less then ideal. The hope is that image
quality will improve over time as
the software ISP and its 3A algorithms get improved. With that said it
is unrealistic to expect the image
quality to become as good as the proprietary stack which has extensive
image quality tuning done on a per
laptop basis.
== Dependencies ==
IPU6 support not only depends on kernel and libcamera support taken
care of by the proposal owner, but
also on pipewire camera support and on Firefox pipewire camera support.
== Contingency Plan ==
ATM IPU6 cameras do not work at all. So unless the new kernel driver
actually causes regressions outside
of the camera functionality no contingency plan is necessary.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 41 has added support for IPU6 cameras on laptops using ov2740,
ov01a10 and hi556 sensors. This
support requires using applications which support accessing cameras
through pipewire such as Firefox.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-ipu6-camera-support-self-contained/124329
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Integrate support into Fedora for Intel IPU6 attached MIPI cameras
using the IPU6 CSI-receiver (isys) driver which has landed in kernel
6.10 together with libcamwera's 0.3 software ISP support and Firefox'
recent support for using cameras through pipewire.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
Many new laptops models have a camera-sensor which is directly
attached to the laptops CPU/SoC over a MIPI CSI2
databus instead of using a USB webcam module talking the standard USB
UVC protocol.
These cameras require a lot of work on the software side to go from
the raw Bayer data received over the CSI2
bus to an usable image. This includes both controlling things like
exposure and gain settings on the sensor
as well as a lot of processing of the raw data, such as debayering and
whitebalancing. Adding support for
these complex cameras is tricky because:
* Applications can no longer directly use /dev/video now
* Supporting ISPs (if supported in the kernel) requires ISP model
specific knowledge in userspace
* Vendor's 3A algorithms for auto-exposure/gain, auto-whitebalance and
auto-focus are secret and need to have open-source counterparts
written and tuned
* Instead of having a single UVC driver this requires CSI-receiver +
ISP + sensor drivers in the kernel
* Different IPU6 laptop models use different sensors, hw-enablement
needs to be done on a laptop by laptop basis
* Good image quality requires per sensor/laptop model tuning
Parts of these challenges are solved by libcamera. For now the aim is
a simple stack with good enough
image quality for video-conferencing. The plan is to have a stack consisting of:
# Mainline kernel sensor driver (currently supported: ov2740, ov01a10, hi556)
# Mainline kernel IPU6 CSI receiver driver
# libcamera simplepipeline-handler using software ISP for debayering + 3A
# pipewire with pipewire libcamera plugin
# pipewire support in Firefox (see [https://jgrulich.cz/tag/pipewire/
Jan Grulich's blog])
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Currently IPU6 cameras do not work OOTB in Fedora, with the new
libcamera software ISP stack
these should work OOTB on laptops with supported camera sensors.
== Scope ==
* Proposal owners:
** The IPU6 CSI receiver has landed in 6.10 and some bugfixes coming
to 6.11 have been added as downstream patches
** libcamera needs a couple of small downstream-patches to enable the
simple pipeline for the IPU6
** pipewire libcamera plugin needs to be made part of the default
Workstation patch-set
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Yes (better hw-support should
help getting more users)
== Upgrade/compatibility impact ==
The pipewire-plugin-libcamera needs to be automatically added on
Fedora workstation updates
to ensure things work. Otherwise there is no upgrade impact.
== How To Test ==
Test plan will be filled in as soon as all necessary bits have landed
in rawhide.
== User Experience ==
IPU6 cameras on laptops with supported camera sensors should work OOTB
after this change, with the caveat
that the image quality may be less then ideal. The hope is that image
quality will improve over time as
the software ISP and its 3A algorithms get improved. With that said it
is unrealistic to expect the image
quality to become as good as the proprietary stack which has extensive
image quality tuning done on a per
laptop basis.
== Dependencies ==
IPU6 support not only depends on kernel and libcamera support taken
care of by the proposal owner, but
also on pipewire camera support and on Firefox pipewire camera support.
== Contingency Plan ==
ATM IPU6 cameras do not work at all. So unless the new kernel driver
actually causes regressions outside
of the camera functionality no contingency plan is necessary.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 41 has added support for IPU6 cameras on laptops using ov2740,
ov01a10 and hi556 sensors. This
support requires using applications which support accessing cameras
through pipewire such as Firefox.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F42 Change Proposal: Opt-In Metrics for Fedora Workstation (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/Metrics
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-opt-in-metrics-for-fedora-workstation-system-wide/124325
== Summary ==
The goal of this change proposal is to provide the Fedora community
with accurate, representative data about the real world use of Fedora
Workstation. By doing this, we believe that we can accelerate the
development of Fedora Workstation, and ensure that it improves in line
with our users' needs and requirements.
'''Protecting user privacy is of utmost importance for this
initiative.''' To this end, the service will only collect generic,
standardized data, and will never collect anything that is personally
identifying. It will also, of course, be fully open source. On the
server side, the data will be stored in a way that prevents user
identification.
'''Another important aspect of the initiative is that it will be run
in a transparent manner, and will be governed as part of the Fedora
project.''' A new SIG will be responsible for the service, and will be
open to community participation. It will publish analyses of the data
which has been collected, provide documentation about how the service
operates, will share samples of the database data, and will respond to
requests from the community.
'''Finally, we intend to ensure that metrics reporting is fully under
the control of end users.''' Metrics collection will default to off,
and will only be enabled through a clear on/off prompt in initial
setup. Users will be able to view the data that has been collected
locally, and will be able to remove the client software from their
systems, should they choose to do so.
To address concerns that the community might have, the change owners
have created a [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist], which will be updated as the
initiative progresses.
== Owners ==
* Name: [[User:aday|Allan Day]]
* Name: [[User:catanzaro|Michael Catanzaro]]
* Name: [https://docs.fedoraproject.org/en-US/workstation-working-group/
Fedora Workstation Working Group]
== Current status ==
The proposal is to deploy a pre-existing data collection system -
called Azafea - for Fedora Workstation. Azafea has both client and
server components. Significant work is required to make a wide scale
deployment of Azafea possible (see scope section below).
This updated proposal obsoletes [[Changes/Telemetry | the original proposal]].
* Targeted release: [[Releases/42 | Fedora Linux 42]]
== Detailed Description ==
This section includes a detailed description of each aspect of the
metrics proposal.
=== Data that will be collected ===
All collected data will be anonymous:
* We will not collect identifying information, such as email
addresses, online account details, and IP addresses.
* We will only collect generic, standardized information. For example,
we want to collect data on which apps are used, but we will never
collect data on which websites are viewed or which files are opened.
* Server side, each metric will be stored separately and will not be
linked to other metrics from the same system. This will prevent user
fingerprinting through the cross-referencing of anonymous information.
All of the code in the data collection system will be open source and
available for public inspection.
The data we plan on collecting will fall into the following categories:
{| class="wikitable" style="margin:auto"
|-
! Category !! Examples
|-
| Hardware details || CPU, graphics, cameras, which peripherals are present.
|-
| System settings || The display language, which input methods are
used, which accessibility features are enabled.
|-
| Desktop usage patterns || Which apps are used, how many open
workspaces there are, how often each system settings panel is opened.
|-
| Performance reports || Disk and memory usage.
|-
| Evidence of problems || Counts of system crashes, OOM events, app crashes.
|}
For more detailed information, see the
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md
preliminary list of metrics that we want to collect]. This list
indicates the purpose of each metric that we hope to collect.
=== Steps to ensure anonymity ===
The [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md
metrics that we hope to collect] are all generic in nature, and do not
contain personal or identifying information.
To prevent accidental collection of identifying information, the data
we collect will be filtered on the client side, so that only known,
standardized variables are included. For example, when recording which
apps are used, we will only record known package names, in order to
prevent custom apps with identifying metadata from being recorded.
Wherever possible, the system will aggregate data locally prior to
upload. For example, it can report the number of times that a feature
was used in a week, instead of the exact time whenever it is used.
This method further increases anonymity by reducing the precision of
the data that is reported.
We will only deploy the service once it has undergone a thorough
period of testing, during which we will verify that the database is
only being populated with anonymous data. (Data from the testing phase
of the system will be permanently deleted.)
=== How metrics data will be used ===
We anticipate that the data we collect will drive myriad improvements
within Fedora as well as the wider ecosystem. These improvements
include:
'''Resource prioritization''' - knowing which hardware, features and
apps are used most will allow developers and partners to focus their
efforts where they will have the most impact.
'''Software improvements''' - data about usage and performance
patterns can drive optimisations in existing software, in terms of
both technical and UX design.
'''Configuration enhancements''' - decisions about default settings
and the default composition of Fedora Workstation can be based on
observed usage patterns.
'''Better development practices''' - we aim to promote and encourage
user and data driven development practices through this work.
To achieve these impacts, analysis of the collected data will be
published and circulated to the relevant developers and projects.
=== Who will have access to metrics data ===
In the interests of transparency, we will put the following mechanisms
in place for viewing the data that is collected:
# Raw data from the database will be published during the testing
phase, prior to wide scale deployment
# Members of the community will be able to join the metrics SIG, in
order to get full ongoing access to the data
# After deployment, a randomly selected sample of the database will be
published (once it has been manually checked)
# Members of the community will be able to request the SIG for copies
of the database, which will be shared privately
This proposal is an attempt to balance the need to protect privacy
with the need to provide transparency. We have a high degree of
confidence that the database will only contain anonymous data (see
"how will we ensure that the system only collects anonymous, generic
data?"). However, there is always some risk that something could go
wrong with data collection. Out of an abundance of caution, we
therefore only want to share data once it has been manually checked.
=== Approval for changes to the metrics system ===
Any changes to the metrics system and its governance arrangements will
require approval by FESCo. This will include any changes to the:
* metrics data that is collected
* the metrics SIG (its rules, role, composition, membership terms)
* the technology used
* changes to the UI for user opt in/opt out
* hosting of the infrastructure or involvement of 3rd parties
=== User control ===
The proposed system aims to ensure that users are always in control of
metrics collection on their systems. This will be achieved through the
following:
* The setting for metrics collection will enabled/disable both local
metrics collection and data upload
* Metrics collection will be off by default
* Metrics collection will only be enabled through an explicit opt in
from the user, which will be presented as part of initial setup
* It will always be possible for users to disable metrics collection
from the system settings
* It will be possible for users to view the metrics that have been
collected locally on their systems
* It will be possible for users to remove the metrics collection
components from their systems, using dnf
=== Metrics system components ===
The metrics system would be composed of server and client Azafea components.
An Azafea server deployment consists of five components: 1. an nginx
proxy server, 2. azafea-metrics-proxy, 3. redis, 4. azafea itself, 5.
a Postgres database
nginx proxies HTTP requests to azafea-metrics-proxy, which is itself a
simple HTTP server that adds batches of metrics into the redis
database, where they will be fetched by Azafea and stored into
Postgres.
The client side consists of the following components:
* eos-metrics - a D-Bus interface that applications and services may
use to record events, plus a GObject library that provides a simple
API around the D-Bus interface
* eos-event-recorder-daemon - the service that actually implements
the D-Bus interface: it collects metrics recorded via D-Bus, batches
them together, and sends them to the metrics server at predefined
intervals
* eos-metrics-instrumentation - the component that calls D-Bus methods
on eos-event-recorder
== Feedback ==
The [[Changes/Telemetry|initial version of this proposal]] generated a
huge amount of feedback and debate. We have put a lot of time and
effort into engaging with this feedback, and the proposal has been
substantially changed in response to it. We are grateful to the Fedora
community for enabling us to improve the proposal in this way.
We know that there were issues with the original proposal, and that
these led to serious concerns amongst the community. We hope that the
updated proposal addresses these concerns, and look forward to
receiving further feedback.
The following is a summary of the key points from the discussion so
far, along with details of the steps that have been taken in response
to them. Additional information is also included in the
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-faq.md
FAQ] If we have missed something from that discussion, please let us
know.
=== Opt in or opt out? ===
The original proposal specified that metrics upload would be disabled
by default, and that the UI setup would include an on by default
switch to allow users to opt out. This aspect of the proposal
attracted by far the most negative feedback.
As a result of this feedback, we have changed the proposal: we now
propose that initial setup will show an explicit yes/no prompt which
has no default value.
We recognise that feedback about the opt-out UI reflected wider
concerns about the privacy and transparency of the metrics system,
which we have addressed through other changes.
=== Proposal omissions ===
We received feedback that the original proposal omitted key details
from the proposal, including:
* The benefit to Fedora
* Which metrics will be collected
* That each metric will be stored separately and will not be correlated
* How members of the community will be able to access the database
* Whether users will be able to view the local data that has been
collected on their systems
* That the metrics packages can be removed using DNF
* The policy through which the collection of specific metrics will be approved
This information has now been added to the proposal.
=== Ability to view the entire data set ===
This was a frequent request in the feedback we received. We understand
the motivation to have transparency and to verify what data is being
collected.
"Who will have access to the data?" contains an updated proposal which
we hope will satisfy this desire while also preventing potential
privacy issues.
=== Risks to anonymity if the metrics server is hacked ===
This was another major subject of discussion, with various concerns
being raised.
We are confident that it will not be possible for the administrators
of the metrics system to identify or fingerprint users under normal
operation of the metrics server. We also want to emphasize the generic
nature of the metrics we want to collect.
We have also committed to:
* Take steps to minimize risks, such as having short retention of server logs
* Manage the server through the metrics SIG, so that members of the
community can contribute their expertise
* Document the infrastructure setup for the metrics server once it has
been setup, in order to solicit further feedback
These points have been added to our
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist].
The metrics server will not store IP addresses or entire batches of
metrics data. However, we acknowledge that, if Fedora infrastructure
is compromised, an attacker could begin recording this information. We
acknowledge this as a risk of the system.
=== Local data collection ===
The original proposal specified that local data collection would
default to on, while upload of that data would default to off. Some
pointed out that this would be a privacy risk.
In the new version of the proposal, local data collection will only be
enabled after the user has consented to metrics collection.
=== Other suggestions===
We received various other suggestions during the debate about the
original change proposal. These included:
==== Provide fine-grained user control over which data is uploaded ====
This would add complexity to the system and to data analysis. We are
also unsure how much these fine-grained controls would be used in
practice. This is not something that we are rejecting outright, but it
is unlikely something that we ourselves would be able to add to the
initial version of the system.
==== Only collect some metrics for a fixed time period ====
We agree that this makes sense for some metrics and we have added this
to our [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist], as a future work item.
==== Restrict metrics collection to a small sample of users ====
The main issues with this approach would be ensuring that the sample
is representative, and our ability to detect issues experienced by
subsets of the user base.
==== Collaborate with a trusted third party ====
The idea behind this suggestion was for us to get additional oversight
and input from an organization that has expertise in data privacy
issues. We'd be very happy to do this, but are unsure who that third
party would be. We are open to suggestions!
==== Adopt differential privacy techniques ====
[https://desfontain.es/blog/friendly-intro-to-differential-privacy.html
Differential privacy] would potentially allow Fedora systems to submit
inaccurate data to the metrics server, while ensuring the overall data
set is still representative and useful. We would welcome collaboration
from Fedora community members interested in improving the metrics
collection system to adopt such techniques.
== Benefit to Fedora ==
See "What will the data be used for?"
== Scope ==
* Proposal owners: this change requires substantial technical and
nontechnical work from the change owners. This will include:
** Properly packaging eos-metrics, eos-event-recorder-daemon, and
eos-metrics-instrumentation for Fedora
** Modifying eos-metrics-instrumentation so that it does not send
events that are not approved for use in Fedora
** Creation of the metrics SIG and its various policies and procedures
** Documentation for end users and members of the community
* Other developers: Community Platform Engineering (CPE) will need to
host the metrics server infrastructure.
* Release engineering: [https://pagure.io/releng/issues/11514 #11514]
* Policies and guidelines: see "How will data collection be approved?"
* Trademark approval: N/A (not needed for this change)
* Alignment with objectives: there are currently no
[https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora
Initiatives]. However, the generated data will be broadly applicable
to Fedora community activities.
== Upgrade/Compatibility Impact ==
There are no special technical challenges in this regard.
Metrics collection will only be enabled in response to an explicit
opt-in by the user, through a UI in either gnome-initial-setup or
gnome-control-center. gnome-initial-setup is only shown for new
installs, meaning that the only way to enable metrics on an upgraded
system would be through gnome-control-center.
== How to Test ==
Testing is not currently possible. Instructions will be provided when
this changes.
== User Experience==
The user experience for the system will consist of:
# In initial setup, a UI to choose between metrics collection being on
or off. There will be no default in the UI and users will have to
explicitly choose one of the two options.
# In the privacy Settings, a switch to turn metrics collection on or off
# User documentation about the service
# A method to view locally collected metrics data
== Dependencies ==
Packages wanting to collect metrics data will need to depend on
eos-metrics. For example, to collect statistics about Settings usage,
the gnome-control-center package would need to depend on eos-metrics
in order to send a metric to eos-event-recorder-daemon.
== Contingency Plan ==
* Contingency mechanism: remove the eos-metrics,
eos-event-recorder-daemon, and eos-metrics-instrumentation packages
from the workstation-product comps group, and rebuild any packages
that gained a dependency on eos-metrics.
* Contingency deadline: beta freeze
* Blocks release? If the change is incomplete, it will need to be
reverted before release.
== Documentation ==
This feature depends on several different upstream projects, each of
which have their own documentation.
Client side components:
* eos-metrics has online docs at
[https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metrics.xml
D-Bus interface XML]. API documentation is also built and installed in
a docs subpackage.
* eos-event-recorder-daemon and eos-metrics-instrumentation components
do not have online documentation at this time.
Server-side documentation:
* [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source
Azafea-metrics-proxy]
* [https://github.com/endlessm/azafea/tree/master/docs/source Azafea]
* [https://azafea.readthedocs.io/en/latest/events.html Events
recognized by the server] (this documentation is currently focused on
use by Endless OS rather than by Fedora, and includes documentation of
many events that are no longer sent by Endless OS)
== Release Notes ==
These will be provided if the proposal is approved and successfully implemented.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-opt-in-metrics-for-fedora-workstation-system-wide/124325
== Summary ==
The goal of this change proposal is to provide the Fedora community
with accurate, representative data about the real world use of Fedora
Workstation. By doing this, we believe that we can accelerate the
development of Fedora Workstation, and ensure that it improves in line
with our users' needs and requirements.
'''Protecting user privacy is of utmost importance for this
initiative.''' To this end, the service will only collect generic,
standardized data, and will never collect anything that is personally
identifying. It will also, of course, be fully open source. On the
server side, the data will be stored in a way that prevents user
identification.
'''Another important aspect of the initiative is that it will be run
in a transparent manner, and will be governed as part of the Fedora
project.''' A new SIG will be responsible for the service, and will be
open to community participation. It will publish analyses of the data
which has been collected, provide documentation about how the service
operates, will share samples of the database data, and will respond to
requests from the community.
'''Finally, we intend to ensure that metrics reporting is fully under
the control of end users.''' Metrics collection will default to off,
and will only be enabled through a clear on/off prompt in initial
setup. Users will be able to view the data that has been collected
locally, and will be able to remove the client software from their
systems, should they choose to do so.
To address concerns that the community might have, the change owners
have created a [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist], which will be updated as the
initiative progresses.
== Owners ==
* Name: [[User:aday|Allan Day]]
* Name: [[User:catanzaro|Michael Catanzaro]]
* Name: [https://docs.fedoraproject.org/en-US/workstation-working-group/
Fedora Workstation Working Group]
== Current status ==
The proposal is to deploy a pre-existing data collection system -
called Azafea - for Fedora Workstation. Azafea has both client and
server components. Significant work is required to make a wide scale
deployment of Azafea possible (see scope section below).
This updated proposal obsoletes [[Changes/Telemetry | the original proposal]].
* Targeted release: [[Releases/42 | Fedora Linux 42]]
== Detailed Description ==
This section includes a detailed description of each aspect of the
metrics proposal.
=== Data that will be collected ===
All collected data will be anonymous:
* We will not collect identifying information, such as email
addresses, online account details, and IP addresses.
* We will only collect generic, standardized information. For example,
we want to collect data on which apps are used, but we will never
collect data on which websites are viewed or which files are opened.
* Server side, each metric will be stored separately and will not be
linked to other metrics from the same system. This will prevent user
fingerprinting through the cross-referencing of anonymous information.
All of the code in the data collection system will be open source and
available for public inspection.
The data we plan on collecting will fall into the following categories:
{| class="wikitable" style="margin:auto"
|-
! Category !! Examples
|-
| Hardware details || CPU, graphics, cameras, which peripherals are present.
|-
| System settings || The display language, which input methods are
used, which accessibility features are enabled.
|-
| Desktop usage patterns || Which apps are used, how many open
workspaces there are, how often each system settings panel is opened.
|-
| Performance reports || Disk and memory usage.
|-
| Evidence of problems || Counts of system crashes, OOM events, app crashes.
|}
For more detailed information, see the
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md
preliminary list of metrics that we want to collect]. This list
indicates the purpose of each metric that we hope to collect.
=== Steps to ensure anonymity ===
The [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-to-collect.md
metrics that we hope to collect] are all generic in nature, and do not
contain personal or identifying information.
To prevent accidental collection of identifying information, the data
we collect will be filtered on the client side, so that only known,
standardized variables are included. For example, when recording which
apps are used, we will only record known package names, in order to
prevent custom apps with identifying metadata from being recorded.
Wherever possible, the system will aggregate data locally prior to
upload. For example, it can report the number of times that a feature
was used in a week, instead of the exact time whenever it is used.
This method further increases anonymity by reducing the precision of
the data that is reported.
We will only deploy the service once it has undergone a thorough
period of testing, during which we will verify that the database is
only being populated with anonymous data. (Data from the testing phase
of the system will be permanently deleted.)
=== How metrics data will be used ===
We anticipate that the data we collect will drive myriad improvements
within Fedora as well as the wider ecosystem. These improvements
include:
'''Resource prioritization''' - knowing which hardware, features and
apps are used most will allow developers and partners to focus their
efforts where they will have the most impact.
'''Software improvements''' - data about usage and performance
patterns can drive optimisations in existing software, in terms of
both technical and UX design.
'''Configuration enhancements''' - decisions about default settings
and the default composition of Fedora Workstation can be based on
observed usage patterns.
'''Better development practices''' - we aim to promote and encourage
user and data driven development practices through this work.
To achieve these impacts, analysis of the collected data will be
published and circulated to the relevant developers and projects.
=== Who will have access to metrics data ===
In the interests of transparency, we will put the following mechanisms
in place for viewing the data that is collected:
# Raw data from the database will be published during the testing
phase, prior to wide scale deployment
# Members of the community will be able to join the metrics SIG, in
order to get full ongoing access to the data
# After deployment, a randomly selected sample of the database will be
published (once it has been manually checked)
# Members of the community will be able to request the SIG for copies
of the database, which will be shared privately
This proposal is an attempt to balance the need to protect privacy
with the need to provide transparency. We have a high degree of
confidence that the database will only contain anonymous data (see
"how will we ensure that the system only collects anonymous, generic
data?"). However, there is always some risk that something could go
wrong with data collection. Out of an abundance of caution, we
therefore only want to share data once it has been manually checked.
=== Approval for changes to the metrics system ===
Any changes to the metrics system and its governance arrangements will
require approval by FESCo. This will include any changes to the:
* metrics data that is collected
* the metrics SIG (its rules, role, composition, membership terms)
* the technology used
* changes to the UI for user opt in/opt out
* hosting of the infrastructure or involvement of 3rd parties
=== User control ===
The proposed system aims to ensure that users are always in control of
metrics collection on their systems. This will be achieved through the
following:
* The setting for metrics collection will enabled/disable both local
metrics collection and data upload
* Metrics collection will be off by default
* Metrics collection will only be enabled through an explicit opt in
from the user, which will be presented as part of initial setup
* It will always be possible for users to disable metrics collection
from the system settings
* It will be possible for users to view the metrics that have been
collected locally on their systems
* It will be possible for users to remove the metrics collection
components from their systems, using dnf
=== Metrics system components ===
The metrics system would be composed of server and client Azafea components.
An Azafea server deployment consists of five components: 1. an nginx
proxy server, 2. azafea-metrics-proxy, 3. redis, 4. azafea itself, 5.
a Postgres database
nginx proxies HTTP requests to azafea-metrics-proxy, which is itself a
simple HTTP server that adds batches of metrics into the redis
database, where they will be fetched by Azafea and stored into
Postgres.
The client side consists of the following components:
* eos-metrics - a D-Bus interface that applications and services may
use to record events, plus a GObject library that provides a simple
API around the D-Bus interface
* eos-event-recorder-daemon - the service that actually implements
the D-Bus interface: it collects metrics recorded via D-Bus, batches
them together, and sends them to the metrics server at predefined
intervals
* eos-metrics-instrumentation - the component that calls D-Bus methods
on eos-event-recorder
== Feedback ==
The [[Changes/Telemetry|initial version of this proposal]] generated a
huge amount of feedback and debate. We have put a lot of time and
effort into engaging with this feedback, and the proposal has been
substantially changed in response to it. We are grateful to the Fedora
community for enabling us to improve the proposal in this way.
We know that there were issues with the original proposal, and that
these led to serious concerns amongst the community. We hope that the
updated proposal addresses these concerns, and look forward to
receiving further feedback.
The following is a summary of the key points from the discussion so
far, along with details of the steps that have been taken in response
to them. Additional information is also included in the
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-faq.md
FAQ] If we have missed something from that discussion, please let us
know.
=== Opt in or opt out? ===
The original proposal specified that metrics upload would be disabled
by default, and that the UI setup would include an on by default
switch to allow users to opt out. This aspect of the proposal
attracted by far the most negative feedback.
As a result of this feedback, we have changed the proposal: we now
propose that initial setup will show an explicit yes/no prompt which
has no default value.
We recognise that feedback about the opt-out UI reflected wider
concerns about the privacy and transparency of the metrics system,
which we have addressed through other changes.
=== Proposal omissions ===
We received feedback that the original proposal omitted key details
from the proposal, including:
* The benefit to Fedora
* Which metrics will be collected
* That each metric will be stored separately and will not be correlated
* How members of the community will be able to access the database
* Whether users will be able to view the local data that has been
collected on their systems
* That the metrics packages can be removed using DNF
* The policy through which the collection of specific metrics will be approved
This information has now been added to the proposal.
=== Ability to view the entire data set ===
This was a frequent request in the feedback we received. We understand
the motivation to have transparency and to verify what data is being
collected.
"Who will have access to the data?" contains an updated proposal which
we hope will satisfy this desire while also preventing potential
privacy issues.
=== Risks to anonymity if the metrics server is hacked ===
This was another major subject of discussion, with various concerns
being raised.
We are confident that it will not be possible for the administrators
of the metrics system to identify or fingerprint users under normal
operation of the metrics server. We also want to emphasize the generic
nature of the metrics we want to collect.
We have also committed to:
* Take steps to minimize risks, such as having short retention of server logs
* Manage the server through the metrics SIG, so that members of the
community can contribute their expertise
* Document the infrastructure setup for the metrics server once it has
been setup, in order to solicit further feedback
These points have been added to our
[https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist].
The metrics server will not store IP addresses or entire batches of
metrics data. However, we acknowledge that, if Fedora infrastructure
is compromised, an attacker could begin recording this information. We
acknowledge this as a risk of the system.
=== Local data collection ===
The original proposal specified that local data collection would
default to on, while upload of that data would default to off. Some
pointed out that this would be a privacy risk.
In the new version of the proposal, local data collection will only be
enabled after the user has consented to metrics collection.
=== Other suggestions===
We received various other suggestions during the debate about the
original change proposal. These included:
==== Provide fine-grained user control over which data is uploaded ====
This would add complexity to the system and to data analysis. We are
also unsure how much these fine-grained controls would be used in
practice. This is not something that we are rejecting outright, but it
is unlikely something that we ourselves would be able to add to the
initial version of the system.
==== Only collect some metrics for a fixed time period ====
We agree that this makes sense for some metrics and we have added this
to our [https://pagure.io/fedora-workstation/blob/master/f/notes/metrics-privacy-transparency.md
privacy and transparency checklist], as a future work item.
==== Restrict metrics collection to a small sample of users ====
The main issues with this approach would be ensuring that the sample
is representative, and our ability to detect issues experienced by
subsets of the user base.
==== Collaborate with a trusted third party ====
The idea behind this suggestion was for us to get additional oversight
and input from an organization that has expertise in data privacy
issues. We'd be very happy to do this, but are unsure who that third
party would be. We are open to suggestions!
==== Adopt differential privacy techniques ====
[https://desfontain.es/blog/friendly-intro-to-differential-privacy.html
Differential privacy] would potentially allow Fedora systems to submit
inaccurate data to the metrics server, while ensuring the overall data
set is still representative and useful. We would welcome collaboration
from Fedora community members interested in improving the metrics
collection system to adopt such techniques.
== Benefit to Fedora ==
See "What will the data be used for?"
== Scope ==
* Proposal owners: this change requires substantial technical and
nontechnical work from the change owners. This will include:
** Properly packaging eos-metrics, eos-event-recorder-daemon, and
eos-metrics-instrumentation for Fedora
** Modifying eos-metrics-instrumentation so that it does not send
events that are not approved for use in Fedora
** Creation of the metrics SIG and its various policies and procedures
** Documentation for end users and members of the community
* Other developers: Community Platform Engineering (CPE) will need to
host the metrics server infrastructure.
* Release engineering: [https://pagure.io/releng/issues/11514 #11514]
* Policies and guidelines: see "How will data collection be approved?"
* Trademark approval: N/A (not needed for this change)
* Alignment with objectives: there are currently no
[https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora
Initiatives]. However, the generated data will be broadly applicable
to Fedora community activities.
== Upgrade/Compatibility Impact ==
There are no special technical challenges in this regard.
Metrics collection will only be enabled in response to an explicit
opt-in by the user, through a UI in either gnome-initial-setup or
gnome-control-center. gnome-initial-setup is only shown for new
installs, meaning that the only way to enable metrics on an upgraded
system would be through gnome-control-center.
== How to Test ==
Testing is not currently possible. Instructions will be provided when
this changes.
== User Experience==
The user experience for the system will consist of:
# In initial setup, a UI to choose between metrics collection being on
or off. There will be no default in the UI and users will have to
explicitly choose one of the two options.
# In the privacy Settings, a switch to turn metrics collection on or off
# User documentation about the service
# A method to view locally collected metrics data
== Dependencies ==
Packages wanting to collect metrics data will need to depend on
eos-metrics. For example, to collect statistics about Settings usage,
the gnome-control-center package would need to depend on eos-metrics
in order to send a metric to eos-event-recorder-daemon.
== Contingency Plan ==
* Contingency mechanism: remove the eos-metrics,
eos-event-recorder-daemon, and eos-metrics-instrumentation packages
from the workstation-product comps group, and rebuild any packages
that gained a dependency on eos-metrics.
* Contingency deadline: beta freeze
* Blocks release? If the change is incomplete, it will need to be
reverted before release.
== Documentation ==
This feature depends on several different upstream projects, each of
which have their own documentation.
Client side components:
* eos-metrics has online docs at
[https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metrics.xml
D-Bus interface XML]. API documentation is also built and installed in
a docs subpackage.
* eos-event-recorder-daemon and eos-metrics-instrumentation components
do not have online documentation at this time.
Server-side documentation:
* [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source
Azafea-metrics-proxy]
* [https://github.com/endlessm/azafea/tree/master/docs/source Azafea]
* [https://azafea.readthedocs.io/en/latest/events.html Events
recognized by the server] (this documentation is currently focused on
use by Endless OS rather than by Fedora, and includes documentation of
many events that are no longer sent by Endless OS)
== Release Notes ==
These will be provided if the proposal is approved and successfully implemented.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora & AI Survey Now Live Until July 16th
Hi folks,
Thank you for contributing to our discussion on what kinds of questions are useful for us to ask our community on the subject of AI in the Fedora ecosystem [1]. We've created a short survey [2] based on the questions that were proposed that we feel are general enough for everyone to feel comfortable answering, and from the answer we receive, the council and other governing bodies of the project can start formalising some AI-related focus areas and develop solid guidelines for the use of AI in the project ecosystem.
The deadline is July 16th, it shouldn't take more than a few minutes of your time to complete, and I will be sending some reminders between now and the closing date too.
A quick reminder that this is not our annual contributors survey, and that survey will be launching soon with a section around AI too. I want to offer an advance apologies for any survey-related fatigue, but when it comes to creating AI guidelines for the project and understanding how our community is doing and feels about the project, this AI survey and the contributor survey is truly the best way to get that feedback and create actionable stuff 'n' things from your direct responses.
Kindest regards,
Aoife
[arch-announce] The sshd service needs to be restarted after upgrading to openssh-9.8p1
After upgrading to `openssh-9.8p1`, the existing SSH daemon will be unable to accept new connections (see <https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5>).
When upgrading remote hosts, please make sure to restart the sshd service
using `systemctl try-restart sshd` right after upgrading.
We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.
URL: https://archlinux.org/news/the-sshd-service-needs-to-be-restarted-after-upgrading-to-openssh-98p1/
When upgrading remote hosts, please make sure to restart the sshd service
using `systemctl try-restart sshd` right after upgrading.
We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.
URL: https://archlinux.org/news/the-sshd-service-needs-to-be-restarted-after-upgrading-to-openssh-98p1/
[USN-6859-1] OpenSSH vulnerability
==========================================================================
Ubuntu Security Notice USN-6859-1
July 01, 2024
openssh vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 24.04 LTS
- Ubuntu 23.10
- Ubuntu 22.04 LTS
Summary:
OpenSSH could be made to bypass authentication and remotely
access systems without proper credentials.
Software Description:
- openssh: secure shell (SSH) for secure access to remote machines
Details:
It was discovered that OpenSSH incorrectly handled signal management. A
remote attacker could use this issue to bypass authentication and remotely
access systems without proper credentials.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 24.04 LTS
openssh-client 1:9.6p1-3ubuntu13.3
openssh-server 1:9.6p1-3ubuntu13.3
Ubuntu 23.10
openssh-client 1:9.3p1-1ubuntu3.6
openssh-server 1:9.3p1-1ubuntu3.6
Ubuntu 22.04 LTS
openssh-client 1:8.9p1-3ubuntu0.10
openssh-server 1:8.9p1-3ubuntu0.10
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6859-1
CVE-2024-6387
Package Information:
https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.3
https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.6
https://launchpad.net/ubuntu/+source/openssh/1:8.9p1-3ubuntu0.10
Ubuntu Security Notice USN-6859-1
July 01, 2024
openssh vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 24.04 LTS
- Ubuntu 23.10
- Ubuntu 22.04 LTS
Summary:
OpenSSH could be made to bypass authentication and remotely
access systems without proper credentials.
Software Description:
- openssh: secure shell (SSH) for secure access to remote machines
Details:
It was discovered that OpenSSH incorrectly handled signal management. A
remote attacker could use this issue to bypass authentication and remotely
access systems without proper credentials.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 24.04 LTS
openssh-client 1:9.6p1-3ubuntu13.3
openssh-server 1:9.6p1-3ubuntu13.3
Ubuntu 23.10
openssh-client 1:9.3p1-1ubuntu3.6
openssh-server 1:9.3p1-1ubuntu3.6
Ubuntu 22.04 LTS
openssh-client 1:8.9p1-3ubuntu0.10
openssh-server 1:8.9p1-3ubuntu0.10
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6859-1
CVE-2024-6387
Package Information:
https://launchpad.net/ubuntu/+source/openssh/1:9.6p1-3ubuntu13.3
https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.6
https://launchpad.net/ubuntu/+source/openssh/1:8.9p1-3ubuntu0.10
FreeBSD Security Advisory FreeBSD-SA-24:04.openssh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-24:04.openssh Security Advisory
The FreeBSD Project
Topic: OpenSSH pre-authentication remote code execution
Category: contrib
Module: openssh
Announced: 2024-07-01
Credits: Qualys Threat Research Unit (TRU)
Affects: All supported versions of FreeBSD.
Corrected: 2024-07-01 08:22:13 UTC (stable/14, 14.1-STABLE)
2024-07-01 08:24:48 UTC (releng/14.1, 14.1-RELEASE-p2)
2024-07-01 08:26:05 UTC (releng/14.0, 14.0-RELEASE-p8)
2024-07-01 08:23:16 UTC (stable/13, 13.3-STABLE)
2024-07-01 08:27:10 UTC (releng/13.3, 13.3-RELEASE-p4)
2024-07-01 08:27:53 UTC (releng/13.2, 13.2-RELEASE-p12)
CVE Name: CVE-2024-6387
Note: Due to the fact this advisory is being released the day after
13.2-RELEASE is going out of support, the Security Team has decided to
include 13.2-RELEASE in the response for this issue.
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
I. Background
OpenSSH is an implementation of the SSH protocol suite, providing an
encrypted and authenticated transport for a variety of services, including
remote shell access.
II. Problem Description
A signal handler in sshd(8) calls a function that is not async-signal-safe.
The signal handler is invoked when a client does not authenticate within the
LoginGraceTime seconds (120 by default). This signal handler executes in the
context of the sshd(8)'s privileged code, which is not sandboxed and runs
with full root privileges.
This issue is a regression of CVE-2006-5051 originally reported by Mark Dowd
and accidentally reintroduced in OpenSSH 8.5p1.
III. Impact
As a result of calling functions that are not async-signal-safe in the
privileged sshd(8) context, a race condition exists that a determined
attacker may be able to exploit to allow an unauthenticated remote code
execution as root.
IV. Workaround
If sshd(8) cannot be updated, this signal handler race condition can be
mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and
restarting sshd(8). This makes sshd(8) vulnerable to a denial of service
(the exhaustion of all MaxStartups connections), but makes it safe from the
remote code execution presented in this advisory.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Perform one of the following:
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms,
or the i386 platform on FreeBSD 13, can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
# service sshd restart
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 14.1]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.1.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.1.patch.asc
# gpg --verify openssh-14.1.patch.asc
[FreeBSD 14.0]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.0.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.0.patch.asc
# gpg --verify openssh-14.0.patch.asc
[FreeBSD 13.3]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.3.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.3.patch.asc
# gpg --verify openssh-13.3.patch.asc
[FreeBSD 13.2]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.2.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.2.patch.asc
# gpg --verify openssh-13.2.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 the applicable daemons, or reboot the system.
VI. Correction details
This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:
Branch/path Hash Revision
- -------------------------------------------------------------------------
stable/14/ 620a6a54bb7b stable/14-n268045
releng/14.1/ 8f80def8aa08 releng/14.1-n267683
releng/14.0/ 70eb00f17b31 releng/14.0-n265420
stable/13/ 25cf430cd551 stable/13-n258037
releng/13.3/ e3e0912f2977 releng/13.3-n257437
releng/13.2/ 99ad94894edf releng/13.2-n254666
- -------------------------------------------------------------------------
Run the following command to see which files were modified by a
particular commit:
# git show --stat <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
VII. References
<URL:https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt>
<URL:https://www.cve.org/CVERecord?id=CVE-2006-5051>
<URL:https://www.cve.org/CVERecord?id=CVE-2024-6387>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-24:04.openssh.asc>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmaCa5QACgkQbljekB8A
Gu8E9hAA2tYE3vcgDNMnsy9Rw5CR8uJWkCAPk4Pd1RvJlYlCFmC4XASukA6DHdv5
Zym13OwC7wO3ak4u819y052Iia7fOCzkdg/MWODvao3v8BOjXcOZjtSCgCsh50Om
NNStF5Bhl4l7FwggZqYgo5+6XafjzjU4NbdiCH4Y4qN8VkQwCoHLozfl7X6/XwyE
0LRCL9IzS2lpoqsMvOBOYkS1U1/arEsjWrY0XrDtA30r1zGkkZQ2DKLPWhxGM2wR
/ImPpWiINxfVq0u55ubZCm9g3JqnXJVBQ41wo44wdW4R98WabvqQgKDLfxwMlhTc
rKlg/JARehrYpPC1d0+PN2RaQUkAucjlxSFjnb3UOt0o0w3FqWB03u9IB7Q7PFya
O7S4+WNyEJZiex9Ef1C/ea3ewfx9AMfaWYj+t2yYZjy5oXgZHk4EpoWsOqNDgmC7
bOlFMPeMoxczXkjqiCmsrODho3w8oEo/I111ovo8Sc6tS+13/Tioy9ZSrgdpIVrV
DGItqasOXmVaHdatkY/DJ6f2buWlpZ3GTadAB5R+sixe/t3s583jV1Hktjb5NY4M
N8y+TEpf5wf/yn9Z/Ub52JQPQDy1qAwICjWPpdYXligYFMV2vy4XZCptnldttz3y
gz+2coOund99MGmxpyAm6NVtpVvVpRfjeVFbcqmzxF+35qXsl8w=
=Zcol
-----END PGP SIGNATURE-----
Hash: SHA512
=============================================================================
FreeBSD-SA-24:04.openssh Security Advisory
The FreeBSD Project
Topic: OpenSSH pre-authentication remote code execution
Category: contrib
Module: openssh
Announced: 2024-07-01
Credits: Qualys Threat Research Unit (TRU)
Affects: All supported versions of FreeBSD.
Corrected: 2024-07-01 08:22:13 UTC (stable/14, 14.1-STABLE)
2024-07-01 08:24:48 UTC (releng/14.1, 14.1-RELEASE-p2)
2024-07-01 08:26:05 UTC (releng/14.0, 14.0-RELEASE-p8)
2024-07-01 08:23:16 UTC (stable/13, 13.3-STABLE)
2024-07-01 08:27:10 UTC (releng/13.3, 13.3-RELEASE-p4)
2024-07-01 08:27:53 UTC (releng/13.2, 13.2-RELEASE-p12)
CVE Name: CVE-2024-6387
Note: Due to the fact this advisory is being released the day after
13.2-RELEASE is going out of support, the Security Team has decided to
include 13.2-RELEASE in the response for this issue.
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.
I. Background
OpenSSH is an implementation of the SSH protocol suite, providing an
encrypted and authenticated transport for a variety of services, including
remote shell access.
II. Problem Description
A signal handler in sshd(8) calls a function that is not async-signal-safe.
The signal handler is invoked when a client does not authenticate within the
LoginGraceTime seconds (120 by default). This signal handler executes in the
context of the sshd(8)'s privileged code, which is not sandboxed and runs
with full root privileges.
This issue is a regression of CVE-2006-5051 originally reported by Mark Dowd
and accidentally reintroduced in OpenSSH 8.5p1.
III. Impact
As a result of calling functions that are not async-signal-safe in the
privileged sshd(8) context, a race condition exists that a determined
attacker may be able to exploit to allow an unauthenticated remote code
execution as root.
IV. Workaround
If sshd(8) cannot be updated, this signal handler race condition can be
mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and
restarting sshd(8). This makes sshd(8) vulnerable to a denial of service
(the exhaustion of all MaxStartups connections), but makes it safe from the
remote code execution presented in this advisory.
V. Solution
Upgrade your vulnerable system to a supported FreeBSD stable or
release / security branch (releng) dated after the correction date.
Perform one of the following:
1) To update your vulnerable system via a binary patch:
Systems running a RELEASE version of FreeBSD on the amd64 or arm64 platforms,
or the i386 platform on FreeBSD 13, can be updated via the freebsd-update(8)
utility:
# freebsd-update fetch
# freebsd-update install
# service sshd restart
2) To update your vulnerable system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 14.1]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.1.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.1.patch.asc
# gpg --verify openssh-14.1.patch.asc
[FreeBSD 14.0]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.0.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-14.0.patch.asc
# gpg --verify openssh-14.0.patch.asc
[FreeBSD 13.3]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.3.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.3.patch.asc
# gpg --verify openssh-13.3.patch.asc
[FreeBSD 13.2]
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.2.patch
# fetch https://security.FreeBSD.org/patches/SA-24:04/openssh-13.2.patch.asc
# gpg --verify openssh-13.2.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 the applicable daemons, or reboot the system.
VI. Correction details
This issue is corrected as of the corresponding Git commit hash in the
following stable and release branches:
Branch/path Hash Revision
- -------------------------------------------------------------------------
stable/14/ 620a6a54bb7b stable/14-n268045
releng/14.1/ 8f80def8aa08 releng/14.1-n267683
releng/14.0/ 70eb00f17b31 releng/14.0-n265420
stable/13/ 25cf430cd551 stable/13-n258037
releng/13.3/ e3e0912f2977 releng/13.3-n257437
releng/13.2/ 99ad94894edf releng/13.2-n254666
- -------------------------------------------------------------------------
Run the following command to see which files were modified by a
particular commit:
# git show --stat <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
VII. References
<URL:https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt>
<URL:https://www.cve.org/CVERecord?id=CVE-2006-5051>
<URL:https://www.cve.org/CVERecord?id=CVE-2024-6387>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-24:04.openssh.asc>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmaCa5QACgkQbljekB8A
Gu8E9hAA2tYE3vcgDNMnsy9Rw5CR8uJWkCAPk4Pd1RvJlYlCFmC4XASukA6DHdv5
Zym13OwC7wO3ak4u819y052Iia7fOCzkdg/MWODvao3v8BOjXcOZjtSCgCsh50Om
NNStF5Bhl4l7FwggZqYgo5+6XafjzjU4NbdiCH4Y4qN8VkQwCoHLozfl7X6/XwyE
0LRCL9IzS2lpoqsMvOBOYkS1U1/arEsjWrY0XrDtA30r1zGkkZQ2DKLPWhxGM2wR
/ImPpWiINxfVq0u55ubZCm9g3JqnXJVBQ41wo44wdW4R98WabvqQgKDLfxwMlhTc
rKlg/JARehrYpPC1d0+PN2RaQUkAucjlxSFjnb3UOt0o0w3FqWB03u9IB7Q7PFya
O7S4+WNyEJZiex9Ef1C/ea3ewfx9AMfaWYj+t2yYZjy5oXgZHk4EpoWsOqNDgmC7
bOlFMPeMoxczXkjqiCmsrODho3w8oEo/I111ovo8Sc6tS+13/Tioy9ZSrgdpIVrV
DGItqasOXmVaHdatkY/DJ6f2buWlpZ3GTadAB5R+sixe/t3s583jV1Hktjb5NY4M
N8y+TEpf5wf/yn9Z/Ub52JQPQDy1qAwICjWPpdYXligYFMV2vy4XZCptnldttz3y
gz+2coOund99MGmxpyAm6NVtpVvVpRfjeVFbcqmzxF+35qXsl8w=
=Zcol
-----END PGP SIGNATURE-----
[USN-6858-1] eSpeak NG vulnerabilities
==========================================================================
Ubuntu Security Notice USN-6858-1
July 01, 2024
espeak-ng vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 23.10
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in eSpeak NG.
Software Description:
- espeak-ng: Multi-lingual software speech synthesizer
Details:
It was discovered that eSpeak NG did not properly manage memory under certain
circumstances. An attacker could possibly use this issue to cause a denial
of service, or execute arbitrary code. (CVE-2023-49990, CVE-2023-49991,
CVE-2023-49992, CVE-2023-49993, CVE-2023-49994)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 23.10
espeak-ng 1.51+dfsg-11ubuntu0.1
espeak-ng-espeak 1.51+dfsg-11ubuntu0.1
Ubuntu 22.04 LTS
espeak-ng 1.50+dfsg-10ubuntu0.1
espeak-ng-espeak 1.50+dfsg-10ubuntu0.1
Ubuntu 20.04 LTS
espeak-ng 1.50+dfsg-6ubuntu0.1
espeak-ng-espeak 1.50+dfsg-6ubuntu0.1
Ubuntu 18.04 LTS
espeak-ng 1.49.2+dfsg-1ubuntu0.1~esm1
Available with Ubuntu Pro
espeak-ng-espeak 1.49.2+dfsg-1ubuntu0.1~esm1
Available with Ubuntu Pro
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6858-1
CVE-2023-49990, CVE-2023-49991, CVE-2023-49992, CVE-2023-49993,
CVE-2023-49994
Package Information:
https://launchpad.net/ubuntu/+source/espeak-ng/1.51+dfsg-11ubuntu0.1
https://launchpad.net/ubuntu/+source/espeak-ng/1.50+dfsg-10ubuntu0.1
https://launchpad.net/ubuntu/+source/espeak-ng/1.50+dfsg-6ubuntu0.1
Ubuntu Security Notice USN-6858-1
July 01, 2024
espeak-ng vulnerabilities
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 23.10
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
Summary:
Several security issues were fixed in eSpeak NG.
Software Description:
- espeak-ng: Multi-lingual software speech synthesizer
Details:
It was discovered that eSpeak NG did not properly manage memory under certain
circumstances. An attacker could possibly use this issue to cause a denial
of service, or execute arbitrary code. (CVE-2023-49990, CVE-2023-49991,
CVE-2023-49992, CVE-2023-49993, CVE-2023-49994)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 23.10
espeak-ng 1.51+dfsg-11ubuntu0.1
espeak-ng-espeak 1.51+dfsg-11ubuntu0.1
Ubuntu 22.04 LTS
espeak-ng 1.50+dfsg-10ubuntu0.1
espeak-ng-espeak 1.50+dfsg-10ubuntu0.1
Ubuntu 20.04 LTS
espeak-ng 1.50+dfsg-6ubuntu0.1
espeak-ng-espeak 1.50+dfsg-6ubuntu0.1
Ubuntu 18.04 LTS
espeak-ng 1.49.2+dfsg-1ubuntu0.1~esm1
Available with Ubuntu Pro
espeak-ng-espeak 1.49.2+dfsg-1ubuntu0.1~esm1
Available with Ubuntu Pro
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6858-1
CVE-2023-49990, CVE-2023-49991, CVE-2023-49992, CVE-2023-49993,
CVE-2023-49994
Package Information:
https://launchpad.net/ubuntu/+source/espeak-ng/1.51+dfsg-11ubuntu0.1
https://launchpad.net/ubuntu/+source/espeak-ng/1.50+dfsg-10ubuntu0.1
https://launchpad.net/ubuntu/+source/espeak-ng/1.50+dfsg-6ubuntu0.1
Sunday, June 30, 2024
Scientific Linux 7 end of life
Hello,
Following the upstream release cycle:
Scientific Linux 7 reached End of Life June 30, 2024.
After this date no additional updates will be published for Scientific Linux 7.
Specifically, no security updates for SL7 will be published after June 30, 2024.
After June 30 2024:
- The installation trees will be moved into the 'obsolete' directory.
- Kickstart and yum operations against the old repository locations will no longer work.
- the official docker images for SL7 (docker pull sl:7) will be retired
-- A copy of the final docker image will be placed in the 'obsolete' directory.
The files themselves will remain available under the 'obsolete' directory.[1]
Users of Scientific Linux 7 should evaluate options for migrating to an actively maintained operating system.
Fermilab recommends Almalinux[2] at this time.
CentOS Stream[3] is also available.
[1] http://ftp.scientificlinux.org/linux/scientific/obsolete/
[USN-6855-1] libcdio vulnerability
-----BEGIN PGP PUBLIC KEY BLOCK-----
xsDNBGYvHjQBDADOi4xF8D69+cDdNMpjhdrWL3Hs7cRLXj2+aOPuMJXBw+dKUeOJ
eLHWnU+yhzQAJTVMSO/cYSzbJSkSF45dSnAIwYU9A501PWv786NEBNNe76y7B8Nm
PTQlRHdet678wzNNvIPCF/Ovll1dmRwh6OBvuSGrjhAITv3F6fDYyP2GE9lfDYyr
aMvG6HxkUZF5mAOB8N0AkVQaiIVLNOXHeKcpznw0G0uW3LtMMQWlm/VPLnaAwehK
0xHW6iK9ou5t5pWYJHoLRWbLTqUHDa9wvDaW+UGMsReVymXRJApHmS/li16TOaJN
w5xyz2NZ30f8FEstdTPo3OmZGcOSqztaqJAKn2tePDTnGXr/yj6wognQGZzXMcRi
uyyN+8j98u1pGwIVnxBQuq+lvpnC6acLvGjrp7F8g5zj6yeYGPJoR1Zp4eP7vbim
KhwK5tQxyoN0b5jP+PdGRQ3AwCBIGVSMRx58JTrPTdmfbVTswlVx+Zc4SeMY9PkO
t8PYsDZR+op2mK0AEQEAAc0nQnJ1Y2UgQ2FibGUgPGJydWNlLmNhYmxlQGNhbm9u
aWNhbC5jb20+wsEOBBMBCgA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE
kd98mdFcnQdP7vQkuGrtzot7pOcFAmYvIIEACgkQuGrtzot7pOetwwv9F4wYw/6x
ZEAp0Vu5F8QlO1rKzEM2eI7Hle/YUEglOdEkKKgtOIrTFlGNIAovVrG/tR8iIdyb
JpEKZoD8e7Vq4wUDNMMTdmrDcetVIHJHCE6ZsFNTXuETss2oKZWPlYAWu9WKK/a3
CukscfORCuR7dVMXOSQ/B9MIt4KabfqOZo6Quh79HHLBNku4FfDlAoiBbG7jEir+
P8QgcJXG8PXjZC4TeVlY4nzGvecr/HVZuuX31GKjqvNRFgohWNYEveDy9zbdkqSf
OgpPHM5E3AAsZUNplo6iIWpxsJ8CyaO9kCNpAQko4rohmYp/VdC/PjaINZKqYT2w
RcZBhsaz8UnZ/frmPTQI8vYOMjhrJx+/t6j1U4hPc1IxeZONoe/vwPlFeR3tpJTC
Ve9uBEGDHZ4peg7wYq6soBaywPZtfhv+vdYfAjJ2W5Ve1xdWXn/Ni3t2Jj0zKOp1
EskzVYobpty3eAoW6BHL1YTin+1BRyt0fB0NoK956UNvQ0EHMm4+n2d2wsEUBBMB
CgA+FiEEkd98mdFcnQdP7vQkuGrtzot7pOcFAmYvHjQCGwMFCQPCZwAFCwkIBwIG
FQoJCAsCBBYCAwECHgECF4AACgkQuGrtzot7pOch/gv6A/IpwNg2u8tHVshl6skL
jdg+ZbN1iXjEWl/yZhPInPni0N3j+uYXO5WcbcnzHCABwl23CEXONDqK56YSFA3w
CriafqM60+8T0rhtE7V1ZDTnlscYWngW135EbPjTMV97UPAzGNJFxQABcNze3Ol3
Gfzqi8PM4dua+rBhuc7frLPGMnr6Uh0dK+48zkR7A3S4FpPodW9Lrx+3p1D4msF+
fCVqiXJAgNZ+4+4DLvw/Z0TqAfq8+p1U5ZPQghmY5t7Eb/ohqmMAHvfwt0ydqTb6
dPQFDftoS5X8k+bq3K2jcjjiXKpnfr2enUtLyC542bXWNcPd0plYYzrU4NI/jLsa
+65eMsJL+jMonB03lvbKcAmJriwsz8ptJPzOeRF+7XYYmgO7qg3FFTcxiomhPKSH
Fm+NAWzxTmHLzNQ93Y+3qSiQ0JGHs3M/68Juzl88qFhOqVUPZkd0q/fQpWWE/DU2
qDIpTJB/EOzrVjlgp9qTGJV1skGtW40nvhhpRhR/njz6zsDNBGYvHjQBDADGlkFl
ersL/tg3bhamgmyYg89KXwxILy7k74KtWQ/dufAf8M11q4y0BpzMu00nTRC0M5NH
nMSqZcvwz+iWvNDc5SiL4OwNg8YKU/3oGmCLBKDpWzXvBhLkGw8L94CLRakU358P
QCtmmPMdYVQ/HBJoxFhnzDPxe9ioPUm/sFaRHswCK/0hJ0q7LUz8w2D6gy+3SDcy
/9MaHTVRarGSVCeShz7qwAg/1dLTFosgxrb4fEKlldlbO97AM+GCpgt1Jew5e88Y
LEWP59/h6kDTQrPddUBO7hVNbly3Pxc8eL9b3iQ1wRJxBNrJ0hlGE4nBw6tVmUjc
vpngQHJ8ZmxQnVs3oVvZESFu6JPoqgNS8VhEAI6EnEOFFm5HL9uDL71fmacAWRrm
9gh1qsMByVvB6pOpeWSQPRicrgAAMcZP+COYl6uqwc2VCKL9NxahrjPjecSUHoEc
78tnVkHrOJiyUa4Xu1AJgeLuwhFnGbgF3SJ4/8/rrYoHScIS9+yKmYzHYDcAEQEA
AcLA/AQYAQoAJhYhBJHffJnRXJ0HT+70JLhq7c6Le6TnBQJmLx40AhsMBQkDwmcA
AAoJELhq7c6Le6Tn/0YL/3u59UilxpTpYCc24LevE7/2RgDHjxG+2TSPs+0G7jN5
wruyvRWOVahZ/N+XW2QLuOUimuYcRtDlAwwd/nsz8OMvVZ++NcFgKJNLUJOqe7Fn
t1oYtTUx9JX7E4j5+SZgG5ORWc4YfLx9hKRxfxZuKOjYrAjPn3f21TppQyhc/mt7
7afVn5tWGGAtV1LTf+qg8JZYLDk6/uz60QFmLga5/r5JDYsrZ9tLrlKymBL2CvJA
B80PAmY7BG0xcJPBU92rU/vj1qEBkQq6tV9dJMmf8u3j3PXVMQTvlm83INjr71lt
bzA/Wy6jHoW1xUWzDb6RKHpfLu87QJ9JMNe/A7eK3xWIwe9aDaQv1pftZ1p3DYau
4xZW0n/FI+30ZxH3W1dTuR2nodEPZIUtD2y8iZyQYie1Ru02rTnw364h/dAB2o7P
MGn/BTYQXiui5WHdgd4e8zAYTC8OSAVw5qjh42UIMltpCX5dli5blaM0lK70x2xe
24qugAHoDe4CIMOsmvXvEw==
=NMey
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
wsD5BAABCAAjFiEEkd98mdFcnQdP7vQkuGrtzot7pOcFAmaCD7gFAwAAAAAACgkQuGrtzot7pOcy
Owv8COu0EKBcx3bZFBnE00FTKgAFfqAk0tG3SHHWbT1Aj0wkLxN1M+VvkSvtdvnqF5lIP1FG/tGZ
5uWRMXZFoMwKnJWVP7r+fLuNqcsOyO7HyPk6U08HMc3jLv+C5EPqWViEZd0LlgajD8HIuKg7Hlxv
8QRTJQ+LGW+Uhq16bOWS1ICPmPENw4nXDOYrcX4kPXgj5t8ETx3igWXuLumFfHCS2i3N98KE/fLw
mooi1Mku9PxgMPep8CXqG5OJhkuHq4A/tW3oplIjHRarK1/K14xeKQkvfi8ija0S0J5GYJ5qJLh+
/Icw0Er1ISzwBlyq4Tj4xq9Akg7aeK/q3kKfZWMwrNO9BGicOmqYNE9icuEjTNczyhIXeksqZ5kj
q42E7AYh5Q2x506Vy9AtJioiG2x5i98qaU0KXLg93JdR/GlF2gVrnEcOHS0NfmLs+FBQx5U2RGlF
WQvcia611xtDbBVwJ6AzaKsQkwIiaHCjunz0xOELgvxQ90/bEsvsCrFJML5l
=jnBi
-----END PGP SIGNATURE-----
xsDNBGYvHjQBDADOi4xF8D69+cDdNMpjhdrWL3Hs7cRLXj2+aOPuMJXBw+dKUeOJ
eLHWnU+yhzQAJTVMSO/cYSzbJSkSF45dSnAIwYU9A501PWv786NEBNNe76y7B8Nm
PTQlRHdet678wzNNvIPCF/Ovll1dmRwh6OBvuSGrjhAITv3F6fDYyP2GE9lfDYyr
aMvG6HxkUZF5mAOB8N0AkVQaiIVLNOXHeKcpznw0G0uW3LtMMQWlm/VPLnaAwehK
0xHW6iK9ou5t5pWYJHoLRWbLTqUHDa9wvDaW+UGMsReVymXRJApHmS/li16TOaJN
w5xyz2NZ30f8FEstdTPo3OmZGcOSqztaqJAKn2tePDTnGXr/yj6wognQGZzXMcRi
uyyN+8j98u1pGwIVnxBQuq+lvpnC6acLvGjrp7F8g5zj6yeYGPJoR1Zp4eP7vbim
KhwK5tQxyoN0b5jP+PdGRQ3AwCBIGVSMRx58JTrPTdmfbVTswlVx+Zc4SeMY9PkO
t8PYsDZR+op2mK0AEQEAAc0nQnJ1Y2UgQ2FibGUgPGJydWNlLmNhYmxlQGNhbm9u
aWNhbC5jb20+wsEOBBMBCgA4AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE
kd98mdFcnQdP7vQkuGrtzot7pOcFAmYvIIEACgkQuGrtzot7pOetwwv9F4wYw/6x
ZEAp0Vu5F8QlO1rKzEM2eI7Hle/YUEglOdEkKKgtOIrTFlGNIAovVrG/tR8iIdyb
JpEKZoD8e7Vq4wUDNMMTdmrDcetVIHJHCE6ZsFNTXuETss2oKZWPlYAWu9WKK/a3
CukscfORCuR7dVMXOSQ/B9MIt4KabfqOZo6Quh79HHLBNku4FfDlAoiBbG7jEir+
P8QgcJXG8PXjZC4TeVlY4nzGvecr/HVZuuX31GKjqvNRFgohWNYEveDy9zbdkqSf
OgpPHM5E3AAsZUNplo6iIWpxsJ8CyaO9kCNpAQko4rohmYp/VdC/PjaINZKqYT2w
RcZBhsaz8UnZ/frmPTQI8vYOMjhrJx+/t6j1U4hPc1IxeZONoe/vwPlFeR3tpJTC
Ve9uBEGDHZ4peg7wYq6soBaywPZtfhv+vdYfAjJ2W5Ve1xdWXn/Ni3t2Jj0zKOp1
EskzVYobpty3eAoW6BHL1YTin+1BRyt0fB0NoK956UNvQ0EHMm4+n2d2wsEUBBMB
CgA+FiEEkd98mdFcnQdP7vQkuGrtzot7pOcFAmYvHjQCGwMFCQPCZwAFCwkIBwIG
FQoJCAsCBBYCAwECHgECF4AACgkQuGrtzot7pOch/gv6A/IpwNg2u8tHVshl6skL
jdg+ZbN1iXjEWl/yZhPInPni0N3j+uYXO5WcbcnzHCABwl23CEXONDqK56YSFA3w
CriafqM60+8T0rhtE7V1ZDTnlscYWngW135EbPjTMV97UPAzGNJFxQABcNze3Ol3
Gfzqi8PM4dua+rBhuc7frLPGMnr6Uh0dK+48zkR7A3S4FpPodW9Lrx+3p1D4msF+
fCVqiXJAgNZ+4+4DLvw/Z0TqAfq8+p1U5ZPQghmY5t7Eb/ohqmMAHvfwt0ydqTb6
dPQFDftoS5X8k+bq3K2jcjjiXKpnfr2enUtLyC542bXWNcPd0plYYzrU4NI/jLsa
+65eMsJL+jMonB03lvbKcAmJriwsz8ptJPzOeRF+7XYYmgO7qg3FFTcxiomhPKSH
Fm+NAWzxTmHLzNQ93Y+3qSiQ0JGHs3M/68Juzl88qFhOqVUPZkd0q/fQpWWE/DU2
qDIpTJB/EOzrVjlgp9qTGJV1skGtW40nvhhpRhR/njz6zsDNBGYvHjQBDADGlkFl
ersL/tg3bhamgmyYg89KXwxILy7k74KtWQ/dufAf8M11q4y0BpzMu00nTRC0M5NH
nMSqZcvwz+iWvNDc5SiL4OwNg8YKU/3oGmCLBKDpWzXvBhLkGw8L94CLRakU358P
QCtmmPMdYVQ/HBJoxFhnzDPxe9ioPUm/sFaRHswCK/0hJ0q7LUz8w2D6gy+3SDcy
/9MaHTVRarGSVCeShz7qwAg/1dLTFosgxrb4fEKlldlbO97AM+GCpgt1Jew5e88Y
LEWP59/h6kDTQrPddUBO7hVNbly3Pxc8eL9b3iQ1wRJxBNrJ0hlGE4nBw6tVmUjc
vpngQHJ8ZmxQnVs3oVvZESFu6JPoqgNS8VhEAI6EnEOFFm5HL9uDL71fmacAWRrm
9gh1qsMByVvB6pOpeWSQPRicrgAAMcZP+COYl6uqwc2VCKL9NxahrjPjecSUHoEc
78tnVkHrOJiyUa4Xu1AJgeLuwhFnGbgF3SJ4/8/rrYoHScIS9+yKmYzHYDcAEQEA
AcLA/AQYAQoAJhYhBJHffJnRXJ0HT+70JLhq7c6Le6TnBQJmLx40AhsMBQkDwmcA
AAoJELhq7c6Le6Tn/0YL/3u59UilxpTpYCc24LevE7/2RgDHjxG+2TSPs+0G7jN5
wruyvRWOVahZ/N+XW2QLuOUimuYcRtDlAwwd/nsz8OMvVZ++NcFgKJNLUJOqe7Fn
t1oYtTUx9JX7E4j5+SZgG5ORWc4YfLx9hKRxfxZuKOjYrAjPn3f21TppQyhc/mt7
7afVn5tWGGAtV1LTf+qg8JZYLDk6/uz60QFmLga5/r5JDYsrZ9tLrlKymBL2CvJA
B80PAmY7BG0xcJPBU92rU/vj1qEBkQq6tV9dJMmf8u3j3PXVMQTvlm83INjr71lt
bzA/Wy6jHoW1xUWzDb6RKHpfLu87QJ9JMNe/A7eK3xWIwe9aDaQv1pftZ1p3DYau
4xZW0n/FI+30ZxH3W1dTuR2nodEPZIUtD2y8iZyQYie1Ru02rTnw364h/dAB2o7P
MGn/BTYQXiui5WHdgd4e8zAYTC8OSAVw5qjh42UIMltpCX5dli5blaM0lK70x2xe
24qugAHoDe4CIMOsmvXvEw==
=NMey
-----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
wsD5BAABCAAjFiEEkd98mdFcnQdP7vQkuGrtzot7pOcFAmaCD7gFAwAAAAAACgkQuGrtzot7pOcy
Owv8COu0EKBcx3bZFBnE00FTKgAFfqAk0tG3SHHWbT1Aj0wkLxN1M+VvkSvtdvnqF5lIP1FG/tGZ
5uWRMXZFoMwKnJWVP7r+fLuNqcsOyO7HyPk6U08HMc3jLv+C5EPqWViEZd0LlgajD8HIuKg7Hlxv
8QRTJQ+LGW+Uhq16bOWS1ICPmPENw4nXDOYrcX4kPXgj5t8ETx3igWXuLumFfHCS2i3N98KE/fLw
mooi1Mku9PxgMPep8CXqG5OJhkuHq4A/tW3oplIjHRarK1/K14xeKQkvfi8ija0S0J5GYJ5qJLh+
/Icw0Er1ISzwBlyq4Tj4xq9Akg7aeK/q3kKfZWMwrNO9BGicOmqYNE9icuEjTNczyhIXeksqZ5kj
q42E7AYh5Q2x506Vy9AtJioiG2x5i98qaU0KXLg93JdR/GlF2gVrnEcOHS0NfmLs+FBQx5U2RGlF
WQvcia611xtDbBVwJ6AzaKsQkwIiaHCjunz0xOELgvxQ90/bEsvsCrFJML5l
=jnBi
-----END PGP SIGNATURE-----
========================================================================== Ubuntu Security Notice USN-6855-1 June 28, 2024 libcdio vulnerability ========================================================================== A security issue affects these releases of Ubuntu and its derivatives: - Ubuntu 24.04 LTS - Ubuntu 23.10 - Ubuntu 22.04 LTS - Ubuntu 20.04 LTS - Ubuntu 18.04 LTS - Ubuntu 16.04 LTS - Ubuntu 14.04 LTS Summary: libcdio could be made to crash or run programs as your login if it opened a specially crafted file. Software Description: - libcdio: C++ library to read and control CD-ROM (development files) Details: Mansour Gashasbi discovered that libcdio incorrectly handled certain memory operations when parsing an ISO file, leading to a buffer overflow vulnerability. An attacker could use this to cause a denial of service or possibly execute arbitrary code. Update instructions: The problem can be corrected by updating your system to the following package versions: Ubuntu 24.04 LTS libcdio++1t64 2.1.0-4.1ubuntu1.2 libcdio19t64 2.1.0-4.1ubuntu1.2 libiso9660++0t64 2.1.0-4.1ubuntu1.2 libiso9660-11t64 2.1.0-4.1ubuntu1.2 libudf0t64 2.1.0-4.1ubuntu1.2 Ubuntu 23.10 libcdio++1 2.1.0-4ubuntu0.2 libcdio19 2.1.0-4ubuntu0.2 libiso9660++0 2.1.0-4ubuntu0.2 libiso9660-11 2.1.0-4ubuntu0.2 libudf0 2.1.0-4ubuntu0.2 Ubuntu 22.04 LTS libcdio++1 2.1.0-3ubuntu0.2 libcdio19 2.1.0-3ubuntu0.2 libiso9660++0 2.1.0-3ubuntu0.2 libiso9660-11 2.1.0-3ubuntu0.2 libudf0 2.1.0-3ubuntu0.2 Ubuntu 20.04 LTS libcdio18 2.0.0-2ubuntu0.2 libiso9660-11 2.0.0-2ubuntu0.2 libudf0 2.0.0-2ubuntu0.2 Ubuntu 18.04 LTS libcdio17 1.0.0-2ubuntu2+esm2 Available with Ubuntu Pro libiso9660-10 1.0.0-2ubuntu2+esm2 Available with Ubuntu Pro libudf0 1.0.0-2ubuntu2+esm2 Available with Ubuntu Pro Ubuntu 16.04 LTS libcdio13 0.83-4.2ubuntu1+esm3 Available with Ubuntu Pro libiso9660-8 0.83-4.2ubuntu1+esm3 Available with Ubuntu Pro libudf0 0.83-4.2ubuntu1+esm3 Available with Ubuntu Pro Ubuntu 14.04 LTS libcdio13 0.83-4.1ubuntu1+esm3 Available with Ubuntu Pro libiso9660-8 0.83-4.1ubuntu1+esm3 Available with Ubuntu Pro libudf0 0.83-4.1ubuntu1+esm3 Available with Ubuntu Pro In general, a standard system update will make all the necessary changes. References: https://ubuntu.com/security/notices/USN-6855-1 CVE-2024-36600 Package Information: https://launchpad.net/ubuntu/+source/libcdio/2.1.0-4.1ubuntu1.2 https://launchpad.net/ubuntu/+source/libcdio/2.1.0-4ubuntu0.2 https://launchpad.net/ubuntu/+source/libcdio/2.1.0-3ubuntu0.2 https://launchpad.net/ubuntu/+source/libcdio/2.0.0-2ubuntu0.2
Subscribe to:
Posts (Atom)