7 ms·

> The code, intended to steal users’ bitcoin wallets, had been injected by an unknown developer with the username right9ctrl. That person had gained commit acce

> The code, intended to steal users’ bitcoin wallets, had been injected by an unknown developer with the username right9ctrl. That person had gained commit access from event-stream’s author, Dominic Tarr, simply by asking for it. To many angry users, this was the equivalent of opening one’s front door to the first stranger who knocked, then grabbing one’s coat and leaving for the day. No. A better analogy would be that a weary volunteer potato farmer for a large community garden is approached by a member of that community who also has potato farming skills. The community member tells him that he wishes take over maintenance of the farm. The weary volunteer accepts the community members offer and leaves the farm in the new volunteer's hands. The weary farmer returns to his home, and pursues other things. Meanwhile, the new community's potato farmer turns out to be malicious. Keep in mind that more than 99% of the time these volunteers are just wanting to give back to the community. It is nothing like giving up the keys to your home. It is like giving up volunteer work to another volunteer, because that is exactly what it is.

dgellow 7y ago
I honestly cannot say if this comment is satire or not.
pdonis 7y ago
> It is like giving up volunteer work to another volunteer But without making it clear to anyone else in the volunteer community that that's what you've done. In other words, using your garden analogy, a weary volunteer potato farmer whose potatoes feed a lot of people is approached by another volunteer who wants to take over maintenance of the potatoes. The weary volunteer gives it to him, but doesn't tell any of the people who rely on his potatoes for food. The new volunteer puts a harmful substance in the potatoes and lots of people get very sick, because they thought the potatoes were still being maintained by the first volunteer, who they knew and trusted; they had no idea that the potatoes were now being maintained by a newcomer who they didn't know and whose trustworthiness they had no way to evaluate.
- josteink 7y ago
  > But without making it clear to anyone else in the volunteer community that that's what you've done. You mean like pretty much 100% of everything else going on in a typical open source community? I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software, nor if updates are based on external patches or (core) internal development. They just sit there entitled and expect free (gratis) software which works for them without providing anything in return. I’m not saying that because I’m a bitter maintainer, but it’s just a fact of life. You couldn't inform these users about any changes at all even if you wanted to, because they’re simply not involved and they never will be. Anyway, if they cared, if they were somewhat involved, they would know. As it stands, it’s their own fault for blindly trusting random code from the internet. And really: mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
  - pdonis 7y ago
    > I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software I'm not talking about users. I'm talking about other developers who are using the package, and who deserve to know when the package's maintainer changes. > it’s their own fault for blindly trusting random code from the internet Developers aren't trusting random code from the internet; they're trusting a particular package maintained by a particular person who, from past experience, they have reason to trust. But if that maintainer hands the project over to someone else without telling all those other developers, that's betraying the trust those other developers put in that maintainer. > mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this? Because it's the previous maintainer's job to tell other developers when he turns over the job to someone else. Failing to do that means the previous maintainer is basically saying what you said above: it's those other developers' own fault for blindly trusting my code, hahaha, sucks to be you. Is that the ethos you want other open source developers to follow?
    - x0x0 7y ago
ploxiln 7y ago
That analogy might work with the original formulation of this idea: if someone opens a "big" pull request on a project you weary of, hand it over. That PR, even without substantial review, can show effort and familiarity, and you could argue there's a really good chance they'll try to be good stewards. But in this case, it's not "a member of that community who also has potato farming skills", it's an absolute nobody, who you haven't seen doing any farming, or eating, before. It's a big world, there are crazies out there, they show up every once in a while. And finally, it's the internet, it's not really like anything that came before. You can be more trusting in a small town than in a big city. The internet is 1000 times bigger than the biggest city, it's a whole new kind of thing. If 99.9% of people out there have good intentions, that still leaves millions of people on the internet trying figure out a way to take advantage of you.
- dustfinger 7y ago
  Trust issues can often be mitigated with verifiable signatures. Perhaps if there was a protocol in place requiring each release to be signed by the current maintainer and all commits signed by the individual contributors, then a change in signature on the release would have provided a strong downstream signal that maintenance had changed hands. Without verifiable signatures, downstream is drinking the water without testing it. As you said, there are crazies out there, who knows what they might put in the water.
tuesdayrain 7y ago
In my opinion the farm analogy doesn't work because you can't fork a farm and continue working where the original left off. In my opinion Dominic should have simply stopped maintaining the package, and maybe added a message stating that the package is no longer being maintained. If someone wants to take over then they would need to fork it. That would force people to consciously switch to the newer forked versions and there would be no surprises about a new maintainer suddenly inserting malicious code.
- zzo38computer 7y ago
  That is what I do too. (I also do not give commit access to anyone else, but do accept patches after I review them. However, nobody ever sends patches or other stuff, but if they did, then I will read them. I do, however, allow others to edit the documentation, just not to edit the code itself.)
