A wonderful twist on being an open source maintainer is when the person engaging poorly and violating the CoC is a security reporter with some valid observations.

A wonderful twist on being an open source maintainer is when the person engaging poorly and violating the CoC is a security reporter with some valid observations.

You now have conflicting responsibilities to users' security and to your and your community's safety.

@filippo I would recommend that nobody gets a CoC free pass. It doesn't matter if that person found something important, or if that person was a big contributor, or if that person was in a leadership position. Same rules for everyone.

@filippo I'm curious, what the violation was?

@filippo that person should understand and rectify their behaviour, or else it's an indication of their poor judgment and values, in which case i wouldn't trust them with my users' security at all

@filippo You have no conflicting responsibilities. Your CoC and your community’s safety means nothing at all if you’re willing to give someone a pass for being occasional useful. Either enforce the CoC, or remove the CoC.

@ohno so to be clear you would just block them and lock the thread and stop replying to the emails to security@ before they could finish discussing the apparently valid security issue which threatens your users' security?

I don't know what the right answer is exactly, but I am pretty sure it is more nuanced than this.

@xyhhx you don't need to trust a reporter with your users' security, you just need to understand what they are saying yourself?

@emersion big contributors and leadership positions are high-power roles that have nothing to do with a drive-by security reporter that is volunteering information that might be relevant to your users' security, who trust you.

I don't know what the answer is but it's not this simple.

@filippo i was replying to your dilemma in the last statement. im saying err on the safety of your community, always. if they can't follow code or conduct, they can't be permitted in your users' presence. even if they report valid security concerns, it's always from the lens of their worldview and you should weigh that when triaging

@xyhhx so you should not hear them out to figure out if there is a security issue you need to fix to protect your users (which are not the same population as your developer community)?

I don't know what the right answer is exactly, but I am pretty sure it is more nuanced than this.

@filippo what if someone was reporting valid security issues, plausibly claiming they know of more, and refusing to say anything about them unless e.g. you allowed them or someone else to harass others or paid them or excluded a person their dislike from the project?

I think that your dilemma is a specific kind of extortion, but I don't see why it shouldn't be dealt with in the way you'd deal with more explicit extortion.