Nothing about that says "I have debugged an issue and contributed actual code to fix it" in there.
[1]: https://docs.kernel.org/process/submitting-patches.html#usin...
(Sure, in the same situation I would prefer to also be credited with authorship too. But I get it.)
Authoring the patch is often trivial once the debugging is done. Describing the debugging as just reporting is underselling it.
One thing I've learned from this thread is that as maintainer of a FOSS package, especially a popular one you are always going to get yelled at (to the point that people will make up reasons and put words in your mouth for yelling at you), no matter what you do. People are literally calling for the maintainer to leave.
A missing Signed-off-by is a clerical error. It doesn’t mean the patch doesn’t work. It’s 100% in the realm of normal for the “lkml bureaucracy” to simply ask the author to add the missing signature and then move on.
You’re acting like a missing signature line immediately invalidates your work and gives any maintainer license to copy paste your work instead of properly applying your patch.
The appropriate attribution arrangement here is not “reported by”. It’s Ariel as the author and the maintainer as the committer. Period.
Having that present would have likely increased the chances of this thing never happening in the first place by a significant factor. Almost every large open source project has their own quirky bits like that and as a newcomer you should at least read the documentation on how to contribute if you want to contribute, especially if that documentation is readily available and meticulously kept up to date.
Note that LKMS treats patches typically as proposals and not as must include verbatim or ignore and that by engaging the Linux kernel security mailing list a whole pile of mechanisms kicks in that remove options to play nice with newbie submitters and to help coach them through how to reach the state of the patch that would have been expected the first time around.
OP is aiming a pretty heavy handed attack on a kernel maintainer (a thankless job on the best of days), does so by misrepresenting their interaction in ways that matter and on top of that couldn't be bothered to read the docs.
I don't follow your fixation on sign-off. I am familiar with the guidelines. Like I said, sign-off is clerical. Yes it's obviously important, but it's still clerical. Nothing you've said changes that.
I agree there's obviously a middle ground here where both the maintainer was acting in the best interest of the community to get a security fix integrated and where the first-time contributor was perhaps miss-attributed in the commotion and feels slighted but also can learn a lesson. I'm not one of those out there calling for a witch hunt to cancel the maintainer (honestly I don't know where to those people are, but I'll take your word that you've encountered a few of them).
Still, your fixation on "well Ariel didn't sign off on the commit so all's fair" is pretty dismissive of the work Ariel did to get to the patch. The bug was acknowledged and outstanding. This obviously wasn't something massively problematic or the original bug would have been fixed when it was reported (I guess maybe it was misunderstood and it really was serious, but I don't get that vibe).
At the end of the day, Ariel is a contributor. No not someone who has privileged commit access to the software, but a contributor to the project nonetheless, whether a maintainer copy-pasted the work or not. And hopefully someone who will continue to contribute in the future. I hope Ariel can come to see it that way whether the maintainer tries to make things right, or even just apologize for the confusion, or not.
I don't read Ariel sharing his experience as an attack. I read it in his words as:
> Well, I certainly didn’t feel inspired to get involved with the kernel community again. On the contrary, I felt belittled and angry that my work wasn’t properly recognized.
> My first contribution to the kernel was a really frustrating and discouraging experience, dealing with people who do not think it’s important to get proper recognition for your work.
I, at least, hold the "lkml bureaucracy" to higher standards.
Whatever work Ariel has done has been grossly negated by this attack piece, besides the fact that it omits and/or materially alters the nature of the interaction. At no point did the maintainer leave any doubt as to their intentions, nor was anything that happened unexpected. If you start off your career as a contributor to the Linux kernel by mailing the security mailing list then that requires you to do your homework because otherwise things will be out of your hands. If that was the OPs intention he would have done better to leave the security mailing list out of it and first strike up a conversation with the maintainer about what the best way to start contributing is (there are guides as well, but since he clearly wanted to target this particular subsystem that would have been a valid approach in my opinion).
It's an attack to me because (1) it mentions an exchange that names individuals and (2) it does so using some very expensive words ('robbery'). That's not the kind of accusation that you make lightly and in this case I think it is vastly misrepresenting what actually happened. You only have to read the responses in this thread to OPs misrepresented account to realize how much effect such a thing can have.
What happened is that someone new chose a wrong and ultimately broken way to submit a patch to LKML and that the maintainers did their best to get maximum mileage out of it without wasting time on formalities. Note that these are pretty busy people, to put it mildly and by mailing the security list you've just made them that much more busy still (even though, technically the patch was an improvement it still required work that then ended up becoming high priority).
As for Ariel being a contributor: according to LKML he submitted a proposed patch that needed work, wasn't properly signed off and according to the git commit log he created a report. That's the extent of it, and that's fairly accurate given the standards for these things.
If you want to argue that those standards need work then you may well have a point. But within the current framework this all was 'business as usual' and totally expected.
I even tried to reach a middle ground understanding and you've doubled down asserting that there's no world in which the author's lived experience can be valid because he didn't initially add a signed-off-by line. If you actually read the post, the author spends most of the time describing the issue and the fix. He takes maybe 5 sentences to explain how he didn't feel like his contribution was accepted in a considerate manner and it's discouraged him from making further contributions. It's not some grand 1000 work attack and if anybody has the thick skin to withstand one of those it's the goliath of the LKML.
And the author pretty explicitly states that he did go back and forth with the maintainer privately and provided a fixed up patch which addressed feedback he'd received on the first patch (presumably with a signed-off-by line, now) and the maintainer still didn't want to give credit. You've conveniently ignored this part of the narrative entirely. This really discredits your whole "it was a quick security list issue and wasn't even formatted properly lol this guy obviously deserves no respect for engaging the security list and generally being a noob" angle.
Everything that we know points to the contributor trying to act responsibly by engaging the security list first since they didn't know the security impact of a possibly major security issue (overwriting the stack of a traced process). I completely fail to understand your logic whereby doing so means the OP obviously fucked up and deserves to have his contribution belittled and stolen and that's just life on the LKML... seriously I think it's time you just admit you're in the wrong here and stop shit posting.
We've already been through the whole "you shouldn't need to have thick skin and tolerate insults and disrespect to contribute to the linux kernel" as a community. Linus even took a leave of absence over this shit. Your stance that this stuff is acceptable and par for the course is no longer the status quo. Grow up.
I've been trying to browse this thread and before I started checking usernames I got the the impression that there's a whole world of maintainers who think it's acceptable to be disrespectful to people spending a lot of time and effort on trying to contribute.
It turns out it's just a few (very prolific) people creating a lot of negative noise across the thread. Thank you for stepping up.
If someone put the work in to identify a bug, contributed a fix, and that fix wasn't accepted but another fix inspired by the previous fix was accepted... That could be plagarism.
Burden of proof is on the plaintiff to prove the fix was inspired by the RCA and proposed fix, of course, but this isn't exactly a clean-room work and kernel maintainers should probably be careful about taking ideas without signoff on the lead-in side too. There's a reason Marvel et. al. in the publishing world can't accept new character concepts.
https://developercertificate.org/
> (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
etc
This is murky enough that it would have to be decided in the court of law, but it's not cut and dry enough that it would be immediately thrown out of that court of law.
Or you're adding some personal other experiences? (What are those? People yelling at you because you did attribute someone for the work they did?)
My understanding is that if the initial patch was not signed off then the maintainer could not sign off his patch, unless he wanted to take on the liability of certifying that the contributor was indeed allowed to contribute the initial patch under whatever license we are talking about here. That sounds like a legal risk I would not be willing to take.
The OP has submitted a link to an email archive further down in the thread.
> Yes, and that was one of the reasons the maintainer rewrote it (which wasn't a lot of work since it was a tiny patch anyway).
I don't think a simple rewrite is enough to convincingly solve the described problem. There is a reason "clean room design" exists and considering the maintainer read the original patch first before creating their own there is a good argument that they were at least subconsciously inspired by the original patch and therefore plagiarized. That is how I understand the legal aspects of this, anyway.
Generally most of the work occurs after a bug is reported, as it did here.
I feel like what some people don't understand is that there are contributions like this all the time, and it is often better to take the submitted code as a proof-of-concept than bring a newcomer up to speed on the maintainers' coding standards.
"Based-on-patch-by:" and/or "Root-caused-by:" comes pretty close, I think.
It may seem like a small difference, but I understand the author's disappointment.
linux$ git log | sed -nE 's/^ *([^ ]+-by:).*$/\1/p' | tr '[:upper:]' '[:lower:]' | sort | uniq -c | egrep -v ' [0-9] '
20 ack-by:
74 acked-and-tested-by:
195801 acked-by:
24 acked-for-backlight-by:
49 acked-for-mfd-by:
19 acked-in-principle-or-something-like-that-by:
21 acked-off-by:
10 analysed-by:
47 analyzed-by:
26 based-on-a-patch-by:
97 based-on-patch-by:
15 based-on-work-by:
128 bisected-by:
18 boot-tested-by:
37 build-tested-by:
147 co-authored-by:
4779 co-developed-by:
175 debugged-by:
60 diagnosed-by:
11 disliked-by:
11 eviewed-by:
51 fixed-by:
18 fix-suggested-by:
32 found-by:
48 generated-by:
19 improvements-by:
79 inspired-by:
18 located-by:
10 not-acked-by:
86 noticed-by:
30 original-by:
140 originally-by:
95 original-patch-by:
44 pointed-out-by:
14 proposed-by:
10 reivewed-by:
22 reported-and-acked-by:
12 reported-and-analyzed-by:
77 reported-and-bisected-by:
12 reported-and-debugged-by:
23 reported-and-suggested-by:
3017 reported-and-tested-by:
21 reported-bisected-and-tested-by:
58990 reported-by:
11 requested-and-tested-by:
363 requested-by:
10 review-by:
55 reviewd-by:
513 reviewed-and-tested-by:
304543 reviewed-by:
16 reviewed-off-by:
67 reviwed-by:
11 root-caused-by:
29 sigend-off-by:
10 signed-by:
157 signed-of-by:
2253448 signed-off-by:
59 singed-off-by:
54 spotted-by:
32 suggested-and-acked-by:
12 suggested-and-reviewed-by:
17 suggested-and-tested-by:
15568 suggested-by:
48 tested-and-acked-by:
22 tested-and-reported-by:
35 tested-and-reviewed-by:
62630 tested-by:
12 verified-by:
If you don't filter out the tags with less than 10 uses, there are some fun ones. For example, "You're-my-ding-a-ling-by:" should be used more often. :)
Identified: They have found an issue and reported it.
Debugged: They found the cause of the issue.
Fixed: They wrote the fix.
It seems that Ariel should be credited for somewhere between Debugged and Fixed. But is only explicitly given credit for the first "tier" of solving the problem. It would have been nice to explain a bit more the work that Ariel put in.
But I agree that I wouldn't expect an inferior (by the maintainer's perspective) patch to be included just to give that credit. But a sentence explaining how Ariel contributed would likely be much appreciated.
> The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.
It sounds like the author wrote the fix and the maintainer merely edited it to fit the project style.
If that truly is all that was done, how hard would it have been to ask the author to quickly make that change?
If the poster wants to get a lawyer he can probably force rewriting git history to give him credit. Is it worth it - probably not.
https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
Note the bit about the Co-developed-by tag:
"A Co-Developed-by: states that the patch was also created by another developer along with the original author. This is useful at times when multiple people work on a single patch. Note, this person also needs to have a Signed-off-by: line in the patch as well."
and
"Note, you did not properly sign-off on this commit, so it couldn't be applied anyway :("
From the exchange between the OP and the kernel maintainer. Which may have been the whole issue.
Well, if it was, the maintainer didn't communicate that well/at all:
"I prefer my version".
You're making the mistake of accepting at face value a one-sided account of an issue, and in the process failing to even check what the answer actually was.
Seriously, this is getting way out of hand: when contributing to a project that has been going for more than a few decades you need to first familiarize yourself with how things are done to set your expectations for the interaction appropriately. The Linux kernel group does a pretty good job and they have their own ways of doing things. It's custom - and polite - to get the lay of the land before yelling 'robbery' when what actually happened is exactly what is supposed to happen: the bug got fixed, you got credited for the report and the maintainer spent some of their - precious - time on getting your proposal - because that is what a patch sent to LKML is - fixed and included.
And that's ignoring for the moment the fact that the interaction wasn't at all like the OP suggested it was.
FWIW a submission to LKML does not come with any kind of guarantees for either accreditation, use, timeliness or consideration. You are making a small gift to the Linux kernel and all of its users and as such you are being thanked. Hopefully you got more value out of the Linux kernel than you contributed on account of the work that others have put in. The LKML record will suffice to prove your claims of copyright but realize that your work does not stand on its own, it is always going to be within a larger context. Try affixing a (C) Worewood to a patch you intend for inclusion and send it to LKML and see how you'll fare.
> The Linux kernel group does a pretty good job and they have their own ways of doing things
I'm not saying otherwise. However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change. Yes the maintainer spent time, but it appears like more credit is being claimed by the maintainer than is deserved, credit that should go to the patch submitter. It doesn't matter if this is normal Linux process, it is still wrong and the maintainers should change their process to be morally correct.
Of course I don't know if the interaction was as OP claims or not. I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)
I think they're doing things as 'by the book' as possible.
> Of course I don't know if the interaction was as OP claims or not.
Well, he documented it twice and those two accounts differ considerably.
> I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)
Who will the OP sue?
For what exactly?
In which court?
None of this makes any sense. If you think the possible outcome of submitting an unsolicited small and broken patch to a security mailing list of a major FOSS project is going to result in you taking anybody to court for copyright infringement then it probably is a great idea not to contribute at all, this will save everybody time and grief. Besides that: the OP - as far as I'm concerned - has copyright to their contribution to LKML, note that nobody except for the OP claims that this is not the case.
It's interesting how for instance all of the comments written in this forum are technically copyrighted by their writers. But you don't control them after submitting them because of the way the forum is structured, the jurisdiction that it is run from and the expectations that come with forum comments. LKML patch submissions are like that as well: they come with a whole pile of baked in assumptions that the OP apparently wasn't familiar with. The idea that each and every minor patch author, especially of patches that are broken and that do not contain required elements is going to end up being hand-held through the process of making a proper contribution is ridiculous.
The maintainers work-load is such that the pay-off is that your contribution is looked at at all, better still if it results in a fix (even if it isn't literally yours). And if you want credit then you should at least state that up front so that the maintainer has a chance to work with you out of the spotlight until you're ready to submit your patch publicly.
Threatening to sue on account of something like this is exactly why I would never be the maintainer of a major open source project, life is too short to deal with all the drama and entitlement.
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.
If this is what the maintainer usually does then the maintainer is a wanker. If they leave the project, the project won't be losing a good person.
You can find it here:
https://www.kernel.org/doc/html/v4.17/process/submitting-pat...
That's exactly what they did.
Keeping 97% of the patch and changing 3% of the patch isn't what anyone would considered rejection.
When I started contributing to the kernel, it was super painful and I failed multiple times. I got super harsh comments (someone called me "retard. It was fun, I laughed, eventually part of my work gor merged) but I always respected the maintainers and I was eager to better myself and improve my analytical and development skills with an open mind to be as sharp as the senior hackers. I always looked up to them and never thought in the same way the newbie did when my patches got re-written or dismissed. I just considered myself "not good enough" and I felt "I had to work harder and smarter".
Your second paragraph is the same logic that frats use to defend hazing rituals. (I went through it, so why shouldn't the new guy?)
Introducing the word 'woke' into this discussion can't possibly be a good idea.
The maintainer said this guy ‘reported’ the bug when he’d actually diagnosed and fixed it. That was a mistake which the maintainer since apologized for, and the mistake could have been avoided without any additional time and effort on the maintainer’s part simply by using a more appropriate tag.
You are really going off into outer space with this stuff about ‘market economics’ and ‘complex courting rituals’. In my experience, whenever I need to make very complex and wide-ranging arguments to justify my behavior, it usually means that I’m the asshole.
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.
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.)
> 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.
"I like my code better" indicates that neither of this happened. So, Ariel deserves (at least partial) credit for fixing, since this was not a "clean room" fix.
Lots of options it seems: https://news.ycombinator.com/item?id=37685190
> Hi Ariel,
>
> I've added Christophe to Cc who works on ppc32.
>
> I haven't actually reproduced the crash with gdbserver, but I have a
> test case which shows the bug, so I've been able to confirm it and
> test a fix.
>
> Thanks for your patch, but I wanted to fix it differently. Can you try
> the patch below and make sure it fixes the bug for you?
>
> I've also attached the test case I've been using.
>
> Christophe are you able to test these on some 32-bit machines? I've
> tested it in qemu and on one 32-bit machine I have here, but some more
> real testing would be good.
>
>
> If the patch works then I'll need to do manual back ports for several of
> the stable kernels, and then once those are ready I will publish the
> patch.
>
> cheers
>
> [...]
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...