0x445442 7y ago
I agree with the sentiment but I think you are being too gracious with your analogy. The long and the short is a group of developers was relying on another group of developers to provide software with security concerns for free without vetting the implementation. I don't know what is more unethical, the backdoor or the blind distribution of the backdoor.

dgellow 7y ago

I honestly cannot say if this comment is satire or not.

pdonis 7y ago

> It is like giving up volunteer work to another volunteer But without making it clear to anyone else in the volunteer community that that's what you've done. In other words, using your garden analogy, a weary volunteer potato farmer whose potatoes feed a lot of people is approached by another volunteer who wants to take over maintenance of the potatoes. The weary volunteer gives it to him, but doesn't tell any of the people who rely on his potatoes for food. The new volunteer puts a harmful substance in the potatoes and lots of people get very sick, because they thought the potatoes were still being maintained by the first volunteer, who they knew and trusted; they had no idea that the potatoes were now being maintained by a newcomer who they didn't know and whose trustworthiness they had no way to evaluate.

josteink 7y ago
> But without making it clear to anyone else in the volunteer community that that's what you've done. You mean like pretty much 100% of everything else going on in a typical open source community? I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software, nor if updates are based on external patches or (core) internal development. They just sit there entitled and expect free (gratis) software which works for them without providing anything in return. I’m not saying that because I’m a bitter maintainer, but it’s just a fact of life. You couldn't inform these users about any changes at all even if you wanted to, because they’re simply not involved and they never will be. Anyway, if they cared, if they were somewhat involved, they would know. As it stands, it’s their own fault for blindly trusting random code from the internet. And really: mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this?
- pdonis 7y ago
  > I’d wager at least 99.99% of the users don’t even knows who or how many maintains a piece of software I'm not talking about users. I'm talking about other developers who are using the package, and who deserve to know when the package's maintainer changes. > it’s their own fault for blindly trusting random code from the internet Developers aren't trusting random code from the internet; they're trusting a particular package maintained by a particular person who, from past experience, they have reason to trust. But if that maintainer hands the project over to someone else without telling all those other developers, that's betraying the trust those other developers put in that maintainer. > mostly changing maintainer for a new, more motivated one usually works out better, even for these users, so why should the burnt out previous maintainer feel bad about this? Because it's the previous maintainer's job to tell other developers when he turns over the job to someone else. Failing to do that means the previous maintainer is basically saying what you said above: it's those other developers' own fault for blindly trusting my code, hahaha, sucks to be you. Is that the ethos you want other open source developers to follow?
  - x0x0 7y ago

ploxiln 7y ago

That analogy might work with the original formulation of this idea: if someone opens a "big" pull request on a project you weary of, hand it over. That PR, even without substantial review, can show effort and familiarity, and you could argue there's a really good chance they'll try to be good stewards. But in this case, it's not "a member of that community who also has potato farming skills", it's an absolute nobody, who you haven't seen doing any farming, or eating, before. It's a big world, there are crazies out there, they show up every once in a while. And finally, it's the internet, it's not really like anything that came before. You can be more trusting in a small town than in a big city. The internet is 1000 times bigger than the biggest city, it's a whole new kind of thing. If 99.9% of people out there have good intentions, that still leaves millions of people on the internet trying figure out a way to take advantage of you.

dustfinger 7y ago
Trust issues can often be mitigated with verifiable signatures. Perhaps if there was a protocol in place requiring each release to be signed by the current maintainer and all commits signed by the individual contributors, then a change in signature on the release would have provided a strong downstream signal that maintenance had changed hands. Without verifiable signatures, downstream is drinking the water without testing it. As you said, there are crazies out there, who knows what they might put in the water.

tuesdayrain 7y ago

In my opinion the farm analogy doesn't work because you can't fork a farm and continue working where the original left off. In my opinion Dominic should have simply stopped maintaining the package, and maybe added a message stating that the package is no longer being maintained. If someone wants to take over then they would need to fork it. That would force people to consciously switch to the newer forked versions and there would be no surprises about a new maintainer suddenly inserting malicious code.

zzo38computer 7y ago
That is what I do too. (I also do not give commit access to anyone else, but do accept patches after I review them. However, nobody ever sends patches or other stuff, but if they did, then I will read them. I do, however, allow others to edit the documentation, just not to edit the code itself.)

0x445442 7y ago

I agree with the sentiment but I think you are being too gracious with your analogy. The long and the short is a group of developers was relying on another group of developers to provide software with security concerns for free without vetting the implementation. I don't know what is more unethical, the backdoor or the blind distribution of the backdoor.