F37 proposal: Erlang 25 (Self-Contained Change proposal)

https://fedoraproject.org/wiki/Changes/Erlang_25

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 ==
Update Erlang/OTP to version 25.

== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemenkov@gmail.com, erlang@lists.fedoraproject.org,
bowlofeggs@fedoraproject.org, jcline@fedoraproject.org


== Detailed Description ==
Upgrade Erlang to version 25 which brings a lot of changes. Just a few
highlights [https://www.erlang.org/blog/my-otp-25-highlights/ from
many]:

* [https://www.erlang.org/blog/parallel-signal-sending-optimization/
The Many-to-One Parallel Signal Sending Optimization].
* [https://www.erlang.org/blog/type-based-optimizations-in-the-jit/
Type-Based Optimizations in the JIT].
* New 'maybe' operator.
* The JIT now supports the AArch64 (ARM64) architecture.
* Better support for perf and gdb.
* Better error reporting in some cases.


Aside from this, we plan to further improve quality of Erlang and
related packages. These are shortcomings we want to address:

* Finish switching to rebar3 as a main build tool and deprecate rebar2.
** Improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]] according to this switch and promote it as the official
guideline.
* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to unified logger.
* We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus
erlang-dbus] library or any other recent implementations..
* SELinux rules for main Erlang applications (Ejabberd, CouchDB,
RabbitMQ) are still outdated or missing.

== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:

* Improved scalability and robustness.
* Much easier developing and debugging.

== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/show_bug.cgi?id=2055490 Upgrade Erlang
to the latest version (25.0)].
** Every Erlang daemon's systemd unit should require epmd.socket.
** Upgrade outdated packages:
*** {{package|riak|Riak}}
**** {{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
**** {{package|riak|CouchDB}} has has been retired. We have to re-add it back.
** {{package|erlang-rebar3|rebar3}}
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Binaries compiled with Erlang 22 and older are no longer compatible.

== How To Test ==

* Ensure that high-grade Erlang applications are still working:
{| border="1"
|-
| '''Name''' || '''Tested'''
|-
| {{package|couchdb}} || {{no}} (package was retired :( )
|-
| {{package|ejabberd}} || {{no}}
|-
| {{package|elixir}} || {{no}}
|-
| {{package|rabbitmq-server}} || {{no}}
|-
| {{package|riak}} || {{no}} (package was retired :( )
|-
| {{package|wings}} || {{no}}
|}

* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version

== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.

== Dependencies ==

The following packages must be rebuilt: NIF-libraries.

== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]],
[[Changes/Erlang_22|Erlang 22]], [[Changes/Erlang_23|Erlang 23]], and
[[Changes/Erlang_24|Erlang 24]]). It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A

== Documentation ==
* [https://www.erlang.org/news/157 Erlang/OTP 25.0 release notes]

== Release Notes ==

Erlang/OTP 25.0 is available in Fedora 37.


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://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 on the list, report it: https://pagure.io/fedora-infrastructure

Fedora elections voting now open

Voting in the Fedora Linux 36 elections is now open. Go to the
Elections app[1] to cast your vote. Voting closes at 23:59 UTC on
Thursday 16 June. Don't forget to claim your "I Voted" badge when you
cast your ballot. Links to candidate interviews are in the Elections
app and on the Community Blog[2].

[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/f36-elections-voting-now-open/

--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
announce mailing list -- announce@lists.fedoraproject.org
To unsubscribe send an email to 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/announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)

https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image

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 ==
Virtualization has long been a steadily growing use case of Fedora
Server Edition, but it is still time consuming and tedious for the
system administrator to create a Fedora Server VM. Supplementing the
downloads by a KVM VM image remedies the deficiency.

== Owner ==
* Name: [[User:pboy| Peter Boy on behalf of Server WG]]
* Email: pboy@uni-bremen.de


== Detailed Description ==
The creation of the VM disk image, uses the same kickstart files and
installation groups as the standard full installation, except of
course for the hardware-specific items. The image is optimized for
KVM.

That way, the VM resembles a default server installation as closely as possible.

All administrative tools are available reliably from the beginning,
all administrative routines and helps (scripts) can be used in the
same way. All application services work in the identical way.

A default VM installation takes 1-2 minutes instead of about 30 mins.

== Feedback ==
The change proposal is based on an extensive discussion of the server
WG and has become part of its work program. For example, the server
documentation on virtualization has already been significantly
expanded in parallel and will continue to be supplemented and updated
on an ongoing basis. This is a response to the importance of the
topic.


== Benefit to Fedora ==
Significantly improves usability for Fedora Server Edition
administrators when deploying a Fedora Server Edtion VM. It thus makes
Fedora Server Edition more attractive, especially for new users
without extensive experience with Fedora. It thus helps to expand our
user base.

Fedora finally provides an installation path for a Fedora Server VM
that is built entirely on Fedora Resources, subject to Fedora quality
control, and compliant with Fedora principles. Until now, if a system
administrator has to install a VM preferable without the hassles of a
full default installation, we could only recommend third party binary
blob (e.g. virt-builder), which is a violation of our own core
principles. In addition, the third party products do not provide a
'Fedora Server Edition', but their own different concept and vision of
a server, under the name Fedora Server.


== Scope ==
* Proposal owners:
A kickstart file for ImageFactory is completed and locally tested.

* Other developers:
n/a
* Release engineering: [https://pagure.io/releng/issues #10768]
* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Objectives:
n/a

== Upgrade/compatibility impact ==

none

== How To Test ==

Basically, the same test procedures as for the full install apply.

1. Install a Fedora Server Edition including virtualization, follow
the Server documentation

2. Import the Fedora Server disk image following the Server
documentation (staging), either using Cockpit or cli virt-install

3. Use the VM with your intendend server applications.

== User Experience ==

Users (system administrators) will have a VM install method available,
which saves them a lot of time and efforts.

== Dependencies ==

none



== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No


== Documentation ==

N/A (not a System Wide Change)

Fedora Server documentation is available.

== Release Notes ==

TBD


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://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 on the list, report it: https://pagure.io/fedora-infrastructure

F37 proposal: LLVM 15 (Self-Contained Change proposal)

https://fedoraproject.org/wiki/Changes/LLVM-15

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 ==
Update all llvm sub-projects in Fedora Linux to version 15.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar@redhat.com>


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 15, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang14 and llvm14 will be added to ensure that
packages that currently depend on clang and llvm version 14 libraries
will continue to work.


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build release candidates into @fedora-llvm-team/llvm15 COPR.
** Build final release (Sep 2022) into Rawhide and F37 branches.

* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang14 and llvm14
compatibility packages if they want to rebuild their package and it
does not work with LLVM 15 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
15 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.

* Release engineering: [https://pagure.io/releng/issues/10820 #10820]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
This change should not impact upgradeability.


== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
15.


== User Experience ==


== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 14 will need to
update their spec file on their first rebuild after this change.


== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Contingency
mechanism: (What to do? Who will do it?): If there are major problems
with LLVM 15, the compatibility package provide a way for other
packages to continue using LLVM 14.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 15:

llvm
clang
lld
lldb
compiler-rt
libomp
llvm-test-suite
libcxx
libcxxabi
python-lit
flang
mlir
polly
libclc
llvm-unwind


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://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 on the list, report it: https://pagure.io/fedora-infrastructure

F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags

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 ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar@redhat.com>


== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]

This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.

The proposed macros for adding new flags are:

%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags

These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.

%build_cflags %{optflags} %{_pkg_extra_cflags}

The proposed new macros to represent existing flags are:

%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects -ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions -fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches -grecord-gcc-switches
%_flag_pipe -pipe
%_flag_wall -Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard

With these new macros, the examples from above could be re-written as:

compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}

For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags
Prototype Implementation].

In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.


== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.


== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the correct
flags are still being used.

* Other developers:
** Other developers may, but are not required to, update their
packages to use the new macros.

* Release engineering: [https://pagure.io/releng/issues/10819 #10819]

* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.

* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
None.


== How To Test ==
* This can be tested by inspecting the value of the %{build_cflags},
%{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring
they are the same before and after the change.
* This can be tested by modifying some of the new macros in a spec
file and ensuring that the changes appear in the appropriate macro
mentioned above.


== User Experience ==
This is a change for developers and will have no impact to the user experience.


== Dependencies ==
None.


== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Change owner
will revert the update to redhat-rpm-config.
* Contingency deadline: Mass Rebuild
* Blocks release? N/A (not a System Wide Change), No

== Documentation ==
None.

== Release Notes ==
None.


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://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 on the list, report it: https://pagure.io/fedora-infrastructure

F37 proposal: Fallback Hostname (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/FallbackHostname

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 is for the fallback hostname for server like variants of
Fedora to use `localhost` as the fallback hostname.

== Owner ==
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: dustymabe@redhat.com
* Name: [[User:davdunc| David Duncan]] (Fedora Cloud)
* Email: davdunc@gmail.com
* Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT)
* Email: pwhalen@redhat.com
* Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server)
* Email: michel@michel-slm.name
* Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE)
* Email: ngompa13@gmail.com


== Detailed Description ==

In Fedora 33 the default fallback hostname was changed from
`localhost` to `fedora` for Fedora Linux instances that didn't get the
hostname set in any other way (i.e. it's the fallback if it's not set
anywhere else). This change came in a systemd update and was never
proposed as a change in Fedora itself.

The enablement upstream was in
https://github.com/systemd/systemd/pull/5175 and the BZ requesting the
change in Fedora was
https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original
reasoning being that `localhost` is a bad hostname for auto-discovery
protocols (think `avahi`) that are useful for more desktop
applications.

Unfortunately, this caused issues because setting the hostname via
reverse DNS lookups (via NetworkManager) stopped working along with
breaking third party tools that set the hostname. The NetworkManager
problem was subsequently fixed, but it still remains that a lot of
third party software will check to see if an instance's hostname is
"unset" by checking the current hostname against the string
"localhost". Additionally it appears this change will never be picked
up by Fedora's primary downstream in CentOS/RHEL (see
https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307b5c2efc6836a?branch=rawhide).

