F37 Change Proposal: MAC Address Policy none (System-Wide Change)
by Vipul Siddharth
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 `systemd-udev` package installs
`"/usr/lib/systemd/network/99-default.link"`,
which sets `Link.MACAddressPolicy=persistent`. This proposal is to
change it to set `Link.MACAddressPolicy=none` to stop changing the MAC address.
This is particularly important for bridge and bond devices.
This change can either only apply to bridge/bond devices, or to
various software devices. That is to be discussed.
== Owner ==
* Name: [[User:thaller|Thomas Haller]] (NetworkManager)
* Email: <thaller(a)redhat.com>
* Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS)
* Email: <dmabe(a)redhat.com>
== Detailed Description ==
On Fedora, udev by default changes the MAC address of a wide range of
software devices.
This was introduced by systemd 242 in early 2019 (Fedora 31), when
`MACAddressPolicy=` was
extended to affect more types of devices.
With `MACAddressPolicy=persistent` udev's aim is to provide a stable
MAC address, otherwise
the kernel will assign a random one. However, that can cause problems:
Firstly, software devices are always created by some tool that has
plans for the device. The tool may not
expect that udev is going to change the MAC address and races against
that. The best solution
for the tool is to set the MAC address when creating an interface.
This will prevent
udev from changing the MAC address according to the MACAddressPolicy.
Otherwise, the tool should wait for udev to initialize the device to
avoid the race. In theory, a
tool is always advised to wait for udev to initialize the device.
However, if it were not for MACAddressPolicy,
in common scenarios udev doesn't do anything relevant for software
devices to make that necessary.
Secondly, for interface types bridge and bond, an unset MAC address
has a special meaning
to the kernel and the MAC address of the first port is used. If udev
changes the MAC
address, that no longer works.
Now the generated MAC address is not directly discoverable as it is
based on `/etc/machine-id`
([https://www.man7.org/linux/man-pages/man5/machine-id.5.html
machine-id(5)]), among
other data. Even if there were a tool to easily calculate the MAC
address, it could be cumbersome
to use it without logging into the machine first. The MAC address can
directly affect the
assigned IP address, for example when using DHCP. When booting a new
virtual machine, the user might
know the MAC address of the (virtual) "physical" interfaces. When
bonding/bridging those
interfaces, the bond/bridge would get one of the well known MAC
addresses. `MACAddressPolicy=persistent`
interferes with that.
The goal of persistent policy is to provide a stable MAC address. Note
that if the
tool or user who created the interface would want a certain MAC address, they
have all the means to set it already. That applies regardless whether
the tool is
iproute2, NetworkManager, systemd-networkd. Neither NetworkManager nor
systemd-networkd
rely on udev's MACAddressPolicy for setting the MAC address. This
behavior is mostly
useful for plain `ip link add`, but it's unclear which real world user
wants this behavior.
Of course, the user is welcome to configure the MAC address in any way
they want. Including,
dropping a link file that sets `MACAddressPolicy=persistent`. The
problem is once udev sets a MAC address,
it cannot be unset. Which makes this problematic to do by default.
While Fedora inherited this behavior from upstream systemd, RHEL-9
does not follow this behavior
([https://gitlab.com/redhat/centos-stream/rpms/systemd/-/blob/c8953519504bf...
centos9],
[https://bugzilla.redhat.com/show_bug.cgi?id=1921094 rh#1921094]). For
RHEL-8, this doesn't
apply because the systemd there is too old to change the MAC address
of most software devices.
This could be either implemented by patching
`/usr/lib/systemd/network/99-default.link`
to have a different policy, or by dropping a link file with higher
priority. In the latter
case, that override could be shipped either by udev or even by NetworkManager.
Another option is to change the scope of this proposal to only change to
`MACAddressPolicy=none` for the device types where this causes the most issues
(bridge/bond/team).
== Feedback ==
This was also discussed on upstream systemd mailing list
[https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html
here].
The upstream systemd maintainers' opinion is that the current udev
behavior is desirable, but accepts that distributions (or network
stacks such as NetworkManager) may choose to change the default
depending on their needs
([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html
reference]).
The goal here is to find out what the Fedora community thinks is the
most appropriate default.
The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094
[rh#1921094]].
== Benefit to Fedora ==
Pros:
- Consistent behavior with RHEL8 and RHEL9.
- Avoid race of udev and the tool that creates the interface.
- Bridge and bond interfaces can get the MAC addresses from their first port.
In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will
get a MAC related to one of its physical NIC devices. In the case of
provisioning
new systems (especially in a large datacenter) information about the server
can be used to configure the network environment (DHCP, Firewall, etc) before
the server is ever even powered on. This does mean that you may have to update
your network environment configuration if you replace a NIC (con), but that you
won't have to update your network environment configuration if you re-install
your server (pro), which is what you'd have to do now with
`MACAddressPolicy=persistent`.
Cons:
- Deviate from upstream systemd.
It is desirable that RHEL and Fedora behaves similar. A possible outcome
could be the current behavior stays and RHEL 10 would change behavior. On the
other hand, different distributions (or even Fedora spins) have different
uses and needs. Deviating might be fine. In the same vein, there is also
a desire to stay close to upstream systemd behavior. But the uses of systemd
project go beyond Fedora/RHEL, so deviating here may also be fine.
== Scope ==
* Proposal owners:
The main goal of this request is to generate productive discussion and
find the desired behavior.
The implementation/changes are either way very simple.
* Other developers:
Other projects that wish a certain MAC address are welcome to
set it for their devices. Including using udev's MACAddressPolicy.
* Release engineering:
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 Objectives:
== Upgrade/compatibility impact ==
After the change, the MAC address for the affected device types changes.
== How To Test ==
1) Create a software device two times, for example `ip link add type
bridge`. Note
that the MAC address is either stable or random, depending on the
`MACAddressPolicy=`.
2) Note that if the software device has the MAC address set initially,
udev does not
change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on
`/sys/class/net/$dev/addr_assign_type`.
3) Create a bridge/bond interface without setting the MAC address.
Note that if `MACAddressPolicy=none`,
the MAC address is random at first. Note that attaching the first port
will update the controller's MAC address.
On the other hand, with `MACAddressPolicy=persistent`, the MAC address
of the controller is fixed
and not inherited from the port.
4) Run
ip monitor link &
while : ; do
ip link del xxx
ip link add name xxx type dummy \
&& ip link set xxx addr aa:00:00:00:00:00 \
&& ip link show xxx | grep -q aa:00:00:00:00:00 \
|| break
done
to reproduce the race between a simple tool and udev changing the MAC address.
== User Experience ==
Bond/bridge devices would again get assigned the MAC address of the
first NIC added to the device.
If we chose to not limit the scope of this change to just
bonds/bridges then all software devices would get randomly assigned
MAC addresses.
== Dependencies ==
None.
== Contingency Plan ==
If the change is rejected, nothing needs to be done. The change
itself will be simple to implement.
Contingency deadline: beta freeze
Blocks release? No
== Documentation ==
TODO.
== Release Notes ==
--
Vipul Siddharth
He/His/Him
FPgM team member
1 year, 2 months
How/Where to put git_archieve.tar.gz for packaging?
by Ming Lei
Hello Richard and Guys,
I am trying to figure out one PR for ubdsrv to sync with upstream.
I found the following change in history update:
commit 2ab1e571717a13edddc572269608e918e449a3b8 (origin/main)
Author: Richard W.M. Jones <rjones(a)redhat.com>
Date: Thu Nov 3 11:33:42 2022 +0000
Move to a newer tag (1.0-rc3 + a couple of upstream patches)
diff --git a/sources b/sources
index 47e83d8..1735716 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz) = a12e218b6d97631b9726cdaa2e14dfb7f4df422dd77265701f40ba8704c7d4ccac6c632f635115863f8694bd626f06f67e2ebdf93ae92778a0dae3cddb0259c6
+SHA512 (ubdsrv-ca8baff898868f2ee6f5cdda9c16cf8d94435262.tar.gz) = 9d85271cc73026e7ff8a58153cffb4fd9f760c136d790e0b681cd6b903813cd9d9b98bba934c7ef1248ee0514fe7a6967d3ee65afd6cc44ea0bd3a0796c62ff3
diff --git a/ubdsrv.spec b/ubdsrv.spec
'fedpkg build' needs ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz to be
put somethere, and I guess when I sync with upstream for ubdsrv new change,
I need to generate ubdsrv-${GIT_HASH}.tar.gz & its sha512sum, and put it
somewhere so that 'fedpkg' can find it and test it first.
Can anyone help to share how/where to upload ubdsrv-${GIT_HASH}.tar.gz?
Also I don't know how to figure out the sha512sum hash? I tried to do that for
ubdsrv-698c92c9d292903adae142a86d2fee10fce91850.tar.gz by plain sha512sum, but
get different result compared with the value in above commit even though the
comment of .tar.gz is same(same prefix, same 'diff -u').
Thanks,
Ming
1 year, 2 months
HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates
by Fabio Valentini
Hi all,
I've been collecting data about the dependency graph of Rust packages
in Fedora for over a year now, and I would like to start the process
of removing some accumulated cruft. In particular, I've been keeping
track of which packages for *library* packages (i.e. they ship only
source code but no binaries) have been leaf packages.
List of Rust library-only packages, which no other package in Fedora
has depended on, for over a year (365 days+):
- rust-compiletest_rs
- rust-constant_time_eq
- rust-conv
- rust-counted-array
- rust-dbus-tokio
- rust-defmac
- rust-dialoguer
- rust-enumset
- rust-failure-tools
- rust-fake-simd
- rust-fbthrift_codegen_includer_proc_macro
- rust-fdlimit
- rust-hamcrest2
- rust-html2pango
- rust-imgref
- rust-ioctl-rs
- rust-lipsum
- rust-listenfd
- rust-loggerv
- rust-lzw
- rust-macro-attr
- rust-mdl
- rust-mktemp
- rust-mnt
- rust-newtype_derive
- rust-odds
- rust-osstrtools
- rust-parse_cfg
- rust-permutate
- rust-piper
- rust-podio
- rust-proc-quote-impl
- rust-process_path
- rust-progress-streams
- rust-protoc-rust
- rust-quickersort
- rust-rand_jitter
- rust-rand_os
- rust-read_input
- rust-relay
- rust-rustc_tools_util
- rust-rustdoc-stripper
- rust-rustfilt
- rust-safe-transmute
- rust-scoped-tls-hkt
- rust-serde-pickle
- rust-serial-core
- rust-sluice
- rust-smallstr
- rust-spinning_top
- rust-spmc
- rust-ssh-key-dir
- rust-stb_truetype
- rust-string_cache_shared
- rust-strings
- rust-sudo_plugin
- rust-sxd-document
- rust-synom
- rust-sysctl
- rust-tabwriter
- rust-take
- rust-timerfd
- rust-tower-test
- rust-tower-util
- rust-ucd-util
- rust-unic-ucd-category
- rust-url_serde
- rust-urlocator
- rust-utf8-ranges
- rust-watchman_client
Some of these packages are dependencies of things that will be worked
on at some point in the future (for example, packaging of GStreamer
plugins that are written in Rust), but others look very much like
accumulated cruft.
If you see a package on this list that you would like to keep for some
reason, please speak up, and I will exclude it from future dependency
graph analysis. Otherwise I will soon start retiring packages that
have been unused for over a year.
The packages that would be in the list above, but which I *know* will
get some use soon, are:
- rust-curve25519-dalek
- rust-gstreamer-audio
- rust-gstreamer-editing-services
- rust-gstreamer-player
I will probably start the cleanup process with packages for crates
that no longer have any dependent crates listed on the crates.io
registry (which is a good indicator that they are indeed obsolete),
and then continue with crates for which the longest amount of time has
passed since the last upstream release (which is "more than 5 years
ago" for some crates ...).
Fabio
1 year, 2 months
Testing of the New Staging Deployment of MDAPI
by Akashdeep Dhar
Hi folks,
I hope you are doing well. I write this to let you know that I have been
working on the MDAPI project under Pierre-Yves Chibon's guidance for some
time now for
1. Refactoring the code
2. Implementing code quality standards
3. Adding more comprehensive tests
4. Implementing a CLI wrapper
And other major changes
The codebase functionality remains the same in this rewrite for users, but
I have made attempts to ensure that it becomes relatively easier for the
community members to be able to contribute to the project with the addition
of documentation, enhancements in code readability and other miscellaneous
changes that help improve the contributor quality of life. Once the changes
were completed, I moved the repository from my personal GitHub namespace
(now archived)[1] over to Fedora Infra's GitHub namespace[2] and deployed
it on the Fedora's staging environment[3], with David Kirwan's assistance.
Please take it for a spin and test it out so that we can fix as many issues
as we can before we deploy it on the production environment.
Happy holidays! :)
Index
1. https://github.com/t0xic0der/mdapi
2. https://github.com/fedora-infra/mdapi
3. https://mdapi.stg.fedoraproject.org/
Regards,
Akashdeep Dhar (he/him),
Objective Representative, Fedora Council
Red Hat Community Platform Engineering
t0xic0der(a)fedoraproject.org
akashdeep(a)redhat.com
1 year, 2 months
Re: Self Introduction: Hussein K.
by Sandro Mani
Welcome!
On 16.12.22 15:15, h-k-81(a)hotmail.com wrote:
> Hello everyone
>
>
> This mail should serve as my self introduction to the devel community.
>
> I am a (soon to be) computer science graduate, that has been working
> in the Linux / open source world for about 6 years. I first started
> working
> as a python developer in the GIS (geographic information system) domain.
> After some time I also began to perform some system administration tasks.
> And before I knew I started to do a bit of everything.
> So to describe my current work, I do
>
> - Python development
> - System administration
> - Kubernetes administration (or whatever you want to call it)
> - A little bit of javascript
> - Devops (Automatic deployments via CI / CD pipelines, mainly using
> Gitlab CI)
>
> Oh, I also picked up rust a couple years ago and have been using it
> for Uni and
> private projects.
>
> Now the reason for why I want to get more involved in the Fedora
> package maintainer community
> is because I want to get a better understanding on how applications
> are packaged and
> distributed to end-users in a secure and stable manner.
> And from my experience, the best way to learn, is to get your hands
> dirty.
> Naturally, I also want to give back to the community, that has doing
> amazing
> work at developing Fedora and keeping everything working, and I want
> to become a part of it.
>
>
> In the last week, I have been reading a lot of documentation on RPM
> packaging
> and I have created my first package. I am currently looking for a sponsor
> to help me with my first package review:
> https://bugzilla.redhat.com/show_bug.cgi?id=2154124
>
>
> This concludes my introduction and I hope this was not too much to
> read :D
>
>
> Best wishes
> Hussein K.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
1 year, 2 months
F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
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 ==
X server implementations (e.g. Xorg and Xwayland) will (by default) no
longer allow clients with different endianess to connect.
== Owner ==
* Name: [[User:whot| Peter Hutterer]]
* Email: peter.hutterer(a)redhat.com
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences
suffices to explain the goal, but the more details you can provide the
better. -->
X server implementations (e.g. Xorg and Xwayland) allow clients with
an endianess different to that of the server to connect. Protocol
messages to and from these clients are byte-swapped by the X server.
However, the code in the X server that does this is virtually
untested, providing a large attack surface for malicious clients. One
needs to only look at e.g.
[https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this
X.Org security advisory] and count the `SProc` mentions for an
indication on how bad this is. A simple solution to remove this attack
surface is to prohibit clients with a different endianess. These
clients will simply fail, in a matter similar to failing to
authenticate against an X server.
The use-case for clients with different endianess is ''very'' niche.
It was common in the 1980s when X was originally developed but at this
point a vanishingly small number of users run clients and X servers on
different machines, let alone on different machines with different
endianess. I'd be surprised if Fedora had ''any'' users requiring this
feature.
Note:
* this only affects use-cases where the server runs on a little endian
host and the client on a Big Endian host (or vice versa).
* this is a change in '''the default behavior''' only and can be
changed via configuration options (for `Xorg`) and/or commandline
arguments (all X servers).
* this is a change in the upstream default behavior that Fedora will
follow along with. This Change is primarily to increase the exposure.
== Benefit to Fedora ==
This change removes a large potential attack surface that can be used
by malicious clients to expose memory locations, crash the X server
and/or do other entertaining things malicious programs like to do.
== Scope ==
* Proposal owners:
# Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
upstream PR]
# Backport patch to Fedora's `xorg-x11-server` and
`xorg-x11-server-Xwayland` packages
* Other developers: This is labelled as system-wide change simply
because it's a change in Xorg/Xwayland. It is otherwise self-contained
in that no other packages need updating, '''unless''' they want to
opt-out of this default. Which is better left to system-specific
configuration anyway.
* Release engineering: This feature does not require coordination with
release engineering
* 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 ==
For the ''extremely niche'' use-case of users that run X clients on a
remote machine with a different endianess, these clients will no
longer be able to connect '''by default'''. For Xorg, the following
`xorg.conf.d` snippet will re-enable the old behavior:
<pre>
Section "ServerFlags"
Option "AllowSwappedClients" "on"
EndSection
</pre>
Wayland users (and thus Xwayland) need to employ compositor-specific
configuration to pass the `+byteswappedclients` flag to Xwayland. At
the time of writing, GNOME does not yet provide such a configuration.
== How To Test ==
To test the impact of this change, you need:
* an X server running on a little endian architecture and an X client
running on a Big Endian architecture (or the other way around)
* set up the X server to accept remote connections, either via TCP or
through SSH
* run the X client which will fail to connect
Alternatively, a test client is available in
[https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the
upstream PR]. This test client pretends to be BigEndian and will fail
to connect when run against a little endian X server.
== User Experience ==
For virtually all users, there is no change in behavior.
Users with X server and client on two different machines must add the
`xorg.conf.d` snippet shown above on affected systems.
== Dependencies ==
No other RPMs depend on this change.
== Contingency Plan ==
This change depends on whether upstream merges this new default
behavior. If upstream does not merged the feature in time, this Change
will be postponed until the next Fedora version to avoid potential
incompatibilities between configurations or commandline options.
* Contingency mechanism: keep current behavior, try again with next
Fedora version
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
F38 proposal: FPC repackaging (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging
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 ==
Split the `fpc` package (the Free Pascal Compiler) into several
sub-packages (built from the same spec file).
== Owner ==
* Name: [[User:suve|Artur Frenszek-Iwicki]]
* Email: <fedora(a)svgames.pl>
== Detailed Description ==
The `fpc` package will be split into three packages:
* `fpc` - the compiler itself, plus utility programs
* `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`)
* `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's
stdlib") for developing programs for Linux
The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`.
== Benefit to Fedora ==
The TUI IDE will be moved to a separate package, slightly reducing the
download size for packages requiring FPC to build.
Putting Linux units in an `fpc-units-ARCHNAME-linux` package will
create a precedent which can be used in the future for introducing
cross-compilation packages, like `fpc-units-x86_64-win64` for MS
Windows.
== Scope ==
* Proposal owners:
** Edit `fpc.spec` as required and rebuild the package, preferably
before the Mass Rebuild.
* Other developers: No action required.
* Release engineering: No action required.
* 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 ==
After upgrading to Fedora 38, users interested in the TUI IDE will
need to manually install the `fpc-ide` package. For those not
interested in the TUI IDE, there will be no impact.
== How To Test ==
A copr repository has been created where users can test out the
modified package:
[https://copr.fedorainfracloud.org/coprs/suve/fpc-split/
copr/suve/fpc-split].
This copr repository also modifies the spec to build units for MS
Windows (`x86_64` only), allowing for cross-compilation.
== User Experience ==
For users not interested in the TUI IDE, this Change will slightly
reduce the install size (about 1.5 MiB for the IDE plus another 3.5
MiB for its dependencies).
Since the TUI IDE does not launch the compiler as a sub-process, but
rather contains an embedded copy of the compiler, users who use only
the IDE and not the standalone compiler will benefit in a similar way
- they will be able to install just the IDE, without the main compiler
package.
== Dependencies ==
None.
== Contingency Plan ==
Worst case scenario - give up, revert to an old version of `fpc.spec`
and rebuild the package.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The `fpc` package no longer includes the terminal-based TUI IDE. Users
interested in the IDE should install the `fpc-ide` package.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 2 months
Web Assembly on Fedora: interested in a Fedora SIG to work on this?
by Michael Dawson
As Web Assembly (WASM) gains momentum we’d like to create a SIG as a place to collaborate to ensure that Fedora is a great platform to both build and run WASM workloads. This includes looking at the toolchains needed to build WASM as a target and the runtimes needed to run WASM. It will provide a place to bring together efforts across different ecosystems (nodejs, rust, compiler toolchains, etc.) as well as a place where people can provide self-help when building and running WASM workloads.
If you are interested in a WASM Sig please let us know.
1 year, 2 months
