> 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, 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

▲

unethical_ban 3 days ago | parent | next [-]

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 3 days ago | parent | prev [-]

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

▲

embedding-shape 3 days ago | parent [-]

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.

	▲	johnmaguire 3 days ago \| parent [-]
		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/121... The "plain" setting jvoison wants to remove is described here: 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.