3 ms·

> That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change. The discussion seems to be

> That second one is a good idea, but the maintainer is also right to ask for some discussion before introducing a breaking change. The discussion seems to be already happening https://codeberg.org/forgejo/forgejo/issues/8634 https://codeberg.org/forgejo/forgejo/issues/8634, author of the blog just did drive-by PR rather than looking at issue tracker It's very much "I know better, do what I told you despise not thinking a second about any second order effects the change might cause" attitude that is so common with security people

henryteeare 6mo ago
I believe the discussion in #8634 is for a different change, but one of a similar nature.
- embedding-shape 6mo ago
  It's not, the maintainer has pointed to that discussion multiple times to the author of the submission, saying they need to resolve that before they can just straight up deprecate authentication methods without any alternatives available to users currently using it.
  - radlad 6mo ago
    I'm really confused by this interpretation. I see a single comment by the maintainer, saying: > That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is). It was a related, but separate issue, which is perhaps best-described in this upstream issue: https://github.com/python-social-auth/social-core/issues/1211 https://github.com/python-social-auth/social-core/issues/121... The "plain" setting jvoison wants to remove is described here: https://security.stackexchange.com/a/218554 https://security.stackexchange.com/a/218554 I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.
unethical_ban 6mo ago
Yeah, ITOps and software teams are totally aware of the second order effects of their shitty software and compliance failures, security are always the wrong ones.

henryteeare 6mo ago

I believe the discussion in #8634 is for a different change, but one of a similar nature.

embedding-shape 6mo ago
It's not, the maintainer has pointed to that discussion multiple times to the author of the submission, saying they need to resolve that before they can just straight up deprecate authentication methods without any alternatives available to users currently using it.
- radlad 6mo ago
  I'm really confused by this interpretation. I see a single comment by the maintainer, saying: > That mistake was made in the past (#8634), where there was still a lot of usages of a old and announced deprecated method (and even with quite some effort there is). It was a related, but separate issue, which is perhaps best-described in this upstream issue: https://github.com/python-social-auth/social-core/issues/1211 https://github.com/python-social-auth/social-core/issues/121... The "plain" setting jvoison wants to remove is described here: https://security.stackexchange.com/a/218554 https://security.stackexchange.com/a/218554 I do agree with the maintainer that a discussion is warranted before removing this setting. But I also wouldn't personally have closed the PR while waiting for said discussion to occur - and the maintainer could have created a discussion themselves. They are signaling they don't want this change, full stop.

unethical_ban 6mo ago

Yeah, ITOps and software teams are totally aware of the second order effects of their shitty software and compliance failures, security are always the wrong ones.