I understand your point about proposal number (3 <-> 1). But I put them together intentionally for several reasons.
The changes are related and checking+testing them along with each
other can save time for everyone, and I had already conversations
with FESCo members and others earlier in the original Discourse
topic before the proposal. It felt useful to have them discussed
at once. It can be said the proposal is a summary of the
discussion topic. Also, this proposal is much about creating and
bringing perspectives together and intentionally leave FESCo some
space for compromises and discussion: again, I see synergies for
the points of the proposal to be one proposal. Personally, I think
there is no realistic issue with bpf=2, ptrace=1, kptr=1, and the
discussion should be mostly about if ptrace and kptr should be
also 2 and how to make the documentation best for gdb/strace users
- but it is up to the members to decide what to focus in the
discussion of course.
Keep in mind that we already agreed in the original discussion
that included FESCo members that I am allowed & will do the
changes to systemd, and also agreed how I shall do it (it is
already elaborated in the proposal). So the means in the proposal
are already agreed, including the how to do it, and it is part of
what people currently vote for. I will prepare the merge request
into Fedora systemd repo if/once the proposal is accepted. Such a
change to our systemd has already occurred before. So that will
not be an issue :)
Except the issue with the package that breaks the default ptrace_scope setting, and which needs to be linked to the ptrace_scope proposal anyway, there are no packages: these are settings from the upstream Linux kernel, we just change the settings. Concerning the package that breaks the ptrace_scope default, people from back then are already involved in the discussion, and at least one FESCo member also knows much about it anyway, as he is himself involved with it & in the discussion.
The proposal is already out and has some feedback. I think
breaking the discussions and withdrawing it and re-creating three
different proposals would cause more confusion than order anyway.
I also don't think it is useful.
However, I agree that the title thus became a little long though.
I expected that the title length will not mitigate representative
feedback as long as the triggers are contained (kernel settings
kptr_restrict, bpf_jit_harden, ptrace_scope, being about
vulnerability/attacks). That a longer title increases the
likelihood to overlook it is indeed a new argument I don't
understand :)
> force the systemd package maintainers to set that and then hope users will read some documentation to enable their installed packages to work again is a great policy.
I think you should read the proposal and potentially the discussion, which I think you have not done yet, as most of what you state has been already tackled. Also, your point about documentation is highly simplified and ignores both that documentation is what affected people with that issue asked for in the first place and also that these gdb/strace users are not the sole users of Fedora, while the practically system-wide policy they imposed in an improvised way without approval affected finally everyone: of course I was myself in situations in which I needed to make something work that unexpectedly broke, and if it is time-critical to get a job done, I understand that everyone in such a situation tends to intuitively ignore implications that feel not relevant for the immediate problem solving, but this is the reason why this improvisation became forgotten and unconsidered, and finally ended up in the current state with everyone being affected by an effectively system-wide change that was never approved -> therefore, my documentation-related part of the proposal does not create a new default but only re-establishes the Fedora default because others forgot to find a permanent solution to replace (or at least approve) their interim solution while subsequently everyone forgot that it existed, leaving it unconsidered later. I understand your perspective, but I hope my perspective makes sense too, and we finally need a compromise that works for everybody :) By the way, there is already positive feedback from users of gdb/strace, and I am open for any incentive that can help to improve the documentation (there is already a topic [1] about where to put the documentation to make it easy to identify and find, and affected developers are free to let me know if anything can be improved -> so far feedback of affected people is on average clearly positive, comparable to what people asked for in 2015). Anyway, if there is more to be discussed about this, please put this into the discussion topic, to keep the discussion together and consistent, and to avoid redundancy (which I now already created :).
Best,
Chris
Christopher, On Mon, Sep 08, 2025 at 06:11:51PM +0000, Christopher Klooz wrote:The below change proposal was accidentally sent to the mailing list under a wrong name.And the new name is so long I originally missed this. Sorry. The long name also suggests (at least to me) that this is really multiple proposals. It seems to suggest three different policy changes. One for logging and processing kernel addresses, impacting programs needing to inspect e.g. /proc/kallsyms. One for BPF using packages, impacting performance and power consumption. And one for tracing/profiling/debugging user space programs, impacting whether installing such a package works out of the box or not. It would be good to turn this into three separate proposals with input from some of the affected package maintainers to come up with a good way to set these values to make sure when you install a package it works out of the box. I don't think just asking FESCO to pick a default value, force the systemd package maintainers to set that and then hope users will read some documentation to enable their installed packages to work again is a great policy. Cheers, Mark
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