The proposal here is to enable variants of Fedora Linux to configure
their default/fallback hostname and to set the default for variants
targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`.


== Benefit to Fedora ==
With this change Fedora's server-like variants will become more
compatible with third party tools that expect a hostname of
`localhost` means the system is unconfigured. It also will mean system
administrator's will see `localhost` and assume the hostname is
unconfigured.

== Scope ==
* Proposal owners:
The feature owners will update the systemd compile time switch for
fallback hostname back to `localhost`. The `fedora-release` package
will be updated such that the Fedora Server, IoT, Cloud, and CoreOS
editions will use `localhost` as the fallback hostname. All other
variants of Fedora (the ones that target desktop/laptop uses) will
default to `fedora` as the fallback hostname.

The proposed changes are a relatively small amount of a work.


* Other developers:
For any variants other than Cloud, CoreOS, IoT, and Server they will
see no change. Work with QA to verify other editions continue to have
a fallback hostname of `fedora`.

For Cloud, CoreOS, IoT, and Server the default fallback hostname would
be `localhost`.


* Release engineering: No changes needed for release engineering.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

There will be NO upgrade impact to systems where:

* An admin statically set the hostname
* A hostname was provided to a system via DHCP
* A hostname was found for a system via reverse DNS lookup

In the case where none of the above are true for a system (i.e. a
fallback hostname will be used) the following upgrade impact will be
observed:

* Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has
`/etc/hostname` written by `cloud-init` on first boot.
* Fedora CoreOS: No impact. Already using `localhost` as fallback hostname.
* Fedora IoT: Some impact. The fallback hostname will change from
`fedora` to `localhost` after upgrade.
* Fedora Server: Some impact. The fallback hostname will change from
`fedora` to `localhost` after upgrade.

For Fedora IoT and Fedora Server we will announce the change and
encourage users to statically set a hostname for their machines if
they don't want the change in behavior.


== How To Test ==

Boot an instance of the flavor of Fedora you are testing in an
environment where there is no DHCP hostname provided and no answer to
a reverse DNS lookup for the instance IP. Run `hostnamectl hostname`
and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT,
Server it should be `localhost`. For all others it should be `fedora`.

== User Experience ==
For Cloud, CoreOS, IoT and Server users will notice intances now
default to `localhost` if a hostname is not provided to an instance by
any other means. For all other variants of Fedora there will be no
change.

== Dependencies ==
There will be changes to the `systemd` and `fedora-release` packages
for this change.


== Contingency Plan ==
* Contingency mechanism: Revert the pull requests to the `systemd` and
`fedora-release` packages.
* Contingency deadline: Final Freeze
* Blocks release? Yes


== Documentation ==
The fallback hostname has now changed to `localhost` for the Cloud,
CoreOS, IoT, and Server variants of Fedora.

== Release Notes ==
The fallback hostname has now changed for the Cloud, CoreOS, IoT, and
Server editions of Fedora to `localhost`. The fallback hostname is the
hostname that is set if the hostname cannot be determined by any other
mechanism (statically set, DHCP, or reverse DNS). This change was done
in order to conform to the common expectation that a hostname of
`localhost` on a system means the hostname is "unset".


--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://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 on the list, report it: https://pagure.io/fedora-infrastructure

[USN-5459-1] cifs-utils vulnerabilities

==========================================================================
Ubuntu Security Notice USN-5459-1
June 02, 2022

cifs-utils vulnerabilities
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 22.04 LTS
- Ubuntu 21.10
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS

Summary:

Several security issues were fixed in cifs-utils.

Software Description:
- cifs-utils: Common Internet File System utilities

Details:

Aurélien Aptel discovered that cifs-utils invoked a shell when requesting a
password. In certain environments, a local attacker could possibly use this
issue to escalate privileges. This issue only affected Ubuntu 18.04 LTS and
Ubuntu 20.04 LTS. (CVE-2020-14342)

It was discovered that cifs-utils incorrectly used host credentials when
mounting a krb5 CIFS file system from within a container. An attacker
inside a container could possibly use this issue to obtain access to
sensitive information. This issue only affected Ubuntu 18.04 LTS and Ubuntu
20.04 LTS. (CVE-2021-20208)

It was discovered that cifs-utils incorrectly handled certain command-line
arguments. A local attacker could possibly use this issue to obtain root
privileges. (CVE-2022-27239)

It was discovered that cifs-utils incorrectly handled verbose logging. A
local attacker could possibly use this issue to obtain sensitive
information. (CVE-2022-29869)

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 22.04 LTS:
cifs-utils 2:6.14-1ubuntu0.1

Ubuntu 21.10:
cifs-utils 2:6.11-3.1ubuntu0.1

Ubuntu 20.04 LTS:
cifs-utils 2:6.9-1ubuntu0.2

Ubuntu 18.04 LTS:
cifs-utils 2:6.8-1ubuntu1.2

In general, a standard system update will make all the necessary changes.

References:
https://ubuntu.com/security/notices/USN-5459-1
CVE-2020-14342, CVE-2021-20208, CVE-2022-27239, CVE-2022-29869

Package Information:
https://launchpad.net/ubuntu/+source/cifs-utils/2:6.14-1ubuntu0.1
https://launchpad.net/ubuntu/+source/cifs-utils/2:6.11-3.1ubuntu0.1
https://launchpad.net/ubuntu/+source/cifs-utils/2:6.9-1ubuntu0.2
https://launchpad.net/ubuntu/+source/cifs-utils/2:6.8-1ubuntu1.2

[USN-5458-1] Vim vulnerabilities

==========================================================================
Ubuntu Security Notice USN-5458-1
June 02, 2022

vim vulnerabilities
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 16.04 ESM

Summary:

Several security issues were fixed in Vim.

Software Description:
- vim: Vi IMproved - enhanced vi editor

Details:

It was discovered that Vim was incorrectly handling virtual column
position operations, which could result in an out-of-bounds read. An
attacker could possibly use this issue to expose sensitive
information. (CVE-2021-4193)

It was discovered that Vim was not properly performing bounds checks
when updating windows present on a screen, which could result in a
heap buffer overflow. An attacker could possibly use this issue to
cause a denial of service or execute arbitrary code. (CVE-2022-0213)

It was discovered that Vim was incorrectly handling window
exchanging operations when in Visual mode, which could result in an
out-of-bounds read. An attacker could possibly use this issue to
expose sensitive information. (CVE-2022-0319)

It was discovered that Vim was incorrectly handling recursion when
parsing conditional expressions. An attacker could possibly use this
issue to cause a denial of service or execute arbitrary code.
(CVE-2022-0351)

It was discovered that Vim was not properly handling memory
allocation when processing data in Ex mode, which could result in a
heap buffer overflow. An attacker could possibly use this issue to
cause a denial of service or execute arbitrary code.
(CVE-2022-0359)

It was discovered that Vim was not properly performing bounds checks
when executing line operations in Visual mode, which could result in
a heap buffer overflow. An attacker could possibly use this issue to
cause a denial of service or execute arbitrary code.
(CVE-2022-0361, CVE-2022-0368)

It was discovered that Vim was not properly handling loop conditions
when looking for spell suggestions, which could result in a stack
buffer overflow. An attacker could possibly use this issue to cause
a denial of service or execute arbitrary code. (CVE-2022-0408)

It was discovered that Vim was incorrectly handling memory access
when executing buffer operations, which could result in the usage of
freed memory. An attacker could possibly use this issue to execute
arbitrary code. (CVE-2022-0443)

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 16.04 ESM:
  vim                             2:7.4.1689-3ubuntu1.5+esm5

In general, a standard system update will make all the necessary changes.

References:
  https://ubuntu.com/security/notices/USN-5458-1
  CVE-2021-4193, CVE-2022-0213, CVE-2022-0319, CVE-2022-0351,
  CVE-2022-0359, CVE-2022-0361, CVE-2022-0368, CVE-2022-0408,
  CVE-2022-0443

[LSN-0086-1] Linux kernel vulnerability

Linux kernel vulnerabilities

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
- Ubuntu 22.04 LTS
- Ubuntu 14.04 ESM

Summary

Several security issues were fixed in the kernel.

Software Description

- linux - Linux kernel
- linux-aws - Linux kernel for Amazon Web Services (AWS) systems
- linux-azure - Linux kernel for Microsoft Azure Cloud systems
- linux-gcp - Linux kernel for Google Cloud Platform (GCP) systems
- linux-gke - Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop - Linux kernel for Google Container Engine (GKE) systems
- linux-ibm - Linux kernel for IBM cloud systems
- linux-oem - Linux kernel for OEM systems

Details

It was discovered that a race condition existed in the network
scheduling subsystem of the Linux kernel, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of
service (system crash) or possibly execute arbitrary code.
(CVE-2021-39713)

Yiqi Sun and Kevin Wang discovered that the cgroups implementation in
the Linux kernel did not properly restrict access to the cgroups v1
release_agent feature. A local attacker could use this to gain
administrative privileges. (CVE-2022-0492)

It was discovered that the network traffic control implementation in the
Linux kernel contained a use-after-free vulnerability. A local attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2022-1055)

Bing-Jhong Billy Jheng discovered that the io_uring subsystem in the
Linux kernel contained in integer overflow. A local attacker could use
this to cause a denial of service (system crash) or execute arbitrary
code. (CVE-2022-1116)

It was discovered that the Linux kernel did not properly restrict access
to the kernel debugger when booted in secure boot environments. A
privileged attacker could use this to bypass UEFI Secure Boot
restrictions. (CVE-2022-21499)

Kyle Zeng discovered that the Network Queuing and Scheduling subsystem
of the Linux kernel did not properly perform reference counting in some
situations, leading to a use-after-free vulnerability. A local attacker
could use this to cause a denial of service (system crash) or execute
arbitrary code. (CVE-2022-29581)

Jann Horn discovered that the Linux kernel did not properly enforce
seccomp restrictions in some situations. A local attacker could use this
to bypass intended seccomp sandbox restrictions. (CVE-2022-30594)

Update instructions

The problem can be corrected by updating your kernel livepatch to the
following versions:

Ubuntu 20.04 LTS
aws - 86.3
azure - 86.3
gcp - 86.3
generic - 86.3
gke - 86.3
gkeop - 86.3
ibm - 86.3
lowlatency - 86.3

Ubuntu 18.04 LTS
aws - 86.3
azure - 86.3
gcp - 86.3
generic - 86.3
gke - 86.3
gkeop - 86.3
ibm - 86.3
lowlatency - 86.3
oem - 86.3

Ubuntu 16.04 ESM
aws - 86.3
azure - 86.3
gcp - 86.3
generic - 86.3
lowlatency - 86.3

Ubuntu 22.04 LTS
gcp - 86.4
generic - 86.4
gke - 86.4
ibm - 86.4
lowlatency - 86.4

Ubuntu 14.04 ESM
generic - 86.3
lowlatency - 86.3

Support Information

Kernels older than the levels listed below do not receive livepatch
updates. If you are running a kernel version earlier than the one listed
below, please upgrade your kernel as soon as possible.

Ubuntu 20.04 LTS
linux-aws - 5.4.0-1009
linux-aws - 5.4.0-1061
linux-azure - 5.4.0-1010
linux-gcp - 5.4.0-1009
linux-gke - 5.4.0-1033
linux-gkeop - 5.4.0-1009
linux-hwe - 5.15.0-0
linux-ibm - 5.4.0-1009
linux-oem - 5.4.0-26
linux - 5.4.0-26

Ubuntu 18.04 LTS
linux-aws-5.4 - 5.4.0-1069
linux-aws - 4.15.0-1054
linux-azure-4.15 - 4.15.0-1115
linux-azure-5.4 - 5.4.0-1069
linux-gcp-4.15 - 4.15.0-1121
linux-gcp-5.4 - 5.4.0-1069
linux-gke-4.15 - 4.15.0-1076
linux-gke-5.4 - 5.4.0-1009
linux-gkeop-5.4 - 5.4.0-1007
linux-hwe-5.4 - 5.4.0-26
linux-ibm-5.4 - 5.4.0-1009
linux-oem - 4.15.0-1063
linux - 4.15.0-69

Ubuntu 16.04 ESM
linux-aws-hwe - 4.15.0-1126
linux-aws - 4.4.0-1098
linux-aws - 4.4.0-1129
linux-azure - 4.15.0-1063
linux-azure - 4.15.0-1078
linux-azure - 4.15.0-1114
linux-gcp - 4.15.0-1118
linux-hwe - 4.15.0-143
linux-hwe - 4.15.0-69
linux - 4.4.0-168
linux - 4.4.0-211

Ubuntu 22.04 LTS
linux-aws - 5.15.0-1000
linux-azure - 5.15.0-1000
linux-gcp - 5.15.0-1000
linux-gke - 5.15.0-1000
linux-ibm - 5.15.0-1000
linux - 5.15.0-24
linux - 5.15.0-25

Ubuntu 14.04 ESM
linux-lts-xenial - 4.4.0-168

References

- CVE-2021-39713
- CVE-2022-0492
- CVE-2022-1055
- CVE-2022-1116
- CVE-2022-21499
- CVE-2022-29581
- CVE-2022-30594

Take the Fedora Annual Contributor Survey 2022

Hello, everyone,

Please participate in the Fedora Annual Contributor Survey 2022!

* https://fedoraproject.limequery.com/2022

The survey is anonymous, it has 44 questions targeting Fedora
contributors of all kinds and asks about your default choices of
applications and services.

This is the second run of the survey. The questions are the same as
last year with more variants added according to the data we have
collected. We will compare answers for this year with the previous
year results.

At the end of the survey you will get the claim link for the badge.

For questions and feedback please refer to the forum thread:

* https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fedora-annual-contributor-survey-for-2022/39576

Thank you for your contribution!

--
Aleksandra Fedorova
bookwar on Matrix/IRC
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure

[USN-5456-1] ImageMagick vulnerability

==========================================================================
Ubuntu Security Notice USN-5456-1
June 01, 2022

imagemagick vulnerability
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 18.04 LTS
- Ubuntu 16.04 ESM
- Ubuntu 14.04 ESM

Summary:

ImageMagick could be made to crash if it opened a specially crafted file.

Software Description:
- imagemagick: Image manipulation programs and library

Details:

It was discovered that ImageMagick incorrectly handled memory under
certain circumstances. If a user were tricked into opening a specially
crafted image, an attacker could possibly exploit this issue to cause a
denial of service or other unspecified impact.

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 18.04 LTS:
imagemagick 8:6.9.7.4+dfsg-16ubuntu6.13
imagemagick-6-common 8:6.9.7.4+dfsg-16ubuntu6.13
imagemagick-common 8:6.9.7.4+dfsg-16ubuntu6.13
libmagick++-6.q16-7 8:6.9.7.4+dfsg-16ubuntu6.13
libmagick++-6.q16hdri-7 8:6.9.7.4+dfsg-16ubuntu6.13
libmagickcore-6.q16-3 8:6.9.7.4+dfsg-16ubuntu6.13
libmagickcore-6.q16hdri-3 8:6.9.7.4+dfsg-16ubuntu6.13

Ubuntu 16.04 ESM:
imagemagick 8:6.8.9.9-7ubuntu5.16+esm3
imagemagick-6.q16 8:6.8.9.9-7ubuntu5.16+esm3
imagemagick-common 8:6.8.9.9-7ubuntu5.16+esm3
libmagick++-6.q16-5v5 8:6.8.9.9-7ubuntu5.16+esm3
libmagickcore-6.q16-2 8:6.8.9.9-7ubuntu5.16+esm3

Ubuntu 14.04 ESM:
imagemagick 8:6.7.7.10-6ubuntu3.13+esm2
imagemagick-common 8:6.7.7.10-6ubuntu3.13+esm2
libmagick++5 8:6.7.7.10-6ubuntu3.13+esm2
libmagickcore5 8:6.7.7.10-6ubuntu3.13+esm2

In general, a standard system update will make all the necessary changes.

References:
https://ubuntu.com/security/notices/USN-5456-1
CVE-2022-28463

Package Information:

https://launchpad.net/ubuntu/+source/imagemagick/8:6.9.7.4+dfsg-16ubuntu6.13

[USN-5457-1] WebKitGTK vulnerabilities

==========================================================================
Ubuntu Security Notice USN-5457-1
June 01, 2022

webkit2gtk vulnerabilities
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 22.04 LTS
- Ubuntu 21.10
- Ubuntu 20.04 LTS

Summary:

Several security issues were fixed in WebKitGTK.

Software Description:
- webkit2gtk: Web content engine library for GTK+

Details:

A large number of security issues were discovered in the WebKitGTK Web and
JavaScript engines. If a user were tricked into viewing a malicious
website, a remote attacker could exploit a variety of issues related to web
browser security, including cross-site scripting attacks, denial of service
attacks, and arbitrary code execution.

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 22.04 LTS:
libjavascriptcoregtk-4.0-18 2.36.3-0ubuntu0.22.04.1
libjavascriptcoregtk-4.1-0 2.36.3-0ubuntu0.22.04.1
libwebkit2gtk-4.0-37 2.36.3-0ubuntu0.22.04.1
libwebkit2gtk-4.1-0 2.36.3-0ubuntu0.22.04.1

Ubuntu 21.10:
libjavascriptcoregtk-4.0-18 2.36.3-0ubuntu0.21.10.1
libwebkit2gtk-4.0-37 2.36.3-0ubuntu0.21.10.1

Ubuntu 20.04 LTS:
libjavascriptcoregtk-4.0-18 2.36.3-0ubuntu0.20.04.1
libwebkit2gtk-4.0-37 2.36.3-0ubuntu0.20.04.1

This update uses a new upstream release, which includes additional bug
fixes. After a standard system update you need to restart any applications
that use WebKitGTK, such as Epiphany, to make all the necessary changes.

References:
https://ubuntu.com/security/notices/USN-5457-1
CVE-2022-26700, CVE-2022-26709, CVE-2022-26716, CVE-2022-26717,
CVE-2022-26719

Package Information:
https://launchpad.net/ubuntu/+source/webkit2gtk/2.36.3-0ubuntu0.22.04.1
https://launchpad.net/ubuntu/+source/webkit2gtk/2.36.3-0ubuntu0.21.10.1
https://launchpad.net/ubuntu/+source/webkit2gtk/2.36.3-0ubuntu0.20.04.1