10 ms·

I read the article, thank you. It is completely fine to have a murderer write your filesystems. Accepting patches from someone who writes good code and treats e

I read the article, thank you. It is completely fine to have a murderer write your filesystems. Accepting patches from someone who writes good code and treats everyone involved with respect is the right approach.

matt4077 9y ago
But would you marry someone who contributed to FAT?
deleted 9y ago
[deleted]
watwut 9y ago
What about accepting non trivial patch from someone who smuggled backdoor for lulz to another project 3 years ago?
- Sephr 9y ago
  Fraud is very different from murder, and I understand why someone would be worried about accepting contributions from a known fraudster. I would not give their contributions extra attention (you should be suspect of all changes, regardless of the author) and I would not ban them from contributing unless they became disruptive or subversive to the project. They served their time; you don't need to punish them further. They are probably even less likely to commit fraud when their employer is aware of a previous fraud conviction. The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor.
  - mannykannot 9y ago
    > They served their time; you don't need to punish them further. It is not about punishing them, it is about reducing the risk of others. Having served time is, at best, no indication of whether a person will revert to their former behavior. > The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor. This is no reason for not using what information you do have. Note: I see that you have edited your original post to address these points, but I think they still stand, as expanded on in the continuing discussion below. Your statement "they are probably even less likely to commit fraud when their employer is aware of a previous fraud" seems to be in agreement with what I have been saying.
    - Sephr 9y ago
      It's a reason to be equally suspicious of all code changes regardless of the publicly known reputation of a contributor, as it always comes down to the code itself.
      - mannykannot 9y ago
        You are still arguing against using the available evidence. You never have the time and resources to fully validate anything of use, so you have to use your judgement as to how best to go about it. If you learn that a person responsible for some aspect of security has been found guilty of defrauding his church's charity drive, it would be prudent to take a second look at his code.
      - watwut 9y ago
        Absolutely. Then again, code review is never perfect and it is easy to miss hard to see cosequence of something subtle. Especially if I tentionally hidden. So, trust matters. If you have track record of doing such things, then accepting your pull request comes with higher risk.
- Sir_Cmpwn 9y ago
  This is a good example, I agree that such a person probably isn't welcome - with a few caviats: - Small (and well scrutinized) patches from this person are fine - At some point forgiveness is due, maybe 3 years is at that point depending on the severity of their backdoor
_qbxp 9y ago
Devil's advocate on this - what if the general population of your customers don't want to support a company that pays the salary of a murderer? Then it affects your bottom line. Would you still be ok with it?
- Sir_Cmpwn 9y ago
  This is about FOSS projects, which are generally unpaid.

matt4077 9y ago

But would you marry someone who contributed to FAT?

deleted 9y ago

[deleted]

watwut 9y ago

What about accepting non trivial patch from someone who smuggled backdoor for lulz to another project 3 years ago?

Sephr 9y ago
Fraud is very different from murder, and I understand why someone would be worried about accepting contributions from a known fraudster. I would not give their contributions extra attention (you should be suspect of all changes, regardless of the author) and I would not ban them from contributing unless they became disruptive or subversive to the project. They served their time; you don't need to punish them further. They are probably even less likely to commit fraud when their employer is aware of a previous fraud conviction. The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor.
- mannykannot 9y ago
  > They served their time; you don't need to punish them further. It is not about punishing them, it is about reducing the risk of others. Having served time is, at best, no indication of whether a person will revert to their former behavior. > The worst fraudsters don't come with a "convicted of fraud" warning—they have evaded being caught and will seem just like any other contributor. This is no reason for not using what information you do have. Note: I see that you have edited your original post to address these points, but I think they still stand, as expanded on in the continuing discussion below. Your statement "they are probably even less likely to commit fraud when their employer is aware of a previous fraud" seems to be in agreement with what I have been saying.
  - Sephr 9y ago
    It's a reason to be equally suspicious of all code changes regardless of the publicly known reputation of a contributor, as it always comes down to the code itself.
    - mannykannot 9y ago
      You are still arguing against using the available evidence. You never have the time and resources to fully validate anything of use, so you have to use your judgement as to how best to go about it. If you learn that a person responsible for some aspect of security has been found guilty of defrauding his church's charity drive, it would be prudent to take a second look at his code.
    - watwut 9y ago
      Absolutely. Then again, code review is never perfect and it is easy to miss hard to see cosequence of something subtle. Especially if I tentionally hidden. So, trust matters. If you have track record of doing such things, then accepting your pull request comes with higher risk.
Sir_Cmpwn 9y ago
This is a good example, I agree that such a person probably isn't welcome - with a few caviats: - Small (and well scrutinized) patches from this person are fine - At some point forgiveness is due, maybe 3 years is at that point depending on the severity of their backdoor

_qbxp 9y ago

Devil's advocate on this - what if the general population of your customers don't want to support a company that pays the salary of a murderer? Then it affects your bottom line. Would you still be ok with it?

Sir_Cmpwn 9y ago
This is about FOSS projects, which are generally unpaid.