Would be helpful is Christine gave some examples to threads and discussions. Without any details, either side can be blamed for the ban.
Also, would be good to know what are the contributions. I have looked at the github page of V contributers https://github.com/vlang/v/graphs/contributors and have not find Chrinstine there.
I don't know if I have any copies of it anymore, because it was deleted from the V Discord. Once they found out I was the author of that post everything was deleted and I was banned from the Discord, Telegram and GitHub.
When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.
I'm going to guess (at least I hope!) that you're inexperienced in the professional world. Well, in the adult world you will face criticism for what you produce constantly.
Some of that criticism will be fair and you'll be able to act on it - you can improve what you've done. Some will be fair but you can't act on it - you can't change it in time or on budget and that's not your fault. And some will be completely unfair - it's simply not accurate.
You need to develop a mature response to all these scenarios. But sticking your fingers in your ears and going, "lalala I can't hear you" is not one of them.
This post pretends to be a security report, but it does not help anybody (there are no users who would be protected by disclosing this "vulnerability"), it is just disruption of people work, and nothing more.
People actively breaking things cannot be just ignored, they should be banned.
> When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.
According to this: https://christine.website/blog/series/v it was a year between first post and the last. It was more than enough time to make at least some contributions.
This timeline convinces me that Christine did not intend to contribute at all.
> Well, in the adult world you will face criticism for what you produce constantly.
Criticism is natural. Banning people who don't help, but distract and demotivate, is also natural.
> You need to develop a mature response to all these scenarios.
It's not that simple. Too much criticism can kill will even in strongest people. Sometimes the best response to non-constructive criticism is to just ban, and focus on what's important.
> No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it.
We don't know how exactly Christine communicated with project devs. We see the posts, but we don't see Telegram or Discord messages or GitHub issues or comments or whatever.
For example, there are people who just derail/flood group communications by raising non-important issues (like discussing syntax), or discussing completely unrelevant topics (like starting a conversation about political situations, human rights etc).
Anyway, I agree that the project author could do better. But I cannot blame him either. At least until either party provide some evidence.
> Having read the posts, it seems perfectly reasonable criticism, with enactable improvement
Calling a product vaporware is not a good way to start a constructive communication.
If I did that, I'd either start with apologising for calling the project vaporware, or did not attempt to join the community.
> To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.
Developers in commercial products are paid for listening that feedback (constructive or not). But V is open source.
And in commercial companies, internal tensions are usually fixed very quickly, because teams cannot work efficiently when communication is bad.
We don't know the full story because the V devs deleted it. Experience tells me that people tend not to delete stories that paint them in the better light.
It's vaporware until it we exists. Perhaps it would be kinder to call it "conceptware" but who really cares?
Oh, and the vast majority of commercial software firms have absolutely terrible communication. And, yes, they do not work effectively.
I feel like I am destroying an optimistic world view here, which is the last thing I wanted. There are many excellent and exciting places to work. Don't let an old man's cynicism put you off!
> And in commercial companies, internal tensions are usually fixed very quickly
I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.
> I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.
Probably most companies deal with tensions more or less successfully. They have good instruments to manage these things: yearly bonuses and option to fire employees who do not cooperate.
Obviously these instruments are not available in open-source projects.
I'm sincerely curious, I have worked in tech for 20 years, and while some companies are active in trying to make sure teams work well together, I've never seen one that had specific systems for keeping tensions in check - maybe it's because I've worked for <1000 people companies?
All successful companies, and these instruments are: 1) bonuses for successful work, which includes ability to resolve conflicts peacefully; 2) option to fire employees who don't work well, in particular, those who don't get along with the team and hire a replacement.
> I've never seen one that had specific systems for keeping tensions in check
It does not work perfectly, for sure. But in free-time opensource project, if you don't like something, you can always express this loudly, or just stop caring about this project, because leaving the opensource project is not a big deal.
Unlike employment, when if you quit or fired, you get a lot of stress, you are seriously motiviated to get conflict resolved.
Long time ago I read an interesting article about how hard is to be a manager in a terrorist organisation. You don't pay people money, at least not a lot, there's no contract, employees goal are likely very different from yours. They quit randomly, they do whatever they want, and it's hard to achieve some discipline. I think this is kind of similar environment as in open-source project (except, open-source contributers don't blow themselves up).
Again you’ve failed to provide a single example from your experience so I’m left to assume you have none.
Sorry, it sounds like you have idealized views that don’t match with actually working at tech companies. Please don’t proselytize things that you have no experience with - it can be massively distracting and confusing for people who are in situations where your advice seems like pure gaslighting.
Bonuses are not a way to ease interpersonal tension, in fact, they make them worse.
If I’ve misread this in any way, please let me know, but don’t further waste my time with bullshit.
I'm failing to see how that post is a "childish attempt" at anything. Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a pretty glaring problem. At worst, you might criticize her for publishing that post immediately after discovering the exploit (instead of the more "polite" approach of allowing someone to patch it first, within a reasonable deadline), but that's pretty minor in comparison to, you know, V's playground being vulnerable to major security issues.
In any case, banning people from contributing to a project entirely merely because they pointed out glaring security issues is considerably more childish than the actual pointing out of security issues, no matter how distastefully the latter might've been done (and again, aside from the lack of a responsible disclosure period, I ain't seeing anything particularly glaring in that post).
I considered it not an issue to post about it because the server was down and confirmed to not come back up (I think someone ace'd it and installed a rootkit then rebooted).
> Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a pretty glaring problem
How it is a problem for anyone except project owners?
Project owners were notified. There was no need to disclose it publicly. I say it's childish.
> banning people from contributing to a project entirely merely because they pointed out glaring security issues
Banning them because they:
* don't do any good (in particular, zero code contributions in a year)
* disrupt the work by telling the internet how to break their service
* call the project "vaporware"
I'd call it is enough reasons to ban them.
And some personal argument.
I have a service I'm running, for the random people in the internet. I implemented it long time ago, and I spend like 10 minutes a year supporting it. It is not protected seriously, because I don't have enough time to do so. I think any kid with basic knowledge of how internet works, can easily break it, or even can DOS it causing me to pay big bucks to the hoster for the consumed CPU.
And I have full-time job. So if some person would notify me about the vulnerability, and give me one (!) day to fix it, I would probably give up what ever I'm doing, my work, my personal plans, and fix the issue, but I would be very unhappy about it, and I will probably be angry at that person, and I'll try to avoid that person like fire.
> How it is a problem for anyone except project owners?
Because an infected machine can and often will participate in infecting other machines.
Not to mention that if an attacker managed to extract credentials that happened to be shared between that server's accounts and, say, contributors' GitHub accounts...
More relevantly for regular users of the playground, though, it ain't clear whether or not the playground server was separate from the web server. If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). And even if they were indeed separate servers, if the credentials to access those servers were shared between them, then compromising one exposes the other.
I agree with you that maybe the author of that article should've waited more than a day, but that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing.
> call the project "vaporware"
I mean, for quite a while it did seem to have a lot of hype without much to show for it (as did Volt, its "killer app", so to speak), and it had a pretty rough release. It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Hopefully things have improved since then.
> Because an infected machine can and often will participate in infecting other machines.
OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process.
> Not to mention that if
That big if.
> If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.).
That's good example.
And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day.
> that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing
I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects.
The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited.
> It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate.
Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you.
Saying he is dumb is not innaccurate. But it doesn't help constructive team work.
The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.
Well, I can only say you don't understand how disclosure works.
When vulnerability is disclosed, there are usually good reasons for doing so.
For example, when a vulnerability in operating system is found, it is disclosed, so users of that operating systems could upgrade operating system, or stop using it, or ask vendor to fix it or whatever. Disclosing this vulnerability makes the people (who are not project owners) safer from possible attacks from attackers who can independently find this vulnerability.
How would disclosing vulnerability of V playground be beneficial for anybody? I can hardly find any significant reason.
It's like you have accidentally found that your neighbour forgets to close the door when he leaves for a walk. You notified him, he did nothing. Disclosing this vulnerability would not make good to anyone except burglars. Good people don't do that.
Users of the service were not affected by this vulnerability, it had no personal data or something.
The only people who could be hurt by this vulnerability is the project owner.
Disclosing this vulnerability would only make it worse for the project owner, and would not do good to anyone (except cracker who might want to use the server to send spam or something).
This post did no good to anyone. It's lose-lose. That's why this post is wrong.
Also, would be good to know what are the contributions. I have looked at the github page of V contributers https://github.com/vlang/v/graphs/contributors and have not find Chrinstine there.