This is very unethical conduct on the maintainer's part.
And this is why finding good maintainers for visible FOSS projects is hard.
You know what's unethical conduct? Misrepresenting someone's words in a way that make them look bad.
The maintainer did exactly what they usually do, I see absolutely nothing unexpected here, note that this was an unsolicited patch sent to a security mailing list. And this is typically how those are dealt with. To claim 'unethical conduct' is one small step removed from a formal complaint about the maintainer, and which is exactly the wrong message to send here. Witch hunts like this cause good people to leave FOSS projects. The maintainer could have given more credit but chose not to, that's the rules you play by when sending in unsolicited patches. If you must have credit then you should not contribute in this fashion.
Is something like "we may accept your work and choose not to give you credit" actually stated somewhere when you sign up for or submit to that security mailing list?
Because that's certainly not the usual rule for unsolicited work in other contexts.
https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
Absolutely nowhere does it say that accepting your patch will lead to you automatically being given kernel contributor status, and to require that status on the basis of committing a single tiny patch that wasn't properly signed off and required work shows a different set of expectations than one that I would see as reasonable.
Now to look at this patch it looks Michael took the report, debugged, tested, and resolved the issue, when all he actually did is move a single line to outside of a conditional.
> and required work shows a different set of expectations
You're really stretching here, the only "required work" missing was a sign off, which Michael could have given.
In any other environment, this would be plagiarism. And it looks morally poor.
Besides that the OP misrepresented the interaction to a degree that he loses my sympathy, he makes the maintainer come off like a dick when in fact that wasn't the case at all, the interchange was polite and to the point and exactly in line with what I'd expect from a kernel maintainer.
Who do you think has the commit bit on the Linux repo? Hint: kernel contributors don't.
> powerpc/32: Fix overread/overwrite of thread_struct via ptrace
Miculas is credited with identifying the low-level issue: ptrace is overwriting thread_struct. To me, that does recognize that Miculas did significant analysis work.
But it ain't much of a sticking point. Most of the time it is just an oversight that can be pointed out and corrected. All it takes is for the maintainer to point it out and ask for it and then then the author to do it. (The patch author themselves need to do it or else there wouldn't be a point to the sign-off; forging a sign-off would defeat the purpose.)