XPost: linux.debian.bugs.dist
From: carnil@debian.org

Control: reopen -1
Control: found -1 6.1.135-1
Control: found -1 6.12.25-1
Control: found -1 6.13.5-1~exp1
Hi Niklas,

On Fri, May 02, 2025 at 10:01:19PM +0200, Niklas Sombert wrote:

Hi Salvatore,

I'm not entirely sure how to reply to this.
I feel strongly about this issue; that's why I opened the bug in the first place.

What you did was exactly was i was looking for (more below)

Salvatore Bonaccorso wrote:

Let me try to be more verbose. There are the mentioned issues in the
bug which explain why in Debian the decision was to disable yama by
default (instead of having enabled it by default), which are related
to debugging. It does not mean that users cannot take advantage of the
Yama protection, but the sysctl know need to enable it. So it is just
hte other way around.

Well, yes, thanks for correcting Tobias, but I don't think this is a good default. Almost no users will enable this setting, because they won't know that it exists. I know about the line in dmesg but I really doubt that
people are going to read their dmesg line by line and search for possible options.
Also, most users probably won't debug applications.

Those are good arguments, and we need to re-evaluate if our stance
that default off for the benefits of the debugging possibilties are
still on the weight balance were we want. So I'm opening the bug with
this fresh information and updated metadata.

What I mean with not having reconsidered is that the potential change
has not made it to neither bookworm, nor trixie (to late now) and we
have not seen other real interest to have it reversed.

Sorry, but this is a circular argument. "We're not doing it because we haven't done it yet."

let me paraphrase it differently: There was no action on the bug and
not much inerest in acting people to do "something" about it. The
kernel team had only few months back more than 1000 open bugs, making
the situation very unhealthy. With this action of closing longstanding
but undhandled bugs (with a hopeful good explanation in my mail
template, was it? what was missing for you as user/reporter?) we
brought the bug list down to now less than 200, with the option that
people affected by bugs (or having deposited a wishlist bug or feature
request) still caring obut the problem can approach us.

it is very important to me to make the statement that we do not want
to just rationalize away the bugs, but get confronted with what is
current.

You explicitly showed interest that the situation is still handled,
after a couple of years of inactivity, and we take this seriously.

So this gives us the chance now to either reconsider the decision of
disabling yama by default or -- close the bug with a sensible
rationale why we want to keep this (but then it is not just a bug
without any reply from our team, which is sad for any reporter).

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

XPost: linux.debian.bugs.dist
From: carnil@debian.org

Hi Niklas,

On Sat, May 03, 2025 at 01:36:08PM +0200, Salvatore Bonaccorso wrote:

Control: reopen -1
Control: found -1 6.1.135-1
Control: found -1 6.12.25-1
Control: found -1 6.13.5-1~exp1
Hi Niklas,

On Fri, May 02, 2025 at 10:01:19PM +0200, Niklas Sombert wrote:

Hi Salvatore,

I'm not entirely sure how to reply to this.
I feel strongly about this issue; that's why I opened the bug in the first place.

What you did was exactly was i was looking for (more below)

Salvatore Bonaccorso wrote:

Let me try to be more verbose. There are the mentioned issues in the
bug which explain why in Debian the decision was to disable yama by default (instead of having enabled it by default), which are related
to debugging. It does not mean that users cannot take advantage of the Yama protection, but the sysctl know need to enable it. So it is just
hte other way around.

Well, yes, thanks for correcting Tobias, but I don't think this is a good default. Almost no users will enable this setting, because they won't know that it exists. I know about the line in dmesg but I really doubt that people are going to read their dmesg line by line and search for possible options.
Also, most users probably won't debug applications.

Those are good arguments, and we need to re-evaluate if our stance
that default off for the benefits of the debugging possibilties are
still on the weight balance were we want. So I'm opening the bug with
this fresh information and updated metadata.

What I mean with not having reconsidered is that the potential change
has not made it to neither bookworm, nor trixie (to late now) and we
have not seen other real interest to have it reversed.

Sorry, but this is a circular argument. "We're not doing it because we haven't done it yet."

let me paraphrase it differently: There was no action on the bug and
not much inerest in acting people to do "something" about it. The
kernel team had only few months back more than 1000 open bugs, making
the situation very unhealthy. With this action of closing longstanding
but undhandled bugs (with a hopeful good explanation in my mail
template, was it? what was missing for you as user/reporter?) we
brought the bug list down to now less than 200, with the option that
people affected by bugs (or having deposited a wishlist bug or feature request) still caring obut the problem can approach us.

it is very important to me to make the statement that we do not want
to just rationalize away the bugs, but get confronted with what is
current.

You explicitly showed interest that the situation is still handled,
after a couple of years of inactivity, and we take this seriously.

So this gives us the chance now to either reconsider the decision of disabling yama by default or -- close the bug with a sensible
rationale why we want to keep this (but then it is not just a bug
without any reply from our team, which is sad for any reporter).

Spending another little bit on time on it and preparing the update in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1507 I
still think there might be compelling reasons that we don't to
nothing, but in that case it would be documented at least properly in
the bugreport.

#712740 stated the reasons why it was not enabled by default, and up
to today at least gdb upstream still does not have the patch which
Ubuntu applies (TTBOMK!).

Ben correctly pointed out that it should not be done independly in
Distros to add better warnings, but if that is considered a worthwile
default setting, then upstream tools should have the patches applied. Apparently though that after years still did not happen, it might not
have enough drift to do so.

Anyway I have put that now into discussion for the team so we can
properly decide on an outcome.

Regards,
Salvatore

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)