5 ms·

Reported-by should go to the person who reported the issue 6 years ago. Finding the issue (again), investigating, debugging, fixing and testing that fix sounds

by matrss 3y ago

Reported-by should go to the person who reported the issue 6 years ago. Finding the issue (again), investigating, debugging, fixing and testing that fix sounds more like a hypothetical "Fixed-by", or co-authorship, depending on how similar the final patches really are. Authoring the patch is often trivial once the debugging is done. Describing the debugging as just reporting is underselling it.

jacquesm 3y ago
That's fair, but before you know it you're going to have a whole taxonomy of different kinds of contributions and there simply isn't one for 'x did RCA' and the fact that the original patch wasn't properly signed off as mentioned in the exchange with the kernel maintainer may have been all that stood between that and another level of accreditation. Which by the way wasn't responded to by the OP as far as I can see, even though the maintainer clearly mentioned it and the LKML list spells out that that is a requirement for accreditation.
- jxramos 3y ago
  yah, this is a sticky point. This is one of those scenarios where I put the onus on the person more familiar with the process to inform others for these sort of nuances. Its one of those information asymmetry / familiarity problems. Maybe both were not well versed in the concept of coauthorship though to be fair and it didn't occur to either of them not knowing what they didn't know.
  - jacquesm 3y ago
    I suspect the maintainer never properly realized how much Co-authorship or authorship of the patch meant to the contributor (given that this was their first contribution), and that was probably informed by the size of the patch, the fact that the OP used their corporate email address and the fact that the patch was very small, required work wasn't properly formatted for immediate inclusion. 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.
    - dcow 3y ago
      [flagged]
      - jacquesm 3y ago
        My 'fixation' is that if you write a 1000 word angry blogpost attacking a kernel maintainer that you weren't properly credited that you could have at least submitted your patch properly formed. You seem to think that a sign-off is a formality, but it really isn't: it's to shield the kernel maintainers from copyright lawsuits by parties that surreptitiously include copyrighted code. It is a very important item on the checklist for a maintainer. You need to personally certify that you are able to make this particular contribution. See the LKML guideline for submitting patches that I've already linked to twice now. 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.
        dcow 3y ago
        I follow your point about the OP maybe not understanding some context and well it's just a hard lesson learned. 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), so I don't think we're dealing with a case of urgency trumping all human decency. 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.
- matrss 3y ago
  The patch I found was signed off. If it wasn't I fail to see how the maintainer could have legitemately signed off his own patch considering it was modified from or inspired by the original patch.
  - jacquesm 3y ago
    They went back and forth on that in email with the maintainer very clearly stating their intentions.
    - matrss 3y ago
      I did not find that yet. Can I read that anywhere? 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.
      - jacquesm 3y ago
        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). The OP has submitted a link to an email archive further down in the thread.
        matrss 3y ago
        I see which email thread you mean now. AFAICS OP submitted the patch with a proper sign-off again approximately 6 hours after they were told the sign off was missing. So I don't see how that could have been an issue. The maintainers patch is from more than a week later. > 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.

by matrss 3y ago

jacquesm 3y ago

That's fair, but before you know it you're going to have a whole taxonomy of different kinds of contributions and there simply isn't one for 'x did RCA' and the fact that the original patch wasn't properly signed off as mentioned in the exchange with the kernel maintainer may have been all that stood between that and another level of accreditation. Which by the way wasn't responded to by the OP as far as I can see, even though the maintainer clearly mentioned it and the LKML list spells out that that is a requirement for accreditation.

jxramos 3y ago
yah, this is a sticky point. This is one of those scenarios where I put the onus on the person more familiar with the process to inform others for these sort of nuances. Its one of those information asymmetry / familiarity problems. Maybe both were not well versed in the concept of coauthorship though to be fair and it didn't occur to either of them not knowing what they didn't know.
- jacquesm 3y ago
  I suspect the maintainer never properly realized how much Co-authorship or authorship of the patch meant to the contributor (given that this was their first contribution), and that was probably informed by the size of the patch, the fact that the OP used their corporate email address and the fact that the patch was very small, required work wasn't properly formatted for immediate inclusion. 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.
  - dcow 3y ago
    [flagged]
    - jacquesm 3y ago
      My 'fixation' is that if you write a 1000 word angry blogpost attacking a kernel maintainer that you weren't properly credited that you could have at least submitted your patch properly formed. You seem to think that a sign-off is a formality, but it really isn't: it's to shield the kernel maintainers from copyright lawsuits by parties that surreptitiously include copyrighted code. It is a very important item on the checklist for a maintainer. You need to personally certify that you are able to make this particular contribution. See the LKML guideline for submitting patches that I've already linked to twice now. 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.
      - dcow 3y ago
        I follow your point about the OP maybe not understanding some context and well it's just a hard lesson learned. 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), so I don't think we're dealing with a case of urgency trumping all human decency. 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.
matrss 3y ago
The patch I found was signed off. If it wasn't I fail to see how the maintainer could have legitemately signed off his own patch considering it was modified from or inspired by the original patch.
- jacquesm 3y ago
  They went back and forth on that in email with the maintainer very clearly stating their intentions.
  - matrss 3y ago
    I did not find that yet. Can I read that anywhere? 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.
    - jacquesm 3y ago
      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). The OP has submitted a link to an email archive further down in the thread.
      - matrss 3y ago
        I see which email thread you mean now. AFAICS OP submitted the patch with a proper sign-off again approximately 6 hours after they were told the sign off was missing. So I don't see how that could have been an issue. The maintainers patch is from more than a week later. > 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.